반려 뒤에 이 사이트에서 고친 것들 — 소개가 사실과 어긋나 있었습니다

birchholt · 2026년 9월

구글이 이름을 꺼낸 후보가 콘텐츠뿐이어서 다음 날 하루 동안 이 사이트를 손봤습니다. 다섯 건이 2026-09-07 11:10 부터 16:54 사이, 5시간 44분에 들어갔습니다. 글은 한 편도 안 늘렸습니다.

늘리는 것보다 먼저 할 일이 있었기 때문입니다 — 이미 올라가 있는 것이 스스로에 대해 하는 말이 사실과 달랐습니다.

1. 글 목록 페이지의 98.2%가 홈 복제였습니다

Search Console 의 「페이지 색인 생성 문제」를 파다가 걸린 것입니다. /posts/ 를 홈과 문자 단위로 대조했더니 이랬습니다.

/posts/ 의 <main>   1008자
  그중 홈과 단일 연속 일치   990자 (98.2%)

「비슷하다」가 아니라 끊기지 않고 이어지는 한 덩어리가 990자입니다. 거기에 세 URL 의 meta description 이 바이트 단위로 같았습니다.

/                  ┐
/posts/            ├─ 셋 다 site.Params.description 으로 폴백
/posts/page/2/     ┘

원인은 파일 하나가 없어서였습니다. content/posts/_index.md 가 없으면 section.html 의 .Content 가 빈 문자열이 되고, /posts/ 는 홈 카드 블록의 복제로만 렌더됩니다. 그 파일을 만들고, head.html 의 $desc 에도 페이저 분기를 넣었습니다.

title 과 canonical 은 이미 페이저 분기가 있었습니다. 페이징을 넣을 때 그 둘만 갈라뒀고, description 을 빼먹은 상태였습니다. 이번에 새로 가른 것은 그 하나입니다.

	고치기 전	고친 뒤
홈과의 최장 연속 일치	990자 (`<main>` 의 98.2%)	994자 (62.0%)
`description`	3개 URL 바이트 단위 동일	3개 URL 전부 분기
`title`·`canonical`	이미 분기돼 있었습니다	그대로

⚠️ 일치한 글자 수 자체는 줄지 않았습니다. 카드 블록은 그대로 두고 그 위에 고유 본문을 얹었을 뿐이라 당연합니다. 비율만 보고 「중복을 지웠다」고 읽으면 안 됩니다. 지운 게 아니라 덮은 것이고, 카드 블록은 여전히 두 페이지에 같이 있습니다.

두 값은 같은 글 목록으로 재야 합니다. 처음에는 고친 뒤 값을 1059자(63.4%)로 적었는데, 그건 그 사이 예약 글 한 편이 더 공개돼 1페이지의 카드 6장 구성이 바뀐 값이었습니다. 앞 열과 같은 조건이 아니라 표에 나란히 둘 수 없습니다.

2. 구조화 데이터가 전 페이지에 0건이었습니다

발행일은 사람이 화면에서 읽을 수 있었지만 기계가 읽을 자리가 없었고, 저자는 화면에도 기계에도 아예 없었습니다. ld+json 이 전 페이지 0건이었고 <time> 도 author 도 없었습니다.

posts 섹션 글에만 BlogPosting 을 붙였습니다. 붙이면서 빌드 실측으로 잡은 함정이 셋입니다.

하나 — safeJS 없이 jsonify 하면 빌드는 통과하는데 유효한 JSON 이 아닙니다. Go 의 html/template 이 <script> 안을 JS 문맥으로 보고, 조립한 객체를 통째로 따옴표 친 문자열 하나로 감싸버립니다. 화면으로는 알 수 없어서 파싱해보고 알았습니다 — json.loads 가 dict 가 아니라 str 을 돌려줬습니다.

둘 — .IsPage 로 거르면 /privacy/ 까지 BlogPosting 이 됩니다. 개인정보처리방침은 블로그 글이 아닙니다. posts 섹션으로 좁혔습니다.

셋 — dateModified 를 ne 로 비교하면 예약 발행분에서 날짜가 뒤집힙니다.

.Date      공개일   (publishDate)
.Lastmod   작성일   (미리 써두고 날짜만 벌린 글)

예약 발행을 쓰고 있어서 이 둘이 어긋납니다. 「다르면 넣는다」로 짜면 수정일이 발행일보다 앞선 데이터가 나갑니다. .After 로 바꿨고, 4편이 여기 걸려 있었습니다.

검증은 이렇게 했습니다(2026-09-07 빌드 기준, 그때 글 11편).

