AI 블로그 자동화에서 canonical URL 점검을 루틴화하는 법

요약

Futory처럼 Markdown 파일 하나가 곧 공개 글이 되는 블로그에서는 본문 품질만큼 URL 품질도 중요합니다. 특히 AI가 매일 글을 만들고 빌드와 재시작까지 수행하는 바이브코딩 운영에서는 “새 파일이 생겼다”와 “독자가 보게 될 대표 주소가 안정적이다”를 분리해서 확인해야 합니다. canonical URL 점검은 이 둘 사이의 작은 안전장치입니다.

canonical은 검색엔진과 공유 도구에 “이 글의 기준 주소는 여기”라고 알려주는 신호입니다. slug가 바뀌었거나, 목록에는 노출되지만 상세 페이지 메타데이터가 어긋났거나, 캐시된 이전 HTML이 남아 있으면 같은 글이 여러 주소처럼 보일 수 있습니다. 오늘은 Futory 발행 루틴에 canonical URL 확인을 넣는 실무적인 방법을 정리합니다.

왜 canonical 점검이 필요한가

자동 발행은 반복 작업을 줄여 주지만, 반복되는 작은 실수도 함께 빠르게 누적시킬 수 있습니다. Markdown frontmatter의 date와 파일명 slug, Next.js 라우트, 공개 URL, sitemap 항목이 모두 같은 글을 가리켜야 운영자가 안심할 수 있습니다.

중복 콘텐츠 신호를 줄인다

동일한 본문이 /posts/example과 다른 임시 경로, 또는 쿼리 문자열이 붙은 주소로 반복 수집되면 검색엔진은 어떤 주소를 대표로 삼아야 할지 판단해야 합니다. canonical이 정확하면 검색 신호가 분산될 가능성을 줄이고, 나중에 성과를 확인할 때도 한 주소를 기준으로 볼 수 있습니다.

공유 링크의 기준을 고정한다

Futory의 글은 홈, /posts, /vibe-coding, 상세 페이지에서 발견됩니다. 독자가 어느 목록에서 들어오든 최종적으로 공유되어야 할 주소는 하나입니다. 발행 자동화가 canonical과 실제 상세 URL을 함께 확인하면, 제목이나 날짜는 맞는데 공유 미리보기 주소가 어긋나는 문제를 더 빨리 발견할 수 있습니다.

Futory 발행 루틴에 넣을 점검 순서

canonical 점검은 거창한 SEO 프로젝트가 아니라 빌드 후 공개 검증에 한 줄 더하는 방식으로 시작할 수 있습니다. 핵심은 새 slug를 기준으로 HTML을 직접 가져와 확인하는 것입니다.

1. slug를 발행 증거의 중심에 둔다

새 글을 만들 때 파일명은 영어 kebab-case로 정하고, 이 slug를 테스트, 빌드 산출물 확인, 공개 URL 확인, 목록 확인에 계속 재사용합니다. 예를 들어 오늘 글의 slug가 ai-blog-canonical-url-check-routine이라면 기준 공개 주소는 /posts/ai-blog-canonical-url-check-routine입니다.

frontmatter의 title이나 description은 사람이 읽는 신호이고, slug는 시스템이 추적하는 신호입니다. 운영 로그에는 둘 다 남기되, 자동 검증은 slug 중심으로 두는 편이 안정적입니다.

2. 빌드 산출물에서 먼저 찾는다

npm run build가 성공한 뒤에는 .next 안에 새 slug가 포함되었는지 확인합니다. 이 단계는 “소스 파일은 생겼지만 빌드가 새 글을 포함하지 못한 상태”를 잡아냅니다. 공개 사이트를 보기 전에 로컬 빌드 산출물에서 slug를 찾으면 문제 범위를 좁히기 쉽습니다.

3. 공개 HTML에서 canonical을 읽는다

PM2 재시작 뒤 상세 페이지를 no-cache로 가져와 <link rel="canonical" ...> 또는 메타데이터에 포함된 기준 주소를 확인합니다. canonical이 명시되어 있지 않은 구조라면, 최소한 상세 페이지의 최종 URL과 og:url 같은 공유 메타 값이 같은 slug를 포함하는지 확인합니다.

