기존 사이트를 진단하고 수정 순서를 정하기

공개 범위와 URL 목록을 확정한다

검색에 없는 페이지를 모두 같은 방법으로 고치면 원인이 남을 수 있다. 링크가 없어 발견되지 않은 글에는 발견 경로가 필요하고, noindex가 있는 글에는 색인 지시 수정이 필요하며, 본문에 답이 없는 글에는 내용 보강이 필요하다. 먼저 같은 URL의 실제 응답과 검색 처리 기록을 비교해 어느 단계에서 자료가 빠졌는지 찾는다.

운영 담당자와 공개·검색 포함 범위를 먼저 정한다. 공개 정책이 모든 공개 콘텐츠의 검색 허용이라면, 기사·공지·소개·사진 설명 같은 콘텐츠 종류만으로 noindex를 추가하지 않는다. 로그인 자료, 초안, 예약 공개 전 자료, 철회한 글은 별도 상태로 구분한다. 검색 제외와 접근 제한은 서로 다른 설정이므로 비공개 자료는 인증·권한으로 보호한다.

콘텐츠 저장소나 CMS에서 공개 URL을 뽑고, 사이트맵과 실제 메뉴·본문 링크에서 발견한 URL을 대조한다. 사이트맵만 조사하면 사이트맵에서 빠진 글을 찾을 수 없다. 목록·상세·페이지 나누기·이미지·첨부 파일처럼 경로의 종류를 함께 적는다. 본문 링크도 사이트맵도 없는 공개 글은 연결을 추가할 후보가 된다.

URL마다 콘텐츠 ID, 유형, 공개 상태, 기대 응답 코드, 대표 주소, 공개일·실질 수정일, 관련 질문을 기록한다. 표본 확인은 각 템플릿의 대표 URL로 시작하되, 최종 대조는 대상 전체 목록에 적용한다. 초안·철회·없는 주소도 별도 표본으로 넣어 공개 글과 섞이지 않는지 확인한다.

배포 전 기준선과 관측표를 만든다

관측 시작 전에 대상 URL과 질문을 고정한다. 배포 전 기록이 있다면 같은 집합으로 비교하고, 없으면 첫 관측을 기준선으로 삼는다. URL이 늘어나거나 질문을 바꾸면 버전을 나눠 추가분을 표시한다. 전체 값 하나만 비교하면 새 콘텐츠 증가와 기존 페이지 개선을 구분하기 어렵다.

기술 기록은 사이트가 실제로 반환한 응답을 남긴다. 검색 기록은 검색엔진이 마지막으로 처리한 상태를 남긴다. AI 기록은 한 질문에 받은 답변과 인용을 남긴다. 같은 URL이어도 세 기록의 시각이 다를 수 있으므로 각 원문을 관측 시각과 함께 보존한다. 아래는 처음의 도서관 오류를 기록하는 가상 예다.

배포 직후에는 새 본문과 대표 주소가 응답에 반영됐는지 확인한다. 이후 검색·AI 관측에서는 최근 수집일과 인용한 문서의 날짜를 읽는다. 수정 전 자료가 남아 있는지에 따라 재수집을 기다릴지, 문서의 기간 설명을 더 고칠지 결정한다.

초기 구축·개편·새 기능 추가의 범위를 나눈다

초기 구축에서는 공개 URL과 기본 본문, 페이지별 제목·설명·대표 주소, robots, 사이트맵, 검색 속성 등록을 만든다. 개편할 때는 이전 URL의 이동·보존 방식, 현재·과거 정보의 구분, 새 데이터 조회의 공개 조건도 조사한다.

새 메뉴나 화면 영역을 추가하면 먼저 “이 영역이 어떤 콘텐츠를 어디서 읽고, 상세로 어떻게 연결하는가”를 적는다. 추가한 영역의 최초 응답에 본문·제목·상세 링크·이미지·원문 출처가 있는지 확인한다. 탭·캐러셀·스크롤 뒤에만 나타나는 자료는 브라우저 동작과 수집 가능한 경로를 함께 본다.

서버 응답과 브라우저 화면을 함께 수집한다

다음은 macOS·Linux 셸에서 실행하는 읽기 전용 조사 예시다. example.com은 설명용 도메인이다. 작업 대상 주소로 바꾸고, 페이지에는 공개 상세 글 하나를 지정한다. 쿠키나 관리자 인증을 넣지 않은 상태에서 시작한다.

AUDIT_ORIGIN='https://example.com' AUDIT_PAGE="$AUDIT_ORIGIN/guides/opening-hours" mkdir -p seo-audit curl -sS -D seo-audit/page.headers -o seo-audit/page.html "$AUDIT_PAGE" curl -sS "$AUDIT_ORIGIN/robots.txt" -o seo-audit/robots.txt curl -sS "$AUDIT_ORIGIN/sitemap.xml" -o seo-audit/sitemap.xml