확인	결과
글의 `ld+json` 이 유효한 JSON 인가	11 / 11
`<time datetime>` 과 `datePublished` 일치	전건
목록·`/404`·`/privacy/` 의 `ld+json`	0건

author 는 새로 만들면서 사이트 이름을 그대로 썼습니다. 없는 사람 이름을 지어내면 그것 자체가 이번에 고치고 있는 것과 같은 종류의 문제가 됩니다.

3. 소개 문구가 안 한 일을 했다고 말하고 있었습니다

홈 하단 카드가 두 블로그를 이렇게 소개하고 있었습니다.

misiq     "외식 기록은 다녀온 곳만 씁니다"
checkin   "다녀온 곳을 다시 찾아갈 수 있게 남깁니다"

두 블로그의 글 99편을 전수로 받아 본문을 훑었습니다. 방문일 표기 0건, 가격 표기 0건입니다.

사진의 촬영 주체는 본문으로 판정할 수 있는 값이 아니어서 세지 않았습니다. 전부 미방문이라는 것은 측정이 아니라 운영자 확인입니다 — 제가 아는 사실이지 재본 값이 아닙니다. 둘을 한 문장에 섞으면 앞의 두 숫자까지 흐려집니다.

어느 쪽이든 사이트가 자기 콘텐츠의 성격을 사실과 다르게 말하고 있었습니다. 주장을 실체에 맞춰 다시 썼습니다.

나중에 실제 방문 기록을 섞게 되면 그때 다시 씁니다.

4. 없는 블로그를 소개하고 있었습니다

3번을 고치고 나서 라이브와 한 줄씩 대조했더니 두 건이 더 어긋나 있었습니다.

	이 사이트가 말하던 것	라이브 실측
이름	「미식가의 주방」	`og:site_name` 은 「미식로그」
성격	“집에서 만드는 것 … 레시피는 계량을 정확히 적고”	카테고리 6개가 전부 맛집, 레시피 카테고리 0개

레시피 블로그를 소개하고 있는데 라이브에는 레시피 카테고리가 0개입니다. 소개가 언제부터 어긋났는지 — 처음부터인지, 블로그 성격이 바뀐 것인지 — 는 과거 스냅샷이 없어 확인하지 못했습니다.

구글 게시자 정책의 Misrepresentative content 는 「사실과 다르게 진술한다(misstates)」를 항목으로 두고 있고, 여기가 심사 대상 사인업 URL 입니다.

여기서 blurb 두 개를 통째로 다시 썼고, 그러면서 두 문구가 나란히 「공개된 정보를 모아 정리한 안내이고 직접 다녀와서 쓴 후기가 아닙니다」로 끝나게 됐습니다. 3번에서 방문 주장을 걷어낸 것과 이 공통 문장은 다른 커밋입니다.

같이 홈 H1 도 바꿨습니다.

전   해본 것만 적는 자리입니다
후   해본 것은 해봤다고, 모은 것은 모았다고 적습니다

이 페이지의 글은 실측 기록이지만 서브도메인 두 곳은 성격이 다릅니다. H1 이 세 호스트를 한 문장으로 덮고 있었던 것이 문제였습니다.

검증은 빌드 산출물 grep 으로 했습니다 — 레시피·집에서 만드는·미식가의 주방·해본 것만 각 0건.

⚠️ 이건 검증이 아니라 확인입니다. 제가 고친 문자열만 찾은 것이고, 같은 종류가 하나 더 남아 있습니다 — 사이트 전역 description 의 「요리와 여행, 두 개의 기록을 운영합니다」가 그대로 홈 meta description 으로 나갑니다. misiq 에 레시피가 0개라는 이유로 요리 서술을 지워놓고 이 줄은 못 잡았습니다. 아직 안 고쳤습니다.

그리고 지금 이 grep 을 라이브에서 재현하면 0건이 아닙니다. 이 글이 옛 문구 넷을 전부 인용하고 있어서 이 페이지가 잡힙니다.

고칠 것을 찾은 방법이 셋 다 같습니다 — 사이트가 하는 말과 라이브를 나란히 놓고 한 줄씩 대조했습니다. 다만 그 대조가 전수가 아니었습니다. 카드와 H1 은 봤는데 사이트 전역 description 은 안 봤습니다.

5. 방침이 하위 도메인을 적용 범위 밖으로 밀어내고 있었습니다

애드센스는 서브도메인을 별도 사이트로 두지 않고 부모 도메인에 병합해서 봅니다. 그런데 개인정보처리방침은 “하위 도메인은 별도입니다"로 시작하고 있었습니다.

