옛 웹 주소를 찾는 판단 기준
템플릿 변경 뒤 남은 옛 웹 주소는 오류 표시만으로 판단하지 말고, 변경 전후 주소 목록을 기준으로 실제 렌더링된 구조화 데이터의 값을 대조해 찾아야 합니다. 사이트 운영자는 변경 대상 주소를 정리하고, 개발 담당자는 변경된 템플릿을 사용하는 페이지에서 출력된 값이 그 목록과 일치하는지 검사합니다.
여기서 찾는 주소는 페이지나 자료의 위치를 나타내는 웹 주소입니다. 사업장 소재지나 우편 주소의 작성 기준은 이번 대조 대상에 포함하지 않습니다. 템플릿을 변경하면서 페이지 경로나 자료 위치를 변경했다면, 화면의 링크뿐 아니라 구조화 데이터에 남은 이전 값도 조사 대상에 포함합니다.
대조 목록에는 변경 전 값과 변경 후 값을 짝으로 기록합니다. 페이지의 이동 대상과 구조화 데이터 안에서 그 주소가 가리키는 대상이 다르면, 주소 문자열만 같다는 이유로 일괄 변경하지 않습니다. 마케팅 담당자는 각 주소가 어떤 콘텐츠를 가리키는지 설명하고, 개발 담당자는 실제 출력 위치를 연결해 기록합니다.
| 변경 전 웹 주소 | 변경 후 웹 주소 | 확인할 페이지 |
|---|---|---|
| 이전 상세 페이지 주소 | 현재 상세 페이지 주소 | 상세 템플릿을 적용한 페이지 |
| 이전 목록 페이지 주소 | 현재 목록 페이지 주소 | 목록을 참조하는 구조화 데이터가 있는 페이지 |
| 이전 자료 위치 주소 | 현재 자료 위치 주소 | 해당 자료를 구조화 데이터에 기재한 페이지 |
| 이전 공통 참조 주소 | 현재 공통 참조 주소 | 공통 설정을 사용하는 페이지 |
표에는 실제로 변경한 항목만 기재하며, 변경하지 않은 주소를 새 주소로 취급하지 않습니다. 현재도 사용해야 하는 값이 섞여 있다면 유지 사유를 별도 기록합니다. 이 목록을 확정하지 못한 상태에서는 옛 문자열을 발견했더라도 수정 대상인지 판단을 보류합니다.
오류 표시와 주소값의 정확성
구글의 리치 결과 테스트 도움말은 테스트 결과에서 발견된 리치 결과 유형과 구조화된 데이터의 오류 및 제안사항을 확인할 수 있다고 설명합니다. 오류나 경고의 설명을 선택하면 해당 위치의 렌더링된 소스 코드가 코드 탐색기에 표시된다고 안내합니다. 담당자는 이 결과를 출력 위치를 찾는 자료로 사용하고, 주소가 최신 값인지 판단할 때는 변경 목록을 적용합니다.
유효한 항목이라는 표시만으로 템플릿 변경 사항이 모두 반영됐다고 결론 내리지 않습니다. 운영자가 의도한 새 주소와 출력된 주소의 일치 여부는 별도로 대조해야 합니다. 반대로 경고가 있다는 이유만으로 그 항목의 모든 주소를 옛값으로 처리해서도 안 됩니다.
구글 검색 센터는 부정확한 권장 속성을 많이 채우는 것보다 완전하고 정확한 값을 적용하는 일이 더 중요하다고 설명합니다. 이번 작업에서는 속성의 양을 늘리는 대신, 변경 대상 값의 잔존 여부를 조사합니다. 전체 구조화 데이터 오류를 함께 해결하려다 주소 수정의 범위가 불명확해지면 별도 작업으로 분리합니다.
자료 준비와 출력값 대조 순서
사이트 운영자는 변경 내역, 적용한 템플릿 이름, 해당 템플릿을 사용하는 페이지 목록을 준비합니다. 개발 담당자는 구조화 데이터를 생성하는 코드와 페이지별 입력값을 조사할 수 있도록 준비합니다. 마케팅 담당자는 변경 후 주소가 가리켜야 하는 콘텐츠를 정리해 기술 담당자에게 전달합니다.
- 변경 전후 주소를 짝지어 정리하고, 변경 대상과 유지 대상을 가립니다. 주소의 일부만 기록하면 서로 다른 경로를 혼동할 수 있으므로 실제 값을 기록합니다.
- 변경된 템플릿을 사용하는 페이지를 리치 결과 테스트로 검사합니다. 렌더링된 소스에서 구조화 데이터의 주소값을 찾아 변경 목록과 대조하고, 발견한 항목과 위치를 기록합니다.
- 같은 템플릿을 사용하는 다른 페이지로 조사 범위를 넓힙니다. 공통 출력 코드에서 비롯된 값인지, 특정 페이지의 입력값에서 비롯된 값인지 가립니다.
- 원인을 수정하고 게시한 뒤 서치 콘솔의 실시간 URL 테스트를 실행합니다. 수정한 페이지에서 문제가 해결됐는지 검사하고, 현재 출력값을 변경 후 주소와 다시 대조합니다.
주소 검색 결과에는 본문 링크나 스크립트의 다른 문자열이 함께 포함될 수 있습니다. 담당자는 검색된 위치가 구조화 데이터에 속하는지 먼저 가린 뒤 기록합니다. 구조화 데이터 안에서도 동일한 값이 여러 항목에 사용된다면 발견 위치를 각각 남깁니다.
| 확인한 페이지 | 구조화 데이터에서 발견한 주소값 | 옛값 잔존 여부 | 수정 후 재확인 결과 |
|---|---|---|---|
| 처음 검사한 적용 페이지 | 실제 출력값 기재 | 변경 목록과 대조해 기재 | 현재 출력값과 테스트 결과 기재 |
| 같은 템플릿의 다른 페이지 | 해당 페이지의 출력값 기재 | 옛값 발견 위치 함께 기재 | 같은 원인의 수정 여부 기재 |
| 개별 입력값이 있는 페이지 | 개별 설정에서 나온 값 기재 | 공통 코드와 별도로 판단 | 개별 값의 반영 여부 기재 |
| 출력을 얻지 못한 페이지 | 판단에 필요한 값 없음 | 미판정으로 기재 | 출력을 얻은 뒤 결과 기재 |
수정 후 테스트와 기록 마감
구글의 URL 검사 도구 도움말은 실시간 테스트가 페이지 수정 후 문제 해결 여부를 테스트하는 데 유용하다고 설명합니다. 페이지에 로그인 없이 인터넷으로 접근할 수 있어야 하며, URL 검사에서 실시간 URL 테스트를 실행하도록 안내합니다. 운영자는 수정 사항이 게시된 페이지를 대상으로 진행합니다.
서치 콘솔에서는 구글 색인 결과와 실시간 테스트 결과를 전환할 수 있으므로, 기록에 어떤 결과를 사용했는지 명시합니다. 테스트 당시의 페이지 주소와 수정 대상 항목을 함께 남기고, 주소값 대조 결과와 도구의 오류 결과를 별도로 기록합니다. 출력값을 얻지 못한 페이지는 완료로 처리하지 않고 재검사 대상으로 남깁니다.
공통 코드와 개별 입력값의 차이
같은 템플릿을 사용한다고 해서 구조화 데이터의 모든 값이 같은 경로에서 생성되는 것은 아닙니다. 공통 코드가 주소를 직접 출력할 수도 있고, 페이지별 저장값을 읽어 출력할 수도 있습니다. 개발 담당자는 옛값이 발견된 항목의 생성 경로를 추적해 수정할 위치를 결정합니다.
여러 페이지에서 동일한 옛값이 발견되면 공통 설정이나 출력 코드를 우선 조사합니다. 특정 페이지에서만 발견되면 해당 페이지의 입력값, 별도 코드, 템플릿 적용 상태를 조사합니다. 이 순서는 원인을 좁히기 위한 실무 절차이며, 발견 양상만으로 원인을 확정하지 않습니다.
마케팅 담당자는 옛값이 발견된 페이지 목록을 전달할 때 템플릿 이름과 콘텐츠 종류도 함께 기재합니다. 개발 담당자는 수정한 생성 경로를 기록해 다른 페이지에도 같은 수정이 적용되는지 판단합니다. 페이지마다 개별 값을 고쳐야 한다면 공통 코드 수정 완료와 개별 입력값 수정 완료를 따로 기록합니다.
소스 검색에서 생기는 오판
옛 주소를 소스에서 발견했다는 사실과 구조화 데이터에 옛값이 남았다는 판단은 같지 않습니다. 사용하지 않는 문자열이나 다른 기능의 설정에 포함된 주소까지 이번 작업의 수정 대상으로 처리하면 불필요한 변경이 발생할 수 있습니다. 담당자는 발견한 문자열을 포함하는 항목과 그 항목의 실제 출력 여부를 연결해 기록합니다.
반대로 템플릿 파일에서 옛 주소를 찾지 못했다는 이유만으로 작업을 끝내지 않습니다. 주소가 저장된 입력값이나 공통 설정에서 전달된다면 템플릿 파일 검색만으로 원인을 찾기 어렵습니다. 렌더링된 결과에서 발견한 항목을 출발점으로 생성 경로를 추적합니다.
페이지에 구조화 데이터가 여러 묶음으로 출력될 때는 수정된 묶음만 검사하고 종료하지 않도록 주의합니다. 별도 코드나 추가 기능이 동일한 대상을 다시 출력하는지 조사합니다. 옛값이 남은 묶음의 생성 주체를 특정한 뒤 해당 설정이나 코드를 수정합니다.
일괄 치환 전에 정할 수정 단위
주소의 일부 문자열이 같다는 이유만으로 전체 소스에 일괄 치환을 적용하지 않습니다. 변경 대상에는 포함되지 않은 참조값까지 수정될 수 있으므로, 개발 담당자는 주소 전체 값과 출력 항목을 기준으로 수정 범위를 정합니다. 여러 주소의 경로를 함께 변경할 때도 각 항목이 가리키는 대상이 유지되는지 판단합니다.
수정 요청에는 발견한 옛값뿐 아니라 변경할 값과 해당 값을 출력하는 위치를 함께 기재합니다. 변경할 값을 확정하지 못했다면 임의의 새 경로를 입력하지 않고 운영자의 결정을 요청합니다. 승인된 대응 관계가 없는 항목은 수정 완료 목록에서 제외하고 미결 항목으로 기록합니다.
자주 묻는 질문
옛 주소가 새 페이지로 연결되면 그대로 유지해도 됩니까?
접속이 된다는 사실만으로 유지 여부를 결정하지 않습니다. 연결 결과와 구조화 데이터에 기재할 값의 정확성은 별도 판단이므로, 운영자는 이전 주소를 계속 사용할 의도가 있는지 결정해야 합니다. 유지하기로 했다면 변경 목록에 그 사유를 기록해 반복 수정 요청을 막습니다.
이전 주소의 경로를 모르면 어떤 자료를 사용해야 합니까?
사이트 운영자는 이전 배포 기록, 콘텐츠 관리 내역, 보관한 페이지 자료에서 변경 전 값을 수집합니다. 개발 담당자는 코드 변경 기록이나 저장값 변경 내역을 함께 조사합니다. 원래 값을 복원할 근거가 없으면 추정 문자열로 목록을 채우지 않고 자료가 부족한 항목으로 기록합니다.
슬래시나 문자 표기 차이도 옛값으로 처리해야 합니까?
표기 차이만으로 모두 옛값이라고 결정하지 않습니다. 변경 요청에서 어떤 표기를 현재 값으로 정했는지와 해당 주소가 가리키는 대상을 함께 판단합니다. 표기 통일이 필요한 항목은 별도 수정 사유를 기재해 경로 변경 작업과 혼동하지 않도록 합니다.
배포 후 상태 보고서만으로 주소 수정을 완료해도 됩니까?
구글 검색 센터는 배포 후 리치 결과 상태 보고서로 템플릿이나 게재 문제에 따른 페이지 유효성을 모니터링하도록 안내합니다. 이 용도와 운영자가 정한 주소값의 반영 여부는 같지 않습니다. 보고서는 배포 후 유효성 관찰에 사용하고, 주소 수정 완료에는 해당 값의 출력 기록을 남깁니다.
검사 도중 구조화 데이터가 전혀 감지되지 않으면 어떻게 합니까?
옛값이 없다고 결론 내리기 전에 해당 페이지에 구조화 데이터가 출력될 예정이었는지 개발 담당자에게 묻습니다. 리치 결과 테스트는 JSON-LD, RDFa, 마이크로데이터를 지원하므로 실제 구현 형식과 출력 상태를 조사합니다. 예정된 출력이 사라졌다면 주소 잔존 조사와 별도로 출력 문제를 처리합니다.