이때 쿼리 문자열을 붙여 캐시를 우회하더라도 canonical 자체는 쿼리 없는 깨끗한 주소를 가리키는 것이 좋습니다. 검증 요청은 /posts/slug?cron_ts=...처럼 하되, HTML 안의 대표 주소는 /posts/slug로 남아야 합니다.

운영자가 남기면 좋은 로그

canonical 점검 결과는 길게 쓸 필요가 없습니다. 다음 네 가지면 충분합니다.

기준 URL

https://futory.oig.kr/posts/slug 형식의 최종 주소를 기록합니다. 이 주소가 이후 목록, sitemap, 공유 카드, 내부 링크 점검의 기준이 됩니다.

상세 페이지 상태 코드

HTTP 200인지 확인합니다. 200이 아니라면 canonical 이전에 라우팅이나 배포 문제가 먼저입니다.

HTML 포함 여부

HTML에 slug, 오늘 날짜, 가능하면 제목이 들어 있는지 확인합니다. 목록 페이지는 일부 텍스트를 생략할 수 있으므로 상세 페이지를 가장 강한 증거로 둡니다.

대표 주소 신호

canonical, og:url, 또는 앱이 제공하는 동등한 메타 신호가 새 slug를 포함하는지 확인합니다. 현재 구조가 canonical 태그를 생성하지 않는다면 그 사실도 로그에 남기고, 향후 layout 메타데이터 개선 항목으로 분리하면 됩니다.

자동화할 때의 주의점

AI 발행 루틴에서 canonical을 점검할 때 가장 흔한 실수는 “문자열이 보인다”만으로 끝내는 것입니다. 상세 페이지에 slug가 보이는 것과 대표 주소가 올바른 것은 다릅니다. 또 다른 실수는 캐시 우회용 쿼리까지 canonical에 들어가도록 만드는 것입니다. 검증에는 쿼리를 쓰고, 대표 주소에는 쿼리를 빼는 원칙을 지키면 됩니다.

또한 canonical 점검은 새 글 하나만 대상으로 해야 합니다. 기존 글 전체를 동시에 고치기 시작하면 오늘의 발행 작업과 사이트 구조 개선 작업이 섞여 장애 범위가 커집니다. Futory의 평일 발행 루틴처럼 매일 하나씩 안전하게 배포하는 흐름에서는 작은 검증을 추가하고, 구조 변경은 별도의 작업으로 분리하는 편이 좋습니다.

자주 묻는 질문

canonical 태그가 없으면 발행 실패로 봐야 하나요?

반드시 그렇지는 않습니다. 사이트 구조가 아직 canonical을 명시하지 않는다면 상세 URL, og:url, sitemap, 목록 노출을 함께 확인하고 “canonical 태그 없음”을 개선 과제로 기록하면 됩니다. 다만 canonical을 쓰기로 한 프로젝트라면 새 글에서 누락된 것은 배포 실패에 가깝게 다루는 편이 안전합니다.

목록 페이지 확인과 무엇이 다른가요?

목록 페이지 확인은 새 글이 독자에게 발견되는지 보는 단계입니다. canonical 점검은 발견된 글의 대표 주소가 안정적인지 보는 단계입니다. 둘은 서로 보완 관계입니다.

AI가 slug를 만들면 canonical도 자동으로 맞나요?

아닙니다. slug 생성, Markdown 저장, Next.js 라우팅, 메타데이터 생성, 런타임 재시작이 모두 연결되어야 합니다. 그래서 발행 후 실제 공개 HTML을 읽어 확인하는 절차가 필요합니다.

결론

Futory의 바이브코딩 발행 자동화에서 canonical URL 점검은 작지만 효과적인 운영 습관입니다. 새 글의 slug를 기준으로 빌드 산출물, 상세 페이지, 목록 페이지, 대표 주소 신호를 연결해 보면 “오늘 글이 만들어졌다”를 넘어 “오늘 글이 올바른 주소로 공개되었다”까지 확인할 수 있습니다.

자동화의 목표는 더 많이 쓰는 것만이 아니라 더 안정적으로 공개하는 것입니다. canonical URL을 발행 증거에 포함하면 검색 신호, 공유 링크, 운영 로그가 같은 방향을 가리키게 되고, 다음 날의 자동 발행도 더 신뢰할 수 있는 상태에서 시작됩니다.