첫 요청에서는 리다이렉트를 자동으로 따라가지 않았다. 헤더 파일에서 상태 코드·Location·X-Robots-Tag·Content-Type을 읽는다. 3xx이면 다음 명령으로 최종 주소와 리다이렉트 횟수도 기록한다. 정상 대표 주소는 로그인 화면이 아닌 의도한 공개 본문을 반환해야 한다.

curl -sS -L -o /dev/null -w 'status=%{http_code} redirects=%{num_redirects} final=%{url_effective}\n' "$AUDIT_PAGE" rg -n -i 'noindex|canonical|<title|application/ld\+json' seo-audit/page.html

rg는 파일 안에서 문자열을 찾는 검색 명령이다. 결과에서 발견한 설정의 위치를 찾는다. 한 줄짜리 HTML이나 JavaScript 문자열도 잡을 수 있으므로 실제 태그와 본문을 구분해 읽는다. 브라우저에서는 새 비로그인 창으로 같은 주소를 열고 본문·사진·링크를 확인한다. HTML에 답변 문장이 없고 로딩 표시만 있으면, 데이터가 어느 단계에서 들어오는지 렌더링 구성의 데이터 조회 절차로 추적한다. Google의 JavaScript 처리 안내를 함께 참고한다.

이 명령으로 저장한 HTML에 휴관일이 없고 브라우저 화면에는 있다면, 두 결과 사이의 JavaScript 실행과 데이터 요청을 조사할 수 있다. 둘 다 휴관일이 없다면 원고나 서버 조회를 고쳐야 한다. 이 차이를 확인하면 검색 노출이 적다는 이유만으로 프레임워크부터 바꾸는 일을 줄일 수 있다.

정적 사진과 CMS 사진을 하나씩 골라 같은 폭의 화면에서 연다. 정적 사진 요청은 폭이 포함된 변환 주소인데 CMS 사진 요청은 원본 주소라면, CMS 필드에서 img.src까지 이어지는 경로를 추적한다. 두 사진의 CSS 폭만 비교하면 서버가 몇 바이트를 보내는지 알 수 없다. CMS 이미지 실습의 원본 보기와 파생본 보기는 같은 자료·같은 배치를 사용하므로 전송 방식의 차이를 비교할 수 있다.

증상을 수정 위치에 연결한다

저장소에서는 아래 검색으로 설정이 만들어지는 위치부터 찾는다. 경로명은 프로젝트 구조에 맞춰 조정한다. 검색 결과에 나타난 기본값뿐 아니라 페이지별 재정의, 응답 헤더, 배포 환경 설정까지 따라간다. 같은 noindex가 HTML과 HTTP 헤더에 동시에 있을 수 있다.

rg -n 'noindex|X-Robots-Tag|generateMetadata|canonical' src app public rg -n 'sitemap|robots|dateModified|datePublished|application/ld\+json' src app public rg -n 'published|visibility|deletedAt|publishedAt' src app

외부 피어리뷰가 있다면 원본의 대상 URL·시점·조건·관측값을 먼저 옮긴다. 지적을 실제 응답과 코드에서 재현한 뒤 수정 위치를 연결한다. 현재 구현에서 이미 고친 항목, 아직 남은 항목, 운영 정책에 맞지 않아 채택하지 않은 제안을 구분한다. 성능 지적은 같은 페이지·기기·네트워크 조건에서 수정 전후를 측정해 비교한다.

사진이 느린 이유도 요청 시점에 따라 달라진다. HTML에 주소가 늦게 생기면 렌더링·데이터 조회를 보고, 주소는 일찍 생겼지만 다운로드가 길면 이미지 용량과 연결을 본다. 다운로드 후 표시까지 오래 걸리면 메인 스레드 작업과 디코딩을 확인한다. 이 순서로 좁히면 프레임워크 전체를 바꾸기 전에 수정할 위치를 찾을 수 있다.

수정 순서와 판단 근거를 정한다

먼저 비공개 자료의 노출, 공개 글의 접근 실패, 광범위한 잘못된 noindex·대표 주소처럼 대상 전체에 영향을 주는 문제를 처리한다. 그다음 누락 본문·끊긴 링크·잘못된 날짜와 사실을 고친다. 제목·요약·표·이미지 설명은 이용자가 답을 찾기 어려운 페이지부터 다듬는다. 외부 답변 관측은 수정 전 기준선을 한 번 남기고 배포 후 같은 조건으로 이어간다.

