Chrome DevTools로는 안 보이는 공개 URL 점검

브라우저에서 보인다고 끝난 게 아니었다

Chrome DevTools는 빠르고 정확하다. 요청이 어떤 status로 끝났는지, 어떤 JavaScript가 실패했는지, 어떤 header가 붙었는지 바로 볼 수 있다. 그런데 사이트를 검색에 맡기는 순간 DevTools만으로는 부족해진다. 내가 보고 있는 것은 내 브라우저의 세션이고, 검색엔진이 보는 것은 공개 URL의 최종 응답이다.

로컬 개발 서버에서 `/blog`가 잘 열려도 production sitemap에 빠져 있을 수 있다. DevTools Network 탭에서 200이 보여도 apex에서 www로 가는 redirect가 플랫폼 앞단에서 다르게 응답할 수 있다. HTML source에 canonical이 있어도 Search Console이 마지막으로 읽은 sitemap은 예전 숫자일 수 있다. 이런 차이를 섞으면 "사이트는 되는데 왜 색인이 안 되지?"라는 질문만 반복하게 된다.

그래서 bobob.app의 개발자도구 방향도 단일 변환기 묶음이 아니라 공개 URL 점검 흐름으로 바꿨다. URL status, redirect chain, response headers, DNS, sitemap, robots, canonical/meta, URL shape를 한 번에 엮어야 DevTools에서 보이는 페이지와 crawler가 받는 페이지를 나눠 볼 수 있다.

내가 먼저 나누는 표

이 표를 만든 뒤로는 같은 "200"도 다르게 적는다. 로컬 200, production 200, Googlebot fetch 성공, Search Console discovered pages는 서로 다른 줄이다. 줄을 섞으면 고칠 곳도 섞인다. 특히 작은 사이트는 데이터가 적어서 한 번 잘못 섞은 기록이 며칠 동안 판단을 흐린다.

DevTools가 강한 구간

DevTools를 버리자는 뜻은 아니다. 입력 폼이 깨졌는지, client bundle이 실패했는지, CSS가 늦게 붙는지, hydration warning이 있는지는 DevTools가 제일 빠르다. 내가 버튼을 눌렀을 때 어떤 request가 나가는지, response body가 어떻게 생겼는지, 로컬 스토리지에 무엇이 남는지도 여기서 본다.

다만 DevTools는 지금 내 탭에서 일어난 일을 잘 보여준다. Search Console의 URL Inspection이 보는 Googlebot smartphone fetch, Bing Webmaster의 recommendation, Naver Search Advisor의 sitemap 상태는 다른 표면이다. 내 탭이 로그인되어 있거나 캐시가 따뜻하거나 locale cookie를 들고 있으면 crawler와 더 멀어진다.

이 차이 때문에 운영 도구는 "내 브라우저에서 됨"을 "공개 URL이 검색에 준비됨"으로 바로 번역하면 안 된다. 중간에 공개 status, redirect, canonical, robots, sitemap, feed, webmaster tool 상태를 끼워 넣어야 한다.

공개 URL 점검 순서

• - 먼저 canonical host에서 URL이 final 200으로 끝나는지 본다.
• - redirect chain에 임시 redirect, 다른 host, 불필요한 hop이 섞이지 않는지 본다.
• - response header에서 content-type, cache-control, security header를 확인한다.
• - sitemap에 들어간 URL이 실제 final 200 HTML인지 확인한다.
• - robots.txt가 sitemap index를 가리키고 public content를 막지 않는지 본다.
• - meta robots와 canonical이 제출하려는 URL과 같은 방향인지 본다.
• - URL query, tracking parameter, hash, mixed host를 정리한다.
• - Search Console은 반드시 맞는 계정과 property에서 본다.
• - 제출, 발견, 색인, 노출, 클릭을 같은 성공 단어로 합치지 않는다.

