콘텐츠 품질과 색인 상태를 다시 보기 전에 정리한 체크리스트

페이지 수보다 먼저 본 것

한동안 bobob.app에는 글이 많이 늘었다. Blog 글은 100개가 넘었고, Play도 계속 추가됐다. 숫자만 보면 부족해 보이지 않는다. 그런데 막상 목록을 다시 보면 문제가 보였다. 짧은 제작 메모가 너무 많았다. 어떤 메모는 한 기능을 고친 흔적이라 남겨둘 가치는 있지만, 처음 들어온 사람이 보기에는 비슷한 짧은 글이 계속 이어지는 것처럼 보일 수 있었다.

그래서 이번에는 "몇 개 더 쓰기"가 아니라 "무엇을 앞에 둘지"를 다시 정리했다. 삭제부터 하지는 않는다. 짧은 글에도 작업 기록이 들어 있기 때문이다. 대신 대표 글, 제작 로그, 아카이브 후보를 나누고, 검색에 제출하는 URL은 대표 글과 Play 중심으로 줄인다. 공개 목록에서도 약한 글이 대량으로 보이지 않게 한다.

나누는 기준

이 기준을 세우고 나니 할 일이 명확해졌다. 먼저 대표 글을 30개에서 45개 사이로 줄인다. 그리고 password-lock처럼 짧은 글이 여러 개 붙은 Play는 "금고 번호 추리판 제작 로그" 같은 깊은 글 하나로 묶는다. ten-box-rush도 마찬가지다. 이렇게 하면 짧은 8페이지가 깊은 1페이지가 된다.

대표 글을 고르는 기준

대표 글은 길이만으로 고르지 않는다. 긴데 비어 있는 글도 있고, 짧아도 중요한 판단을 담은 글도 있다. 그래도 제출 표면에 남길 글은 아래 조건을 최대한 만족해야 한다.

• - 본문이 충분히 길고 한두 문단으로 끝나지 않는다.
• - 표, 체크리스트, 단계, 비교 중 하나 이상이 있다.
• - 실제로 무엇을 바꿨는지 나온다.
• - 왜 그 판단을 했는지 나온다.
• - 배포, sitemap, feed, Search Console, Play 결과 링크 같은 검증 경로가 보인다.
• - 같은 카테고리에서 거의 같은 질문을 반복하지 않는다.

특히 개발 메모는 조심해야 한다. "버튼을 조금 고쳤다"는 기록은 나에게는 의미가 있지만, 방문자에게 단독 글로 충분한 가치를 주기는 어렵다. 그런 메모는 삭제하지 않고 Play 제작 로그의 재료로 쓰는 쪽이 낫다.

이번 정리에서 실제로 바꾼 것

말로만 줄였다고 쓰면 아무 의미가 없다. 그래서 이번에는 글 묶음마다 어디에 남기고 어디에서 빼는지 숫자로 먼저 봤다. 현재 Blog 원문은 127개다. 그중 공개 목록과 sitemap/feed에 계속 넣을 대표 글은 35개로 유지하고, 나머지 92개는 archive 또는 noindex 후보로 돌렸다. 삭제가 아니라 역할을 바꾸는 쪽이다.

이 숫자를 적어둔 이유는 나중에 마음이 급해졌을 때 다시 넓히지 않기 위해서다. 검색에 더 많이 보이고 싶다는 마음 때문에 짧은 글을 다시 제출 표면에 넣으면, 처음 들어온 사람이 보는 인상은 다시 흐려진다. 대표 글은 적어도 표, 체크리스트, 제작 판단, 검증 기록 중 하나가 있어야 하고, 짧은 글은 그 기준을 통과하기 전까지 뒤쪽 기록으로 남기는 편이 맞다.

sitemap을 줄이는 이유

많은 URL을 제출하는 것이 항상 좋은 신호는 아니다. 새 사이트는 특히 그렇다. sitemap이 넓으면 Search Console에서 발견과 색인을 분리해서 보기 어렵고, 얇은 글이 대표 글과 같은 무게로 제출된다. 그래서 지금은 `/sitemaps/en`을 대표 글, category hub, Play, trust 성격의 핵심 페이지 중심으로 줄인다.

줄인 sitemap은 숨기는 전략이 아니다. 오히려 공개 표면을 더 솔직하게 만드는 일이다. "이 사이트에서 먼저 봐야 할 콘텐츠는 이것입니다"라고 말하는 목록에 가깝다. 짧은 제작 메모 URL은 살아 있지만, 검색에 적극 제출하지 않는다. 사용자가 Play 제작 로그를 읽다가 필요한 맥락으로 열 수 있는 정도면 충분하다.

다시 확인할 순서

• - `/blog`에서 대표 글만 보이는지 확인한다.
• - category hub가 대표 글 기준으로만 계산되는지 본다.
• - `/sitemaps/en` URL 수가 줄었는지 확인한다.
• - `/feed.xml`, `/atom.xml`, `/feed.json`이 대표 글과 Play만 내보내는지 본다.
• - 짧은 제작 메모 상세에 `noindex`가 붙는지 확인한다.
• - 대표 pillar 글 2개를 URL 검사 대상으로 잡는다.
• - Search Console의 discovered pages가 새 sitemap 수와 맞는지 며칠 두고 본다.

