Search Console을 기다릴 때 오늘 볼 것과 며칠 둘 것

제출했는데 조용하다

사이트를 배포하고 sitemap을 제출하면 바로 뭔가 달라질 것 같다. 그런데 대부분 조용하다. 색인도 바로 안 되고, 노출도 안 늘고, 클릭은 당연히 없다.

이 시간이 제일 어렵다. 뭘 잘못했나 싶어서 계속 설정을 만지게 된다. canonical을 다시 보고, robots.txt를 다시 보고, sitemap을 다시 열어본다. 필요한 확인도 있지만, 불안해서 만지는 것도 꽤 있다. 문제는 이때 손댄 변경이 실제로 필요한 수정인지, 숫자가 안 움직여서 나온 불안인지 구분하기 어렵다는 점이다.

그래서 이 글은 Search Console을 빨리 통과시키는 요령이 아니다. 내가 실제로 Bobob을 운영하면서 제출 성공, sitemap 발견, URL 검사, 실제 색인을 섞어 보지 않으려고 만든 작은 대기표다. 검색 엔진이 언제 가져갈지는 내가 못 정하지만, 오늘 확인할 수 있는 신호와 며칠 둬야 하는 신호는 나눌 수 있다.

나눠서 봐야 하는 것

기다릴 때는 상태를 나눠서 봐야 한다.

• - 라이브 페이지가 200인가
• - sitemap에 들어갔는가
• - Search Console이 sitemap을 읽었는가
• - URL 검사에서 크롤링 가능한가
• - 실제 색인에 들어갔는가
• - 검색 결과에 노출되는가

이 단계가 섞이면 계속 헷갈린다. 제출 성공을 색인 성공으로 착각하면 실망하고, 색인 대기를 오류로 착각하면 괜한 수정을 한다.

이 표를 적어두면 같은 화면을 다시 봐도 판단이 덜 흔들린다. 예를 들어 sitemap 제출 알림이 떴다고 해서 그 URL이 색인된 것은 아니다. 반대로 URL 검사에서 현재 접근 가능하다고 나왔는데도 색인 상태가 아직 `발견됨 - 현재 색인이 생성되지 않음`이면, 바로 제목과 구조를 갈아엎기보다 며칠 뒤 같은 URL을 다시 보는 편이 낫다.

오늘 볼 대기표

내가 바로 볼 수 있는 항목은 생각보다 좁다. 대신 이 좁은 항목을 제대로 보면 불필요한 수정을 많이 줄일 수 있다.

• - 페이지가 최종 canonical 주소에서 200으로 열린다.
• - robots.txt가 공개 페이지를 막지 않는다.
• - sitemap index가 `/sitemaps/en`을 가리킨다.
• - `/sitemaps/en` 안에 대표 글, category hub, Play, trust page가 들어 있다.
• - 약한 짧은 메모는 sitemap과 feed에서 빠져 있고 noindex다.
• - 대표 글은 제목만 있는 페이지가 아니라 표, 체크리스트, 제작 판단, 검증 기록 중 하나 이상을 가진다.
• - URL 검사 라이브 테스트가 현재 페이지 접근을 막지 않는다.
• - Play나 Blog 목록에서 실제 대표 글로 자연스럽게 이동할 수 있다.

이 항목은 오늘 고칠 수 있다. 페이지가 404면 고친다. canonical이 다르면 고친다. sitemap에 약한 글이 너무 많으면 줄인다. 대표 글이 얇으면 보강하거나 archive로 내린다. 오늘 볼 대기표는 "검색 숫자가 안 움직인다"보다 "내가 제출한 표면이 지금 봐도 괜찮다"에 가깝다.

며칠 둘 대기표

반대로 바로 결론 내리면 안 되는 항목도 있다.

• - Search Console discovered pages가 새 sitemap 숫자와 같은 날 맞는지.
• - URL 검사 색인 상태가 요청 직후 바로 바뀌는지.
• - 노출과 클릭이 하루 안에 생기는지.
• - Bing이나 Naver가 같은 속도로 따라오는지.
• - 대표 pillar 글이 요청 직후 검색 결과에 뜨는지.

이 항목은 느리다. 느리다고 해서 항상 실패는 아니다. 특히 새로 정리한 Blog + Play 표면은 제출과 관측 사이에 시간이 필요하다. 이 구간에서 계속 제목을 바꾸고 sitemap 범위를 넓히면, 나중에 어떤 변경이 실제로 영향을 줬는지 알 수 없다. 조용한 시간은 불편하지만, 관찰 기간을 망가뜨리면 더 곤란하다.

남길 기록

숫자가 움직이지 않는 동안 할 수 있는 일은 기록이다. 무엇을 언제 배포했고, 어떤 URL을 제출했고, 어떤 응답을 확인했는지 적어두면 다음 판단이 조금 덜 흔들린다.

내가 남기는 기록은 보통 이런 식이다.

기록은 외부를 설득하기 위한 장식이 아니다. 다음에 내가 같은 불안을 만났을 때 "이미 본 것"과 "아직 기다릴 것"을 다시 나누기 위한 장치다. 숫자가 0인 화면을 보면 사람은 자꾸 새 작업을 만들고 싶어진다. 하지만 이미 확인한 것까지 다시 흔들면 사이트가 안정된 신호를 주기 어렵다.

만지지 않는 시간

기다리는 동안 가장 조심할 것은 계속 고치는 버릇이다. 하루 안에 숫자가 안 움직였다고 제목을 바꾸고, 구조를 바꾸고, sitemap을 다시 흔들면 오히려 무엇이 효과였는지 모르게 된다.

그래서 며칠은 일부러 손을 덜 대는 것도 필요하다. 대신 라이브 페이지가 열리는지, canonical이 맞는지, Search Console에서 어떤 날짜에 다시 확인할지만 적어둔다. 조용한 시간이 실패는 아니다. 아직 데이터가 오지 않은 시간일 수도 있다.

이번 Bobob 정리에서도 이 기준을 쓰고 있다. 대표 글은 30개 안팎으로 줄이고, 짧은 제작 메모는 Play별 build log에 흡수하고, category hub와 Play와 trust page 중심으로 sitemap을 유지한다. 외부 도구에는 다시 제출하되, 제출 성공을 색인 성공으로 말하지 않는다. 이 선을 지키는 게 재밌지는 않지만, 사이트가 실제로 운영되고 있다는 증거는 이런 작은 구분에서 더 잘 남는다.

다음 확인 체크리스트

• - 새 대표 세트가 `/blog` 첫 화면에서만 봐도 너무 정보성 검색 글로 치우쳐 보이지 않는가.
• - `/sitemaps/en` URL 수와 feed item 수가 문서와 실제 응답에서 같은가.
• - 두 개 이상의 대표 pillar URL이 URL 검사에서 접근 가능하고 sitemap에 묶여 있는가.
• - Search Console discovered pages가 새 sitemap 수와 맞는지 며칠 뒤 다시 확인했는가.
• - Bing Webmaster와 Naver Search Advisor에서 sitemap, robots.txt, 소유권, 수집 상태를 별도 기록했는가.
• - 관측 전에는 약한 글을 더 제출하지 않고, 기존 대표 글의 본문과 연결만 정리했는가.

이 체크리스트가 끝나도 바로 결론은 아니다. 하지만 적어도 내가 오늘 볼 수 있는 대기표는 본 셈이다. 그다음은 며칠 둘 대기표를 며칠 두는 일이다.