이 순서는 느려 보이지만 실제로는 시간을 줄인다. Search Console에서 "크롤링됨 - 현재 색인이 생성되지 않음"을 봤을 때도 바로 제목을 고치지 않는다. 이 문구는 크롤링 실패가 아니라 Google이 페이지를 가져온 뒤 아직 색인에 넣지 않은 상태다. 먼저 sitemap에 들어갔는지, fetch가 성공했는지, canonical이 맞는지, noindex가 없는지 본다. 그 다음에 본문 품질과 title/description을 본다.

Search Console은 계정부터 확인한다

Search Console에서 `이 속성에 액세스할 수 없습니다`가 보이면 색인 상태를 본 것이 아니다. 다른 Google 계정으로 열린 화면, 다른 property, 로그인 도중 멈춘 패스키 확인 화면은 모두 운영 관찰에서 제외해야 한다. 같은 브라우저에서 Google 서비스가 열려 있어도 Search Console property 권한은 별개다.

그래서 Search Console을 여는 순서는 계정, property, sitemaps row, Page indexing report, URL Inspection 순서다. 첫 줄에서 막히면 그날의 결론은 "색인 상태가 그대로"가 아니라 "유효한 Search Console 관찰을 못 했다"다. 이 차이를 적어야 불필요한 코드 수정이나 sitemap 반복 제출을 막을 수 있다.

캐시는 내 탭과 public response를 갈라놓는다

배포 뒤에 "나는 새 화면을 보는데 검색엔진이나 다른 브라우저는 예전 화면을 본다"는 말이 나오면 먼저 캐시를 의심한다. DevTools Network 탭은 현재 탭의 memory cache, disk cache, service worker, conditional request를 같이 보여줄 수 있다. 반대로 공개 URL checker는 서버가 지금 외부 요청에 돌려주는 status, redirect chain, `cache-control`, `etag`, `last-modified`, `x-vercel-cache`, `cf-cache-status` 같은 header를 남긴다.

이 둘은 역할이 다르다. DevTools에서 disable cache를 켜고 새로고침해도 CDN edge가 `HIT`나 `STALE`을 줄 수 있고, public checker에서 200을 받아도 내 브라우저가 `304 Not Modified`로 기존 asset을 재사용할 수 있다. 그래서 cache 문제는 "새로고침했는데 그대로"가 아니라 어느 층이 그대로인지로 적어야 한다.

그래서 `캐시 헤더 확인`, `304 확인`, `x-vercel-cache 확인`, `cf-cache-status 확인`, `배포 후 캐시 확인` 같은 검색은 HTTP Status Checker로 보내되, 그 도구가 캐시를 지운다고 말하지 않는다. 하는 일은 public response evidence를 잡는 것이다. 캐시를 실제로 비우는 일은 hosting platform, CDN, browser, service worker 쪽에서 한다.

리디렉션 사유를 볼 때 먼저 가르는 것

Search Console의 `리디렉션이 포함된 페이지`는 항상 나쁜 신호가 아니다. `http://`가 `https://`로 가거나, apex host가 `www` canonical host로 308 이동하는 것은 정상적인 정리일 수 있다. 문제는 제출한 URL이 final 200 대표 URL이 아니라 중간 redirect URL이거나, hop이 많거나, canonical이 다른 host/path를 가리키거나, 루프처럼 같은 URL 주변을 반복할 때다.

그래서 `www 리디렉션 확인`, `308 리디렉션 확인`, `리디렉션 루프 점검` 같은 검색은 단일 status code가 아니라 redirect chain, DNS target, canonical 후보를 이어서 봐야 한다. 좋은 redirect는 대표 URL을 하나로 모은다. 나쁜 redirect는 검색엔진이 색인할 URL을 고르기 전에 길을 잃게 만든다.

canonical 중복 사유는 URL 모양부터 맞춘다

Search Console에서 `사용자가 선택한 표준이 없는 중복 페이지`나 `적절한 표준 태그가 포함된 대체 페이지`를 보면 먼저 화낼 일이 아니라, Google이 어떤 URL 묶음을 같은 페이지로 보고 있는지부터 갈라야 한다. 이 사유는 곧바로 "망했다"가 아니다. 일부 alternate URL은 의도한 canonical로 모였다는 뜻일 수 있고, 일부 duplicate URL은 sitemap이나 내부 링크가 흔들렸다는 뜻일 수 있다.