여기서 중요한 것은 바로 결론을 내지 않는 것이다. sitemap 제출 성공은 파일을 읽었다는 뜻이지, 모든 대표 글이 색인됐다는 뜻은 아니다. URL 검사에서 색인 요청을 눌러도 바로 검색 노출이 생기는 것은 아니다. 발견, 색인, 노출, 클릭은 서로 다른 단계다.

사용자 화면에서 다시 보는 것

소스에서 `indexPolicy: noindex`를 붙였다고 끝나는 것도 아니다. 처음 들어온 사람은 frontmatter를 보지 않는다. 실제로는 `/`, `/blog`, category hub, Play detail, related links, feed, sitemap이 같은 방향을 가리켜야 한다. 그래서 로컬에서 다시 볼 때는 아래 장면을 따로 나눠 본다.

• - 홈 첫 화면에서 도구 목록보다 Blog + Play 방향이 먼저 읽히는지 본다.
• - `/blog`가 오래된 짧은 메모 목록처럼 보이지 않고, 세 pillar와 대표 글을 먼저 보여주는지 본다.
• - category hub에서 `정보` 글이 한 주제의 파생 질문만 계속 반복하지 않는지 본다.
• - Play detail에서 관련 Blog가 실제 제작 판단으로 이어지는지 본다.
• - 짧은 메모 URL은 살아 있더라도 검색 제출과 공개 목록에서 과하게 밀리지 않는지 본다.
• - `/about`과 `/contact`가 아직 예전 도구 사이트처럼 보이지 않는지 본다.

이 확인은 사람 눈으로 보는 단계가 필요하다. 하네스가 h1, description, canonical, robots, sitemap 수를 잡아도, 목록이 "짧은 작업 조각을 많이 늘어놓은 사이트"처럼 보이는지는 별도로 판단해야 한다. 그래서 대표 글을 줄이는 일과 목록에서 약한 글을 덜 보이게 하는 일은 같은 작업으로 묶어 봐야 한다.

공개 목록에서 보이고 싶은 상태

처음 들어온 사람에게는 이 사이트가 이렇게 보여야 한다.

• - 직접 만든 Play가 있고 실제로 조작할 수 있다.
• - 글은 짧은 조각이 아니라 대표 판단 중심으로 정리돼 있다.
• - 제작 과정은 숨기지 않지만 Play별 로그로 묶여 있다.
• - 도구는 archive로 남아 있고, 필요할 때 이어진다.
• - 운영자는 sitemap, feed, Search Console 같은 지루한 부분도 보고 있다.

이 상태가 되어야 "페이지가 많다"보다 "직접 만든 원본 콘텐츠가 중심이다"라는 신호가 강해진다. 지금 필요한 일은 급하게 글을 더 늘리는 것이 아니라, 이미 늘어난 글을 더 책임 있게 정리하는 것이다.

아직 기다릴 것

코드와 콘텐츠를 정리해도 외부 관찰은 시간이 걸린다. Search Console에서 새 sitemap을 다시 제출하고, 대표 pillar 글 몇 개를 URL 검사로 확인한 뒤, discovered pages와 indexing reason이 어떻게 변하는지 봐야 한다. 그 전까지는 배포가 끝났다고 해서 품질 문제가 끝났다고 말하면 안 된다.

기다림 메모를 체크리스트 안으로 접었다

색인 대기와 숫자 0을 따로 짧은 글로 남겨두면 그날의 불안은 잘 보인다. 하지만 제출 표면에 둘 글이라면 불안 자체보다 무엇을 확인하고 무엇을 기다릴지 나뉘어야 한다. 그래서 `indexing-waiting-room`으로 묶인 두 archive 메모를 이 체크리스트 안으로 접었다.

이 둘을 합치면 핵심은 하나다. 숫자가 안 움직인다고 바로 제목을 갈아엎거나 sitemap을 넓히지 않는다. 먼저 라이브 URL 200, canonical, robots, sitemap index, `/sitemaps/en`, noindex, feed, 대표 글의 본문 밀도를 본다. 여기까지 맞으면 그다음은 Search Console이 다시 읽을 시간을 둔다.

기다리는 동안 손을 놓자는 뜻은 아니다. 할 수 있는 일은 내부 표면을 정리하는 것이다. 약한 글이 공개 목록에 과하게 보이지 않는지, 대표 글이 짧은 메모를 제대로 흡수했는지, Play에서 관련 글로 넘어가는 길이 자연스러운지 본다. 반대로 Search Console discovered pages, 실제 색인 상태, 노출과 클릭은 같은 날 결론 내리지 않는다. 이 선을 나눠야 다음에 숫자가 움직였을 때 무엇이 원인이었는지 덜 흐려진다.

나는 이번 정리를 통과를 위한 꼼수로 보지 않으려고 한다. 실제로 방문자가 처음 열었을 때도 더 낫다. 짧은 글이 수십 개 늘어선 목록보다, 왜 이 사이트가 있는지 설명하는 글과 직접 해볼 수 있는 Play가 먼저 보이는 편이 훨씬 명확하다.