SEO 진단 결과에 경고가 많다고 해서 모든 권고를 그대로 실행할 필요는 없습니다. 먼저 확인할 것은 그 경고가 실제 페이지와 맞는지, 제안된 수정이 페이지의 목적에 적절한지입니다. 관측은 맞아도 ‘필수 수정’이라는 해석은 맞지 않을 수 있습니다.
이 글은 2026년 8월 28일 SearchTune OS와 Inblog 블로그의 작업·검증 기록을 정리한 자사 사례입니다. 이번 원고 작성을 위해 새로 진단하거나 성능을 측정한 결과가 아닙니다. 수정한 부분뿐 아니라 하지 않은 일과 끝내 검증하지 못한 부분을 함께 설명합니다.
TL;DR
목록 8개의 JS 의존 판정과 실제 H1 부재를 구분했습니다.
38개 글의 스키마와 FAQ를 실제 본문에 맞추고 원본 보존을 검증했습니다.
앱의 로컬 성능 결과, 블로그 성능 보류와 도구 재진단 미완료는 별개입니다.
진단 결과를 왜 다시 확인해야 하나요?
Google은 2026년 6월 5일 수정한 공식 안내에서 외부 SEO 조언을 공식 지침과 대조하라고 권합니다. 제3자 도구는 Google 내부 순위 데이터에 접근할 수 없으며 성과를 보장할 수 없다고도 설명합니다. 진단 도구를 쓰지 말라는 뜻이 아니라, 관측값과 해석·예측을 구분하라는 기준으로 읽을 수 있습니다. Google의 외부 SEO 도구 안내
이번 작업에서도 경고 목록을 곧바로 수정 목록으로 바꾸지 않았습니다. 대상 URL을 열고 실제 제공되는 내용을 확인한 뒤, 아래와 같이 판정을 나눴습니다.
| 판정 | 실제 사례 | 다음 조치 |
|---|---|---|
| 실제 누락 | 목록 페이지의 H1 부재 | 해당 목록에서만 보완하고 공개 화면 확인 |
| 오탐·과도한 해석 | 제목·요약·링크가 초기 HTML에 있는 목록을 JS 의존으로 단정 | 관측 근거를 남기고 대규모 재구축은 하지 않음 |
| 실제 부재지만 선택 사항 | 목록용 스키마 미적용 | 없다는 사실과 일괄 필수라는 주장을 분리 |
| 플랫폼 제약 | Inblog가 관리하는 핵심 번들·필수 스타일 | 직접 바꿀 수 있는 범위와 플랫폼 관리 범위 구분 |
| 검증 미완료 | 불완전한 성능 보고서·재진단 한도 소진 | 완료라고 표시하지 않고 필요한 재검증 기록 |
‘수정하지 않음’은 하나의 상태가 아닙니다. 문제가 없어서 유지한 것인지, 선택 사항을 보류한 것인지, 문제가 있어도 아직 검증하지 못한 것인지 구분해야 다음 담당자가 판단을 이어갈 수 있습니다.
같은 목록에서 오탐과 실제 오류를 어떻게 나눴나요?
당시 블로그 목록과 카테고리 목록을 포함한 8개 URL에 ‘JS 의존 페이지’ 지적이 있었습니다. 그러나 초기 HTML에서 실제 글 제목·요약·링크를 확인할 수 있었습니다. 글 본문이 길게 들어 있지 않은 목록을 정적 콘텐츠가 없는 페이지로 단정할 근거는 부족했습니다.
따라서 이 지적을 이유로 사이트 전체를 다시 만들거나 호스팅을 이전하지 않았습니다. 빈 카테고리 3개는 기존 글을 추가 분류하는 별도 조치로 보완했습니다. 목록의 카드와 이미지 비율도 유지했습니다.
반면 같은 목록의 H1 부재는 실제 보완 대상이었습니다. 기존 스타일에 맞춘 20px 제목 한 줄을 목록에만 추가하고, 8개 모두 초기 HTML과 브라우저 화면에서 확인했습니다. 공통 헤더나 게시글·작성자 페이지에 추가 H1을 넣지는 않았습니다.
핵심은 ‘이 페이지에 문제가 있다’는 넓은 판단 대신 무엇이 없고 무엇은 이미 있는지를 나눠 보는 것입니다. 초기 HTML 확인 역시 모든 검색엔진의 색인 성공을 증명하는 것은 아닙니다. 이번 사례에서는 해당 경고가 실제 상태를 정확히 설명하는지를 판단하는 근거로 사용했습니다.
구조화 데이터는 많이 넣을수록 좋은가요?
지적된 글 38개에는 실제 제목·URL·대표 이미지·최초 발행일에 맞는 BlogPosting을 적용했습니다. BlogPosting은 Article의 하위 타입이므로 같은 글을 설명하는 Article을 중복해서 추가하지 않았고, 확인되지 않은 저자도 만들어 넣지 않았습니다. Schema.org의 BlogPosting 정의
FAQ도 개수가 아니라 본문 대응을 기준으로 정리했습니다. 기존 구조화 데이터의 질문·답변 127쌍 중 실제 본문에 대응하는 34쌍만 유지했습니다. 이는 본문에서 질문 93개를 지웠다는 뜻이 아니라, 코드에 들어가는 설명을 실제 페이지 내용과 맞춘 작업입니다. Google도 독자에게 보이지 않는 내용이나 무관한 내용을 구조화 데이터로 표시하지 말라고 안내합니다. 구조화 데이터 일반 지침
목록용 CollectionPage와 목록의 BreadcrumbList는 추가하지 않았습니다. 실제로 없다는 사실은 남기되, 모든 페이지의 SEO·AI 검색 필수 요건으로 받아들이지는 않았습니다. Google의 AI 최적화 가이드 역시 생성형 검색을 위한 특별한 스키마를 요구하지 않으며 기본 SEO 원칙을 강조합니다. 이 설명은 Google 검색에 관한 것입니다. Google AI 최적화 가이드
38개 검증 통과는 해당 스키마·메타의 정합성을 확인했다는 의미입니다. 기존 글 전체의 사실성이 검증됐거나 검색 노출을 보장한다는 뜻은 아닙니다.
💡 잠깐, 우리 사이트도 점검해 볼까요?
서치튠의 URL 진단으로 사이트 구조와 콘텐츠의 준비도를 살펴보고, 결과를 실제 오류·선택 사항·확인 필요로 나눠 보세요. 점수는 검색 순위나 AI 인용을 보장하지 않습니다.
고친 부분만큼 원본 보존도 어떻게 확인했나요?
변경 전에는 본문, 제목, URL, 최초 발행일, 대표 이미지, 분류와 디자인 정보를 보관했습니다. 저장 성공만 보고 끝내지 않고 변경 후 공개 페이지를 다시 읽어 보존 대상과 비교했습니다.
당시 기존 글 178개의 최초 발행일과 대표 이미지는 모두 유지됐습니다. 본문 HTML을 구분하는 해시값은 174개에서 같았고, 4개는 승인된 형식 복구 시범 1개와 문단 보완 3개로 달라졌습니다. 따라서 ‘모든 본문을 그대로 유지했다’고 쓰지 않았습니다.
특히 시범 글 하나는 편집기를 여는 과정에서 HTML이 자동 정규화됐습니다. 다른 구형 글로 편집을 확대하지 않고, 해당 글만 승인된 범위에서 표·체크박스·소제목 형식을 복구했습니다. 원래 텍스트와 URL·제목·날짜·이미지는 유지했지만 HTML 바이트까지 동일하다고 보고하지 않았습니다.
원본 보관은 복구 파일 하나를 만드는 데서 끝나지 않습니다. 어떤 차이가 승인된 수정이고, 어떤 차이는 예상하지 못한 변화인지 설명할 수 있어야 합니다. 문제가 생겼을 때도 현재 상태와 대조해 변경한 필드나 문단만 복구할 기준을 남기는 편이 안전합니다.
앱이 개선됐는데 블로그 성능은 왜 완료가 아니었나요?
같은 도메인에 있어도 앱과 Inblog 글은 제공되는 코드와 수정 범위가 달랐습니다. 한쪽에서 얻은 성능 결과를 다른 쪽의 해결 근거로 사용하지 않았습니다.
| 대상 | 당일 기록에서 확인한 결과 | 완료라고 말하지 않은 부분 |
|---|---|---|
| 앱 홈 | 동일한 로컬 모바일 조건에서 전후 각 3회 비교. 초기 정적 JavaScript gzip 용량 314,381→226,423바이트, 27.98% 감소 | 실제 방문자의 체감속도가 27.98% 빨라졌다는 뜻은 아님 |
| Inblog 글 | 중복 전체 폰트 요청 제거, 같은 버전의 분할 폰트와 글자 배치 유지 | 정한 전후 성능 비교 조건의 완전한 충족·실사용 INP 개선 |
| 후속 확인 | 직접 HTTP·렌더 검증 기록 확보 | 한도 소진으로 하지 못한 진단 도구 재진단의 새 점수 |
앱 비교는 확장 없는 브라우저, 412×823 화면, DPR 1.75, CPU 4배 감속, Slow 4G, 캐시·서비스워커 우회 조건이었습니다. 이는 통제된 로컬 실험이며 공개 사용자 전체의 경험을 대표하지 않습니다.
반면 Inblog 지식 패널 글은 변경 전의 유효한 독립 성능 보고서가 2개뿐이었고, 전후 보고서 모두 불완전할 수 있다는 경고가 있었습니다. 측정 환경 차이도 남아 있어, 이번 작업에서 정한 전후 각 3회 성능 완료 기준을 통과했다고 표시하지 않았습니다.
당시 사용 중인 플랜의 진단 한도도 소진돼 재진단은 미완료였습니다. 직접 확인한 폰트 요청 제거와 구조 개선은 기록하되, 새 진단 점수나 검색 순위·AI 인용 상승을 만들어 보고하지 않았습니다. 이는 당시 상태이며 이후의 계정 한도까지 설명하는 것은 아닙니다.
내 사이트에서는 어떤 순서로 판정하면 되나요?
이번 사례의 작업 흐름은 다음 다섯 단계로 정리할 수 있습니다.
원문 보관: 경고 문구와 측정 날짜·기기·지역·도구 조건을 함께 저장합니다.
URL 연결: 앱·글·목록 중 어떤 페이지인지, 실제 제공·수정 주체가 누구인지 확인합니다.
실제 확인: 초기 HTML, 렌더 화면, 원문 콘텐츠와 구조화 데이터를 대조합니다. 접근 실패는 정상으로 처리하지 않습니다.
최소 조치: 바꿀 필드와 보존할 필드를 먼저 정하고, 위험한 편집은 한 페이지에서 확인한 뒤 확대합니다.
공개 검증: 같은 URL을 다시 열어 수정 내용과 원본 보존을 검사합니다. 도구 재진단이나 성능 측정이 미완료면 별도 상태로 남깁니다.
이 흐름은 ‘경고가 사라졌는가’와 ‘필요한 문제가 해결됐는가’를 나눠 확인하게 해 줍니다. 관측이 맞는지부터 살피면, 수정하지 않은 이유도 검증 가능한 작업 결과가 됩니다.
✅ 실행 체크리스트
- 경고 원문을 정확한 URL과 측정 조건에 연결했습니다.
- 실제 오류·오탐·선택 사항·플랫폼 제약·미검증을 구분했습니다.
- 본문·URL·최초 발행일·이미지·분류의 원본을 보관했습니다.
- 구조화 데이터가 실제 보이는 내용과 대응하는지 확인했습니다.
- 수정한 필드와 의도하지 않은 차이를 공개 페이지에서 다시 검사했습니다.
- 직접 확인 결과, 도구 재진단, 실사용 성과를 별도로 기록했습니다.
관련 글과 확인한 출처
후속 점검은 브랜드 준비도 체크리스트, 근거 정리는 AI 답변 출처 검증표에서 이어갈 수 있습니다.
사례의 수치와 조치는 2026년 8월 28일 작업·검증 기록의 집계입니다. 본문에 연결한 Google 공식 지침과 Schema.org 문서는 판정 원칙의 근거이며, 자사 작업이나 성과를 외부 기관이 인증했다는 뜻은 아닙니다.