여기서 중요한 것은 canonical tag 하나만 보고 끝내지 않는 것이다. Google은 canonical tag를 신호로 보지만, sitemap, redirect, 내부 링크, 페이지 내용, URL 모양도 같이 본다. 그래서 `표준 URL 불일치`, `중복 표준 URL 확인`, `사용자가 선택한 표준이 없는 중복 페이지` 같은 검색은 URL Parser, Meta Tag Generator, Sitemap Generator를 한 줄로 이어야 한다.

내가 남길 기록은 짧아도 된다. inspected URL, user-declared canonical, Google-selected canonical, sitemap 포함 여부, final status, redirect chain, query/tracking/hash 차이만 적어도 다음 행동이 정해진다. canonical이 맞고 alternate가 의도된 것이라면 기다린다. canonical이 없거나 제출 URL이 흔들렸다면 sitemap과 내부 링크부터 줄인다.

미색인 URL을 볼 때 남기는 증거

Search Console이 `크롤링됨 - 현재 색인이 생성되지 않음`이나 `발견됨 - 현재 색인이 생성되지 않음`을 보여주면, 내가 먼저 여는 흐름은 `/search?q=crawled%20currently%20not%20indexed`다. 이 검색은 `미색인 URL 진단` workflow를 먼저 보여주고, 지금 고칠 수 있는 표면과 리포트 갱신을 기다려야 하는 표면을 나눠 준다.

이 표를 채운 뒤에도 색인이 바로 되지는 않을 수 있다. 그래도 적어도 "Google이 아직 안 읽음"인지, "읽었지만 아직 색인 선택을 안 함"인지, "내가 제출한 URL 모양이 애초에 흔들림"인지가 갈린다. 이 차이가 있어야 기다릴지, canonical을 고칠지, 본문을 보강할지, sitemap 제출 범위를 줄일지 정할 수 있다.

색인 리포트가 안 움직일 때 보는 공식 기준

Search Console 숫자가 안 바뀌면 제일 먼저 날짜를 본다. sitemap row의 `last read`가 오늘이어도 Page indexing report 날짜는 며칠 전일 수 있다. 이 둘은 같은 화면 안에 있어도 같은 시계가 아니다. 그래서 "크롤링도 실패, 색인도 실패"라고 한 줄로 적기 전에, Google 문서가 나누는 상태부터 다시 본다.

내가 참고한 기준은 Page indexing report, URL Inspection tool, Ask Google to recrawl your URLs, Sitemaps overview다. Google은 재크롤링이 며칠에서 몇 주 걸릴 수 있고, 요청이 검색 결과 포함을 보장하지 않는다고 설명한다. 여기서 중요한 문장은 하나로 줄일 수 있다. 요청, 발견, 크롤링, 색인, 노출은 서로 다른 단계다.

그래서 bobob.app에서 하루 단위로 하는 일도 바뀐다. 같은 sitemap을 다시 제출하거나 title만 계속 바꾸는 대신, 오늘 바꿀 수 있는 public response와 content signal을 닫는다. `HTTP Status Checker`로 final response를 보고, `Sitemap Generator`로 제출 URL 세트를 줄이고, `Robots.txt Generator`와 `Meta Tag Generator`로 crawl/index 신호를 맞춘다. 그 다음 Search Console은 맞는 계정에서 리포트 날짜와 URL Inspection 결과를 따로 적는다.

오늘 고칠 것과 기다릴 것

이 표는 속도를 빠르게 만드는 마법이 아니다. 대신 같은 불안을 매일 다른 파일에 쏟는 것을 막는다. 오늘 고칠 수 있는 것은 public URL과 content quality다. 기다려야 하는 것은 Google의 report refresh와 index selection이다. 둘을 섞지 않아야 개발자도구, Blog, Play를 같은 사이트 안에서 계속 살릴 수 있다.

bobob.app에서 바꾼 이유

