구축 노트 · SEO / GEO
정적 사이트에 검색 기반을 만드는 최소 구현 순서
검색 기반은 CMS나 자동 발행부터 시작하지 않아도 됩니다. 공개 URL과 문서의 의미를 먼저 정하고, 검색 로봇이 발견할 파일과 내부 링크를 연결한 뒤 같은 규칙을 자동 확인하면 작은 정적 사이트도 관리 가능한 검색 기반을 가질 수 있습니다.
핵심 답 — CMS보다 먼저 정할 5가지
- 각 공개 문서의 고유 URL, title, description, canonical을 맞춥니다.
- robots, sitemap, feed가 공개 URL과 같은 내용을 가리키게 합니다.
- Home → Hub → Detail → Related/CTA가 일반 링크로 연결됩니다.
- Article/CollectionPage 같은 structured data는 화면의 공개 사실과 일치할 때만 사용합니다.
- 사람의 기억에 의존하지 않도록 이 규칙을 자동 검사로 정합니다.
왜 CMS가 검색 기반의 시작점은 아닌가
CMS는 콘텐츠를 편하게 작성하고 관리하는 도구입니다. 그러나 검색엔진이나 AI 기반 검색 서비스가 읽는 것은 최종적으로 공개된 URL, 문서 제목, 본문 구조, 링크, 이미지와 출처입니다. CMS가 있어도 canonical이 중복되거나 sitemap이 공개 경로와 다르면 기반은 약합니다. 반대로 정적 HTML이라도 이 정보가 일관되면 검색 가능한 문서 구조를 만들 수 있습니다.
JERRYBAY는 이 순서로 검색 기반을 준비했습니다. 먼저 세 개의 초기 공개 글을 만들고, `/insights/`, robots, sitemap, feed, 내부 링크와 품질 검수를 묶어 작은 콘텐츠 검색 구조를 구성했습니다. 운영 규모가 커질 때 콘텐츠 관리 도구를 별도로 더하는 방향을 잡고 있습니다.
1. 문서의 고유한 의미와 canonical URL을 고정합니다.
검색 기반에서 가장 먼저 필요한 것은 “이 문서가 무엇인가”에 대한 일관된 답입니다. 각 상세 페이지는 고유한 title과 description, canonical URL을 가져야 합니다. 공유 화면에 쓰이는 Open Graph title/description/url도 같은 문서를 설명해야 합니다.
글이라면 화면에 보이는 제목, 작성자, 발행일과 `Article` structured data가 일치해야 합니다. Google Search Central도 structured data가 페이지의 실제 콘텐츠를 정확히 나타내야 한다고 안내합니다. 프로젝트 상세라면 실제 내용을 Article처럼 꾸미기보다 `WebPage` 등 맞는 유형을 선택하는 편이 낫습니다.
2. robots, sitemap, feed를 같은 URL 목록에 맞춥니다.
robots.txt는 검색 로봇의 접근 규칙과 sitemap 위치를 알리는 데 사용합니다. sitemap.xml은 사이트가 중요하다고 판단한 공개 URL을 검색엔진에 알려주는 파일입니다. Google은 sitemap을 URL 발견을 돕는 수단으로 설명하며, sitemap에 넣었다고 색인이 보장되는 것은 아니라고 안내합니다. RSS feed는 최신 콘텐츠의 제목, 설명, 발행일과 영구 링크를 제공하는 별도 구독 경로입니다.
3. SEO와 GEO가 함께 읽을 수 있는 본문 구조를 만듭니다.
검색 키워드를 반복하는 것보다 중요한 것은 독자가 묻는 질문에 바로 답하고, 그 답의 근거와 세부 설명을 구조화하는 것입니다. JERRYBAY의 글은 상세 글의 상단에 핵심 답을 먼저 두고 H2/H3로 문제·원인·방법·사례·체크리스트·FAQ를 구분합니다. 제품명, 회사명, 기술명 같은 Entity는 정확한 이름으로 쓰고, 공개 근거는 참고 자료 섹션에서 분리합니다.
이 방식은 전통적 SEO뿐 아니라 생성형 검색과 AI 답변 환경에서 문서의 핵심 주장과 근거를 파악하기 쉽게 만드는 데도 유리할 수 있습니다. 다만 GEO를 이유로 새로운 사실을 만들거나 FAQ를 억지로 늘리는 것은 금지해야 합니다.
4. 이미지도 이해를 돕는 근거로 다룹니다.
상세 글에 들어가는 이미지는 장식보다 이해를 돕는 역할이어야 합니다. 실제 screenshot, prototype, sample, process diagram을 우선하고, 각 이미지에 구체적인 alt text와 caption/source를 붙입니다. AI로 생성한 Concept visual이라면 실제 고객 화면이나 성과처럼 오해되지 않게 `Concept / Illustration / Prototype`으로 표시해야 합니다.
5. 사람이 기억하지 않아도 되는 규칙은 테스트합니다.
정적 사이트는 구조가 단순한 대신 사람이 파일을 직접 수정할 때 어긋남이 생기기 쉽습니다. 따라서 공개 URL 존재 여부, 중복 title, canonical과 OG URL의 일치, sitemap/feed XML, 깨진 내부 링크, JSON-LD parsing을 자동 검사로 정하는 편이 좋습니다. 브라우저 검수에서는 데스크톱·모바일 화면, 가로 넘침, 메뉴, 오류와 주요 링크 목적지를 확인합니다.
자동 확인
HTML, canonical, links, sitemap/feed처럼 같은 입력에서 같은 결과가 나오는 검사는 자동화에 적합합니다.
사람이 보는 검수
긴 글의 읽기 흐름, 이미지 의미, 모바일 인지부하와 근거가 오해될 가능성은 별도 리뷰가 필요합니다.
언제 콘텐츠 관리 도구가 필요할까
작성할 페이지가 늘어나고 title, image, source, tag, related content를 사람이 여러 HTML에 반복 입력하기 시작하면 CMS의 가치가 커집니다. 그러나 이때도 공개 사이트까지 즉시 동적 CMS로 바꿀 필요는 없습니다. JERRYBAY는 별도 관리 화면에서 콘텐츠를 관리하고 확인한 내용을 정적 사이트에 반영하는 방식을 구상하고 있습니다. 이렇게 하면 작성 편의와 정적 공개 구조의 단순성을 함께 가져갈 수 있습니다.
구현 체크리스트
- 모든 공개 URL에 고유 title/description/canonical이 있다.
- H1은 페이지당 하나이며 본문 H2/H3 구조가 자연스럽다.
- robots/sitemap/feed URL이 공개 URL과 일치한다.
- Hub에서 Detail, Detail에서 Related/Business로 일반 링크가 연결된다.
- Article schema의 제목·작성자·날짜가 화면의 문구와 일치한다.
- 이미지에 설명형 alt와 caption/source가 있다.
- 중요 콘텐츠에 참고 자료가 있다.
- 자동 확인과 데스크톱·모바일 브라우저 검수가 배포 전에 실행된다.
FAQ
정적 사이트도 SEO에 불리하지 않나요?
정적이라는 이유만으로 불리한 것은 아닙니다. 중요한 것은 검색 로봇이 접근 가능한 고유 URL, 의미 있는 콘텐츠, metadata, 내부링크, 성능과 구조의 일관성입니다.
해시태그를 많이 넣으면 검색에 더 잘 걸리나요?
해시태그는 내부 Topic taxonomy와 탐색에는 유용하지만, 무관한 키워드 반복은 검색 품질을 높이는 핵심 수단이 아닙니다. 본문 의미, 근거, Entity, 내부링크와 metadata가 우선입니다.
자동 발행까지 바로 연결하는 게 효율적이지 않나요?
콘텐츠의 근거·개인정보·시각 품질 검수가 안정되기 전에는 초안 확인까지 자동화하고 공개는 별도 확인 단계로 남기는 편이 안전합니다.
참고 자료
- Google Search Central — SEO Guide for Web Developers ↗ — sitemap, robots, structured data 등 개발자가 확인할 기본 검색 요소.
- Google Search Central — Build and submit a sitemap ↗ — sitemap 작성·제출 공식 가이드.
- Google Search Central — Structured data introduction ↗ — structured data와 실제 페이지 의미의 관계를 설명하는 공식 문서.
- Google Search Central — Canonical URLs ↗ — 중복 URL과 canonical 신호에 대한 공식 안내.
- robots.txt · sitemap.xml · feed.xml — 현재 JERRYBAY 공개 discovery files.