진단 결과 한 줄에는 네 가지가 적혀 있습니다
진단 도구가 내놓은 목록을 열면 지적이 줄 단위로 쌓여 있습니다. 한 줄을 작업으로 넘기기 전에 그 줄이 무엇으로 이루어졌는지 봅니다.
- 대상 — 어느 주소에서 본 것인가
- 발견값 — 그때 응답에 실제로 들어 있던 값
- 기대값 — 도구가 이래야 한다고 본 값
- 확인 시점 — 그 값을 받은 시각
앞의 셋을 기록하는 방식은 진단·콘텐츠 점검·순위 측정의 차이에서 다뤘습니다. 읽기에서 갈리는 것은 네 번째입니다. 기대값의 출처에 따라 같은 지적이 당장 고칠 오류에서 우리 규칙과 다른 상태로 바뀝니다.
기대값이 어디서 왔는지부터 가릅니다
출처는 보통 셋 중 하나입니다. 검색엔진의 공식 문서, 도구가 정해 둔 기본값, 우리 팀의 편집 규칙입니다.
| 지적된 항목 | 기대값은 어디서 왔나 | 그래서 어떻게 읽나 |
|---|---|---|
| title 태그 없음 | 공식 권고 | 근거가 분명한 오류 |
| 제목·설명이 길다 | 도구의 기본 글자 수 | 뜻이 통하면 둬도 됩니다 |
| H1 이 두 개 | 우리 편집 규칙 | 규격 위반은 아닙니다 |
| canonical 불일치 | 공식 설명(힌트) | 우리 표기를 읽은 값 |
| noindex 있음 | 공식 동작 정의 | 의도한 비공개면 예외 |
공식 권고가 근거인 줄은 그대로 넘깁니다. Google 문서는 사이트의 모든 페이지에 title 요소로 제목을 지정하라고 적습니다.
글자 수 지적은 성격이 다릅니다. 같은 문서는 제목 요소의 길이에 상한이 없고 검색 결과에서 보통 화면 폭에 맞춰 잘린다고만 설명하며, 설명(description)도 길이 제한이 없고 필요하면 잘린다고 적습니다. 몇 자 초과라는 선은 도구가 정한 것입니다. 쓰는 기준은 H1 구조와 페이지 제목에 있습니다.
H1 개수도 우리 쪽 규칙입니다. HTML 규격은 제목이 하나 이상 있는 문서라면 그중 적어도 하나가 레벨 1이어야 한다고 권하는 선까지이고, 몇 개까지인지는 정하지 않습니다.
canonical 지적은 canonical 태그 설정법에서 다룬 대로 표기가 힌트입니다. 공식 문서는 대표주소를 중복 집합에서 Google이 가장 대표적이라고 고른 주소로 정의하고, 우리가 적은 것과 다른 쪽을 고를 수 있다고 적습니다.
도구가 받은 응답은 그 시점의 응답입니다
기대값의 출처가 분명해도 발견값이 지금도 같은지는 별개입니다. 지적 하나를 확인할 때 같은 입력으로 다시 받아 봅니다.
- 결과에 적힌 주소를 그대로 씁니다. 끝 슬래시와 대소문자, 쿼리까지 같아야 합니다.
- 그 주소의 응답을 받아 지적된 값만 찾습니다.
- 값이 다르면 시점 차이인지 조건 차이인지 적습니다.
다르게 나오는 흔한 이유는 캐시, 로그인 뒤에만 열리는 페이지, 자바스크립트로 나중에 채워지는 값입니다. 색인 쪽은 한 가지가 더 있습니다. Google 문서는 meta 태그와 HTTP 헤더를 보려면 페이지를 수집해야 한다고 적습니다. 표기를 고쳐도 다시 수집되기 전에는 검색엔진 쪽 상태가 그대로입니다. 영역별 확인 순서는 기술 SEO 진단이란?에 있습니다.
문제·해당 없음·확인 못 함을 한 칸에 섞지 않습니다
줄마다 상태를 정할 때 세 가지를 구분합니다.
- 문제 — 출처가 분명한 기대값과 발견값이 다릅니다.
- 해당 없음 — 그 기대값이 이 주소에 적용되지 않습니다.
- 확인 못 함 — 도구가 그 주소를 받지 못했거나 값을 읽지 못했습니다.
세 번째를 통과로 적으면 다음 진단에서 비교할 수 없게 됩니다. 재지 못한 항목을 0으로 적지 않는 이유는 화이트라벨 보고서 구성에서 다뤘습니다. 확인 못 함은 빈 칸으로 두고 왜 읽지 못했는지를 한 줄 붙입니다.
예외는 의도가 아니라 적용되지 않는 이유로 적습니다
해당 없음으로 돌릴 줄에는 근거가 남아야 다음 진단에서 또 올라오지 않습니다.
관리 화면은 로그인한 사람만 쓰는 페이지라 색인 대상이 아닙니다. 이 경로의 noindex 지적은 해당 없음입니다. (2026-10-15 확인)
반대로 출처가 공식 문서인 줄은 예외로 돌리지 않습니다. 근거가 그대로 남아 있으니 다음 진단에서 같은 지적이 다시 올라오고 예외 목록만 길어집니다. 예외를 작업 상태와 함께 관리하는 방법은 결과를 수정 작업으로 연결하기에 있습니다.
다 읽었는지 확인하는 방법
목록을 덮기 전에 줄마다 네 가지가 채워졌는지 봅니다.
- 기대값의 출처가 셋 중 무엇인지 적혀 있다
- 발견값을 직접 다시 받아 본 날짜가 있다
- 상태가 셋 중 하나로 정해져 있다
- 문제로 남긴 줄에는 무엇을 보면 해결된 것인지가 적혀 있다
네 칸이 다 차도 수정이 끝났다는 뜻은 아닙니다. 어느 지적을 왜 고치고 왜 두는지가 정해졌다는 뜻입니다. 고친 뒤 반영은 공개된 주소의 응답을 다시 받아 확인해야 하고, 그것까지 끝나도 검색 결과의 위치는 별개 문제입니다. 지금 가장 중요한 주소 하나의 결과를 열어 기대값의 출처부터 적어 보세요.