예전 도구 목록만 보면 많은 기능이 이미 브라우저나 IDE 안에 있었다. JSON formatting, Base64 decode, CSS 정리 같은 기능은 필요하지만, 그것만으로는 다시 들어올 이유가 약하다. 반대로 공개 사이트 운영자는 배포 뒤에 여러 표면을 이어서 본다. redirect 확인 후 DNS를 보고, sitemap을 정리한 뒤 robots와 canonical을 보고, 마지막에 Search Console이나 Bing/Naver를 본다.

그래서 `/search?q=site indexing checklist` 같은 검색은 이제 개별 도구 하나보다 `검색 노출 준비 점검` 흐름을 먼저 보여준다. HTTP status checker, sitemap generator, robots.txt generator, meta tag generator, URL parser가 한 줄로 이어진다. 이 조합은 DevTools의 Network 탭을 대체하려는 게 아니다. DevTools가 보여주는 현재 탭 상태를 공개 검색 표면으로 확장하는 역할이다.

상태를 잘못 적으면 생기는 문제

이런 문장 정리는 사소해 보이지만 운영 품질을 만든다. "됐음"이 아니라 "어느 표면까지 됐음"이라고 적어야 다음 작업이 정해진다. status 문제면 status를 고치고, canonical 문제면 canonical을 고치고, 본문 깊이 문제면 대표 글을 보강한다. 증거가 없을 때 title만 계속 바꾸면 나중에 무엇이 효과였는지 모른다.

지금 이 사이트에서 확인할 것

bobob.app은 현재 공개 표면을 작게 유지하고 있다. `/sitemaps/en`에는 홈, 검색, trust pages, Blog category hub, 대표 Blog, Play, `/tools`, 그리고 운영 우선 도구만 넣는다. 짧은 제작 메모는 URL로 남아도 sitemap/feed/search에서 대표 글처럼 밀지 않는다.

이 상태에서 내가 봐야 할 것은 URL 수 자체가 아니라 줄이 맞는지다. source target, live sitemap, IndexNow 제출 수, WebSub feed item 수, Search Console discovered pages를 따로 적는다. 지금 live 쪽이 맞아도 Search Console 계정이 다르면 제출 버튼을 누르지 않는다. 계정이 다른 상태에서 본 화면은 관찰 기록이 될 수는 있어도, bobob.app property의 운영 행동으로 쓰면 안 된다.

기다리는 동안 할 수 있는 일

색인은 기다려야 하는 구간이 있다. 하지만 기다리는 동안 할 일이 없는 것은 아니다. DevTools로 local interaction을 보고, 공개 URL status checker로 final response를 보고, sitemap과 robots 도구로 제출 표면을 줄이고, meta/canonical을 다시 확인한다. Blog 글은 짧은 조각보다 대표 판단을 담게 만들고, Play는 관련 글과 다시 이어지게 둔다.

주소 대기표 도장 찍기는 이 루틴을 작은 Play로 바꾼 것이다. 오늘 볼 도장과 며칠 둬야 할 도장을 나누는 방식은 Search Console을 볼 때도 그대로 필요하다. 지금 바로 고칠 수 있는 표면과 외부 도구가 다시 읽을 때까지 기다려야 하는 표면을 나눠야 불안한 수정이 줄어든다.

마지막 체크

• - DevTools에서 본 200을 production canonical 200으로 다시 확인했는가.
• - sitemap URL이 실제 final 200 HTML인지 확인했는가.
• - robots.txt와 meta robots가 같은 방향인지 확인했는가.
• - canonical이 제출 URL과 같은 host/path를 가리키는가.
• - Search Console은 `bobob935@gmail.com` 계정과 `sc-domain:bobob.app` property에서 봤는가.
• - discovered pages, indexed pages, impressions, clicks를 같은 숫자로 말하지 않았는가.
• - Bing/Naver 상태를 Google 상태로 대신 말하지 않았는가.

이 정도를 통과해야 "개발자도구 사이트"가 아니라 "공개 웹 운영 점검대"라고 말할 수 있다. DevTools는 계속 쓴다. 다만 DevTools가 끝낸 일과 검색엔진이 아직 끝내지 않은 일을 같은 줄에 놓지 않는다. 그 구분이 지금 사이트의 방향이다.