각 과제는 “URL / 증상 / 원본 응답 또는 화면 / 원인 위치 / 수정 / 통과 조건 / 재관측 질문”으로 기록한다. 예를 들어 공개 상세 글에 공통 레이아웃의 noindex가 내려오면, 해당 기본값과 공개 페이지 재정의를 고친 뒤 정상 글·초안·없는 주소를 함께 확인한다. 근거가 아직 없는 추측은 조사 항목으로 남겨 수정 과제와 구분한다.

Google의 생성형 검색은 기본 검색 품질과 기술 요건을 사용한다. 먼저 공개 본문·접근·출처를 고친다. llms.txt를 읽는 별도 도구를 운영한다면 그 도구에 전달할 내용과 갱신 시점을 정한다. 생성형 검색 최적화 안내

다음 단계에 넘길 자료

진단이 끝나면 질문–URL 목록, 공개 상태표, 응답·화면 기록, 우선순위가 있는 수정 목록을 남긴다. 수정 담당자는 이 자료에서 코드 위치와 통과 조건을 바로 찾을 수 있어야 한다. 외부 보고서에 접근할 수 없으면 접근 가능한 항목과 아직 관측하지 못한 항목을 기록한다. 값을 비워 둔 이유도 다음 관측자가 이해할 수 있게 적는다.

진단 목록의 각 항목에 수정할 파일·설정·콘텐츠와 기대 응답을 연결한다. 렌더링을 바꿀 항목은 데이터의 갱신 빈도와 공개 조건부터 정하고, 주소 문제는 대표 URL과 이전 주소 대응표부터 정한다. 수정 후에는 같은 URL과 질문으로 다시 확인한다.

가상 도서관의 세 증상을 수정 과제로 바꾼다

운영 시간 상세 주소를 비로그인 상태로 요청해 본문을 저장한다. 로딩 표시만 있다면 페이지 조회 시점을 조사한다. canonical이 홈이면 상세 메타데이터 생성 위치를 찾는다. 이전 시간표를 현재 질문에 사용할 수 있는지 날짜와 적용 기간을 대조한다.

아래 표는 가상 도서관의 세 오류와 수정 위치를 연결한다. 응답 HTML, canonical 값, 과거 안내의 본문을 나란히 읽으면 필요한 변경을 구분할 수 있다.

기술 결함과 콘텐츠 결함의 근거를 나눈다

같은 “검색 유입이 적다”는 증상에도 원인이 다르다. 서버 응답에 본문이 없으면 전달 경로를, 질문에 필요한 신청 조건이 없으면 원고를, 신청 버튼 뒤 오류가 나면 전환 경로를 조사한다. 키워드 조사와 실제 문의에서 찾은 질문을 진단표에 포함하고, 각 페이지가 그 질문에 답하는지 확인한다.

기준선에는 대상 질문·URL·게시본·적용 기간과 관측 시각을 함께 남긴다. 지금의 화면과 한 달 전 검색 보고서를 직접 비교하지 말고, 실제로 어느 원고가 노출됐을 수 있는지 확인한다. 검색 의도별 지도의 문서 역할을 기준으로 누락을 찾는다.

색인은 됐지만 생성형 답변에 보이지 않는 경우를 좁힌다

가상 운영 시간 안내가 URL 검사에서 색인으로 표시돼도 본문의 휴관 조건이 답변에 빠질 수 있다. 먼저 해당 응답의 실제 인용 URL을 저장한다. 현재 운영 시간 안내를 인용했다면 본문에 예외가 있는지와 nosnippet·data-nosnippet으로 가려졌는지를 읽는다. 과거 기록을 인용했다면 기간과 현재 안내 링크를 대조한다. 인용 자체가 없으면 Search generative AI 참여 설정과 질문에 대응하는 내용을 확인한다.

진단표에는 질문과 인용 주소를 함께 적는다. URL 검사에서 읽은 최근 수집일과 스니펫 지시도 붙인다. 예를 들어 AI가 2025년 안내를 인용했다면 그 문서의 적용 기간과 현재 안내 링크를 먼저 살핀다. 현재 안내를 인용하면서 휴관일을 빠뜨렸다면 해당 문장과 예외 설명을 대조한다.

예를 들어 검색 도구의 마지막 수집일이 10월 20일이고 휴관 조건을 24일에 추가했다면, 20일 자료로 만든 답변에는 새 조건이 없을 수 있다. 24일 이후 자료를 인용하면서도 예외가 빠졌다면 답과 조건의 배치, 인용한 구절, 질문 해석을 다시 본다. 수집 날짜를 비교하는 이유는 수정이 아직 전달되지 않은 경우와 전달된 내용을 잘못 사용한 경우를 나누기 위해서다.