페이지 테스트와 문제 항목 탐색
구조화 데이터 오류는 리치 결과 테스트에서 문제가 표시된 항목을 펼쳐 렌더링된 코드의 위치를 찾는 순서로 찾습니다. 도구로 확인하기 어려운 품질 문제는 별도로 점검하고, 수정한 데이터를 다시 테스트합니다. 사이트 운영자는 페이지 전체의 결과 요약만 읽고 수정 요청을 보내기보다 문제가 발생한 항목의 세부정보까지 찾아야 합니다.
먼저 조사할 페이지 주소로 리치 결과 테스트를 실행합니다. 결과가 나오면 페이지를 가져왔는지와 구조화된 데이터 항목을 찾았는지를 읽습니다. 구글의 리치 결과 테스트 도움말은 크롤링 완료를 페이지에 접근할 수 있다는 뜻으로 설명합니다. 페이지 접근에 실패했다면 마크업의 속성부터 고치지 말고 접근 문제를 먼저 처리할 작업으로 기록합니다.
페이지를 가져온 결과에서는 문제가 표시된 항목을 펼칩니다. 구글 도움말에 따르면 항목의 세부정보에서 문제 설명을 클릭하면 해당 위치의 코드 탐색기를 열 수 있습니다. 운영자는 항목 이름, 문제 설명, 표시된 코드 내용을 함께 기록합니다. 같은 페이지에 여러 항목이 있으면 전체 결과의 문구를 각 항목의 상태로 대신 사용하지 않습니다.
| 확인 단계 | 열어 볼 항목 | 찾아 기록할 정보 |
|---|---|---|
| 페이지 테스트 | 크롤링과 페이지 가져오기 결과 | 접근 성공 여부와 검사한 페이지 |
| 문제 항목 탐색 | 감지된 구조화된 데이터의 세부정보 | 항목 이름과 문제 설명 |
| 코드 위치 추적 | 문제 설명에서 여는 코드 탐색기 | 강조된 내용과 주변 코드 |
| 품질 조건 점검 | 공개 본문과 마크업 내용 | 내용의 불일치와 판단 근거 |
| 수정 후 테스트 | 수정한 페이지의 새 검사 결과 | 기존 문제의 상태와 새 문제 |
렌더링된 코드와 수정 대상의 연결
코드 탐색기의 표시를 실제 수정할 파일 이름으로 곧바로 해석하지 않습니다. 구글 도움말은 탐색기가 렌더링된 소스 코드를 사용한다고 설명합니다. 구현 담당자는 그 코드가 사이트에서 어떤 방식으로 생성되는지 추적하고, 수정할 원천을 찾아야 합니다. 운영자가 전달할 위치와 구현 담당자가 변경할 위치는 서로 다를 수 있습니다.
문제가 표시된 부분은 주변 코드와 함께 기록합니다. 속성 이름만 전달하면 반복되는 항목 중 어느 항목을 뜻하는지 가리기 어렵습니다. 항목을 식별할 수 있는 이름이나 해당 콘텐츠의 설명을 함께 남기고, 표시된 값이 무엇인지 기재합니다. 코드 위치는 문제를 재현하는 자료로 사용하며 수정 방법을 확정한 증거로 취급하지 않습니다.
검사 결과에 문제가 없다는 사실과 페이지 내용이 적절하다는 판단도 따로 처리합니다. 구글 검색 센터는 테스트로 대부분의 기술 오류를 찾을 수 있지만 품질 가이드라인은 자동화된 도구로 간편하게 검사하기 어렵다고 설명합니다. 운영자는 도구의 표시를 기술 문제 탐색에 사용하고, 내용에 관한 판단은 본문과 운영 자료를 근거로 진행합니다.
수정 요청에 필요한 자료와 실행 순서
수정 요청은 문제 위치와 테스트 결과를 함께 전달하는 방식으로 준비합니다. 운영자는 검사한 페이지 주소, 항목의 세부정보, 코드 탐색기에서 찾은 부분을 한 요청에 모읍니다. 구현 담당자가 같은 문제를 재현할 수 있도록 검사에 사용한 사용자 에이전트도 기재합니다. 구글 도움말은 페이지를 스마트폰 또는 데스크톱 조건으로 테스트할 수 있다고 설명합니다.
- 조사할 페이지 주소로 테스트를 실행하고 페이지 가져오기 결과를 기록합니다.
- 문제가 표시된 항목을 펼쳐 항목 이름과 설명을 수집합니다.
- 문제 설명에서 코드 탐색기를 열고 해당 내용과 주변 코드를 저장합니다.
- 공개 본문과 최신 운영 자료를 대조해 품질 문제를 별도로 기록합니다.
- 수정 요청에 자료를 첨부하고 반영된 페이지로 다시 테스트합니다.
구글 도움말에 따르면 공유 버튼으로 테스트 결과의 브라우저 링크를 전달할 수 있습니다. 운영자는 공유 기능으로 얻은 결과 링크를 수정 요청에 첨부하고, 링크가 어떤 문제를 설명하는지 짧게 기재합니다. 결과 링크만 보내면 수정 범위가 모호해질 수 있으므로 요청서에는 발견한 내용을 별도로 남깁니다.
| 발견한 문제 위치 | 수정 요청에 첨부할 자료 | 수정 후 재확인할 항목 |
|---|---|---|
| 문제가 표시된 데이터 항목 | 항목 이름, 문제 설명, 결과 링크 | 해당 항목의 문제 표시 |
| 코드 탐색기의 강조 부분 | 주변 코드와 항목 식별 정보 | 변경한 내용의 실제 반영 |
| 본문과 마크업의 불일치 | 본문 발췌와 서로 다른 값 | 공개 내용과 데이터의 일치 |
| 최신 정보와 다른 내용 | 현재 정보의 근거와 변경 요청 | 이전 값의 잔존 여부 |
반영된 페이지의 재테스트 기록
수정한 코드의 테스트 결과와 공개 페이지의 테스트 결과는 완료 기록에서 따로 표시합니다. 코드를 고쳤더라도 실제 페이지에 반영했는지는 추가로 확인해야 하기 때문입니다. 구현 담당자는 변경한 내용과 반영 여부를 전달하고, 운영자는 공개 페이지를 다시 검사해 새 결과를 기록합니다. 작업 중 코드만 검사했다면 그 사실을 요청서에 명시합니다.
재테스트에서는 처음 기록한 문제 항목을 찾아 상태가 달라졌는지 읽습니다. 이어서 새로 표시된 문제가 있는지 검사하고, 수정한 값이 렌더링된 코드에 들어갔는지 대조합니다. 검사 조건을 변경했다면 변경 이유도 함께 남깁니다. 서로 다른 조건의 결과를 수정 전후의 차이로 오해하지 않도록 기록을 분리합니다.
완료 보고에는 수정 전 설명, 변경 내용, 수정 후 결과를 연결합니다. 품질 문제에 관한 요청이 있었다면 해당 내용의 반영 여부도 별도 항목으로 기재합니다. 남은 문제가 있으면 완료라는 말로 묶지 않고 미처리 내용과 추가로 필요한 자료를 기록합니다.
자동 검사 밖의 품질 판단
품질 점검은 마크업이 공개 페이지를 사실대로 설명하는지 판단하는 작업입니다. 구글 검색 센터는 최신 정보와 원본 콘텐츠를 제공하고, 독자에게 표시되지 않는 콘텐츠를 마크업하지 않도록 안내합니다. 운영자는 이 조건을 적용할 때 공개 본문, 구조화된 데이터, 현재 정보를 입증하는 운영 자료를 준비합니다. 도구의 결과 문구만으로 내용의 적절성을 승인하지 않습니다.
먼저 구조화된 데이터에 담긴 정보가 페이지 독자에게도 전달되는지 대조합니다. 본문에 없는 설명이 있다면 사이트 내부 자료에 존재한다는 이유만으로 적절하다고 판단하지 않습니다. 페이지에서 해당 내용을 공개할 수 있는지 결정하고, 공개하지 않을 내용이라면 마크업의 수정 범위를 정합니다. 이 과정에서는 코드 문법과 콘텐츠 공개 결정을 서로 다른 작업으로 기록합니다.
최신성은 날짜 표기만으로 판단하지 않습니다. 운영자는 서비스 내용이나 안내 조건이 현재도 적용되는지 관련 자료와 대조합니다. 페이지 본문과 마크업이 같은 옛 정보를 담고 있다면 둘의 일치만으로 작업을 끝내지 않습니다. 현재 내용을 확정한 뒤 어느 부분을 함께 변경할지 요청서에 기재합니다.
품질 문제를 오류 문구로 단정하는 실수
자동 검사에 표시되지 않은 품질 문제는 발견 근거를 직접 설명해야 합니다. 구글 검색 센터는 페이지 주제와 관련이 없거나 오해를 일으키는 콘텐츠를 마크업하지 않도록 안내합니다. 운영자는 어떤 내용이 페이지 주제에서 벗어나는지, 어떤 표현이 사실과 다른지 구체적으로 기재합니다. 추측을 검사 도구가 내린 판정처럼 전달하지 않습니다.
문제가 의심되지만 현재 정보를 확정하지 못했다면 수정값을 임의로 정하지 않습니다. 요청서에는 서로 충돌하는 자료와 추가로 필요한 사실을 기록합니다. 내용의 근거가 확정되면 수정 범위를 정하고 기술 작업으로 연결합니다. 자료가 없는 상태와 잘못된 값이 입증된 상태를 같은 완료 조건으로 처리하지 않습니다.
품질 문제를 고친 뒤에는 공개 본문도 변경 의도에 맞는지 읽습니다. 구조화된 데이터만 삭제하거나 변경하면 독자에게 남아 있는 잘못된 설명을 놓칠 수 있습니다. 콘텐츠 변경에 따른 판단 근거와 코드 수정에 따른 테스트 결과를 각각 남겨 작업 내용을 설명합니다.
여러 문제의 공통 원인 판단
한 항목에 여러 문제가 표시되어도 문제마다 별개의 원인이 있다고 단정하지 않습니다. 운영자는 각 설명을 기록한 뒤 문제가 가리키는 코드 내용이 겹치는지 대조합니다. 구현 담당자는 공통으로 영향을 주는 부분이 있는지 추적하고, 수정 범위를 정합니다.
하나의 변경으로 여러 표시가 사라졌다면 완료 기록에도 실제 변경 내용을 기준으로 설명합니다. 사라진 문제 문구마다 별도의 수정을 수행한 것처럼 기재하지 않습니다. 반대로 일부 문제만 남았다면 이전 요청의 해결 여부와 남은 작업을 나누어 기록합니다. 원인이 같다는 판단은 표시 위치가 비슷하다는 추정에 그치지 않고 변경 내용과 재테스트 결과로 뒷받침합니다.
자주 묻는 질문
테스트 결과 링크를 받는 사람에게 권한이 필요합니까?
구글 도움말은 공유한 테스트 결과를 읽는 데 권한이 필요하지 않다고 설명합니다. 운영자는 내부 구성원만 접근하는 자료라고 가정하지 말고 공유할 코드와 결과에 민감한 내용이 있는지 먼저 검사합니다. 수정 요청을 전달할 때도 필요한 수신자에게만 링크를 공유합니다.
테스트 결과 링크만 장기 기록으로 보관해도 됩니까?
장기 기록을 결과 링크 하나에만 의존하지 않습니다. 구글 도움말은 테스트 기록의 저장과 결과 링크의 유효성에 정해진 기간이 있다고 설명합니다. 운영자는 문제 설명과 변경 내용, 검사 결과를 별도 작업 기록으로 보관하고 링크는 보조 자료로 사용합니다.
공개 전 코드 조각으로도 수정 내용을 시험할 수 있습니까?
구글 도움말에 따르면 리치 결과 테스트에서 코드 입력을 선택해 코드 조각을 검사할 수 있습니다. 코드를 변경한 뒤 테스트 실행으로 다시 검사하는 방식도 지원합니다. 작업 기록에는 공개 페이지 검사와 혼동하지 않도록 코드 조각을 입력한 테스트였다는 사실을 기재합니다.
테스트를 통과한 코드에 주석을 남겨도 됩니까?
JSON-LD의 주석은 게시 전에 삭제해야 합니다. 구글 도움말은 리치 결과 테스트가 해당 주석을 무시하지만 JSON-LD 표준은 이를 지원하지 않아 실제 사용에서 오류가 생길 수 있다고 설명합니다. 테스트 통과 여부만으로 주석을 유지하는 결정을 내리지 않습니다.
문제 항목의 코드 위치를 바로 찾지 못하면 어떻게 합니까?
표시된 설명을 추측해서 임의의 코드 위치에 연결하지 않습니다. 서치 콘솔의 URL 검사 도움말은 강조된 문제를 클릭해 가능한 경우 관련 코드를 찾을 수 있다고 설명합니다. 직접 연결되는 위치가 없으면 항목 이름과 문제 설명을 기록하고, 구현 담당자에게 해당 데이터가 생성되는 부분을 추적하도록 요청합니다.