등록 단위와 방침 범위가 정반대였습니다. 심사에 들어가는 세 호스트 중 둘이 방침 바깥에 있는 셈입니다.

세 호스트 전부를 적용 대상으로 선언하고, 하위 도메인을 두 층으로 갈랐습니다.

층	무엇	누가 처리	어디를 가리키나
플랫폼	회원·댓글·방명록·접속 로그·`stat.tiara.daum.net`	카카오	티스토리 방침
운영자	그 위에 제가 얹은 것	저	이 방침 2·3·4항

같이 채운 것이 둘입니다.

광고 스크립트가 apex 에만 있습니다. 하위 도메인에는 아직 없습니다(실측: adsbygoogle 0건). 방침이 “광고를 게재합니다"라고만 써두면 그것도 사실과 다릅니다
Cloudflare Web Analytics 비콘 스니펫은 세 호스트에 전부 들어가 있습니다. 다만 실제로 집계되는 것은 apex 뿐입니다 — 서브도메인 비콘은 수집 경로가 POST 404 로 떨어집니다(기록). 방침에는 「삽입되어 있다」까지만 적혀 있는데, 바로 뒤 문장이 「집계 정보만 남깁니다」로 이어져 세 호스트에서 다 수집되는 것처럼 읽힙니다. 아직 안 고쳤습니다

하위 도메인에서 이 방침으로 오는 링크는 티스토리 스킨 푸터에서 겁니다. 스킨은 관리자 화면에 직접 붙여넣어야 해서 이 저장소의 커밋에 없습니다.

확인하지 못한 것 · 아직 안 고친 것

이 다섯 가지가 승인을 만들어내는지 모릅니다. 구글이 이름을 꺼낸 것은 「콘텐츠 부족」과 「낮은 콘텐츠 품질」이었고, 여기서 고친 것은 대부분 앞쪽의 위생 조치입니다
재제출은 아직 안 했습니다. 심사 시야의 91%인 서브도메인 99편이 남아 있습니다
사이트 전역 description 의 「요리」가 그대로 남아 있습니다. 4번에서 지운 것과 같은 종류인데 못 잡았습니다
방침의 방문 통계 항이 하위 도메인에 대해 실제보다 넓게 읽힙니다. 비콘은 있는데 수집이 안 되는 상태를 그대로 적어야 합니다
2026-09-07 GSC 기준 이 사이트 글 10편 중 7편이 크롤조차 안 된 상태였습니다(「발견됨-미색인」, 최종 크롤링 1970-01-01). 구조화 데이터를 붙였다고 읽히기 시작한다는 보장은 없고, 그 뒤로 다시 재보지 않았습니다
홈과 /posts/ 의 카드 블록 중복은 덮었을 뿐 지우지 않았습니다. 지워야 하는지는 아직 판단하지 않았습니다
/about/·/contact/ 는 이 사이트에 없습니다(홈 소개 문단이 대신하고 있습니다). 서브도메인 쪽은 about·privacy 가 네 URL 전부 404 인 채로 남아 있습니다

정리

반려 뒤에 한 일도 글을 늘리는 쪽이 아니었습니다. 이미 있는 것이 스스로에 대해 하는 말을 실측과 대조했습니다
/posts/ 의 <main> 98.2%가 홈과 한 덩어리로 일치했고, 원인은 content/posts/_index.md 파일 하나가 없어서였습니다
비율은 98.2% → 62.0% 로 떨어졌지만 일치 글자 수는 990자 → 994자로 그대로입니다. 지운 게 아니라 덮었습니다. 그리고 두 값은 같은 글 목록으로 재야 비교가 됩니다
jsonify 는 safeJS 없이 쓰면 빌드를 통과한 채로 유효하지 않은 ld+json 을 만듭니다. 화면으로는 안 보이고 파싱해야 잡힙니다
예약 발행을 쓰면 .Lastmod 가 .Date 보다 앞섭니다. ne 로 비교한 dateModified 가 4편에서 뒤집혀 있었습니다
소개 문구 세 건이 사실과 어긋나 있었습니다. 언제부터 어긋났는지는 스냅샷이 없어 모릅니다 — 대조로 알 수 있는 것은 「지금 다르다」까지입니다
고친 문자열만 grep 하는 것은 검증이 아니라 확인입니다. 그 grep 을 통과하고도 같은 종류가 사이트 전역 description 에 남아 있었습니다
방침의 적용 범위와 애드센스의 등록 단위가 정반대였습니다. 방침은 잘 쓰는 것보다 무엇을 덮는지가 등록 단위와 맞는지가 먼저였습니다

← 다른 기록 보기