신규 사이트 GEO 설계 체크리스트 — 구축 단계부터 스키마 반영하기

신규 사이트는 왜 구축 단계부터 GEO를 반영해야 하나요?

신규 사이트는 구축 단계부터 GEO를 반영하는 편이 유리합니다. 정보 구조·URL·렌더링·스키마·크롤러 접근을 설계할 때 함께 정해 두면, 런칭 뒤 사후 교정으로 뜯어고치는 재작업을 줄이고 처음부터 AI 검색에 읽히는 사이트를 만들 수 있습니다.

GEO(생성형 엔진 최적화)는 ChatGPT·Perplexity·Google AI 개요·네이버 AI 브리핑 같은 답변에 우리 콘텐츠가 인용되도록 사이트를 다듬는 일입니다. 이 신호의 상당수는 정보 구조와 URL, 렌더링 방식, 구조화 데이터처럼 사이트의 뼈대에 자리합니다.

문제는 이 뼈대가 런칭 뒤에 가장 바꾸기 어려운 부분이라는 데 있습니다. URL 규칙을 바꾸면 링크와 색인이 흔들리고, 렌더링 방식을 갈아엎으면 개발을 다시 해야 합니다. 반면 설계 단계에서 한 줄씩 점검해 두면 대부분 추가 비용 없이 반영됩니다.

구분이 중요합니다. 사이트를 새로 만드는 시점의 설계 결정과, 이미 만든 사이트를 고치는 일은 접근이 다릅니다. 스타트업이 성장 단계별로 무엇을 먼저 할지는 스타트업 초기 검색·AI 노출 세팅, 스키마와 llms.txt를 실제로 채우는 코드는 JSON-LD와 llms.txt 설정법에서 이어집니다.

여기 담은 것은 구축할 때 내려야 할 설계 결정입니다. 코드 예시보다, 무엇을 어떻게 정할지에 관한 판단 기준에 무게를 둡니다.

신규 사이트 GEO 설계 체크리스트는 무엇을 점검하나요?

신규 사이트 GEO 설계는 크게 여섯 갈래를 점검합니다. 정보 구조, URL과 내부 링크, 렌더링 방식, 구조화 데이터, 크롤러 접근, 저자 신뢰 신호입니다. 여섯 항목 모두 개발이 시작되기 전 기획 단계에서 결정되므로, 설계 회의에서 한 번씩 짚어 두면 대부분 확보됩니다.

구축 단계에서 정할 여섯 가지 설계 결정은 다음과 같습니다.

1. 정보 구조: 어떤 페이지를 어떤 위계로 배치하고, 각 페이지가 어떤 주제 하나를 책임질지 정합니다.
2. URL과 내부 링크: 주소 규칙과 페이지 사이의 연결을 일관되게 설계합니다.
3. 렌더링 방식: 본문이 서버 HTML에 담기도록 SSR이나 프리렌더링을 기본값으로 잡습니다.
4. 구조화 데이터: 어떤 페이지 유형에 어떤 스키마를 넣을지 템플릿 단위로 미리 매핑합니다.
5. 크롤러 접근: robots.txt와 llms.txt, 방화벽에서 AI 봇을 막지 않도록 설정합니다.
6. 저자 신뢰 신호: 저자 페이지와 프로필 구조를 콘텐츠 모델에 처음부터 포함합니다.

이 순서에는 이유가 있습니다. 위쪽 세 가지(정보 구조·URL·렌더링)는 사이트의 뼈대라 나중에 바꾸기가 가장 어렵고, 아래쪽 세 가지(스키마·크롤러·저자)는 런칭 뒤에도 보강할 여지가 남습니다. 그래서 설계 회의에서는 위쪽부터 확정하는 편이 안전합니다.

정보 구조와 콘텐츠는 어떻게 설계하나요?

정보 구조는 한 페이지가 하나의 주제를 책임지도록 설계하는 것이 핵심입니다. AI는 페이지 단위로 내용을 발췌해 인용하므로, 한 페이지에 여러 주제를 뭉쳐 두면 어느 질문에도 또렷한 답이 되지 못합니다. 기획 단계에서 페이지 목록을 질문 하나에 답하는 단위로 나눠 둡니다.

주제를 나눌 때는 고객이 실제로 던지는 질문을 축으로 삼습니다. 무엇인지, 어떻게 하는지, 무엇과 다른지 같은 질문마다 페이지를 배정하면, 각 페이지가 답변엔진이 집어 가기 좋은 자기완결 단위가 됩니다. 이 질문 목록이 곧 사이트의 콘텐츠 지도가 됩니다.

이때 함께 볼 것은 페이지끼리 겹치지 않게 하는 일입니다. 비슷한 질문에 답하는 페이지가 여럿이면 AI가 어느 쪽을 인용할지 흩어지고, 검색에서도 자기들끼리 순위를 나눠 갖습니다. 설계 단계에서 한 질문에 한 페이지를 원칙으로 잡으면 이 겹침을 미리 막을 수 있습니다.

콘텐츠를 채우기 전에는 브랜드가 누구이고 무엇을 다루는지 정리한 기준 문서를 먼저 만들어 두는 편이 좋습니다. 이 기준 문서를 만드는 법은 비즈니스 컨텍스트 문서 만들기에 정리해 두었습니다. 사람과 AI가 브랜드를 같은 방식으로 이해하게 만드는 출발점입니다.

설계 산출물은 거창하지 않아도 됩니다. 페이지 목록, 각 페이지가 답하는 질문 하나, 페이지 사이의 상하 관계를 적은 표 한 장이면 충분합니다. 이 지도가 있으면 다음 단계인 URL 설계와 스키마 매핑이 자연스럽게 따라옵니다.

URL과 내부 링크 구조는 어떻게 설계해야 하나요?

URL은 짧고 의미가 드러나며 한번 정하면 잘 바뀌지 않도록 설계하는 것이 원칙입니다. 주소는 사람과 AI가 페이지의 위치와 주제를 읽는 첫 단서이고, 런칭 뒤 URL을 바꾸면 그동안 쌓인 링크와 색인이 끊기기 때문입니다. 그래서 규칙은 구축 초기에 확정해 두어야 합니다.

신규 구축 시 URL 설계 원칙은 다음과 같습니다.

1. 의미 있는 단어를 쓰고, 자동으로 생성되는 숫자나 물음표 뒤 문자열을 피합니다.
2. 카테고리 위계가 필요하면 한두 단계로 얕게 유지합니다.
3. 페이지마다 주소를 하나로 고정하고, 중복 주소는 대표 주소로 모읍니다.

주소 규칙을 정했으면 페이지 사이의 연결도 함께 설계합니다. 상위 개념에서 하위 문서로 내려가는 이동 경로와, 화면에 보이는 위치 표시(BreadcrumbList)를 구조에 넣으면 AI가 사이트의 위계를 파악하기 쉬워집니다.

내부 링크는 관련 주제끼리 이어 주는 지도 역할을 합니다. 설계 단계에서 어떤 페이지가 어떤 페이지로 연결될지 미리 그려 두면, 콘텐츠를 채울 때 링크가 빠지지 않고 주제 사이의 관계가 또렷해집니다.

연결 방식은 중심 문서 하나에 관련 문서를 이어 붙이는 허브 구조가 흔합니다. 큰 주제를 다루는 문서를 가운데 두고 세부 문서를 그 아래로 연결하면, 사람도 AI도 어느 문서가 그 주제의 대표인지 파악하기 쉬워집니다.

렌더링과 크롤러 접근은 어떻게 정해야 하나요?

본문은 서버가 보내는 HTML에 그대로 담기도록 렌더링 방식을 정하는 것이 안전합니다. 대부분의 AI 크롤러는 자바스크립트를 실행하지 않고 서버가 보낸 소스만 읽기 때문에, 화면에만 그려지고 소스에는 없는 텍스트는 인용 후보에 오르지 못합니다.

렌더링 방식은 크게 둘로 나뉩니다. 서버에서 HTML을 완성해 보내는 SSR(서버 사이드 렌더링)과, 브라우저에서 자바스크립트로 화면을 그리는 CSR(클라이언트 사이드 렌더링)입니다. 구글은 자바스크립트를 렌더링하되 시간이 걸릴 수 있다고 안내하고(Google 검색 센터, 2025), 다른 AI 크롤러는 대개 실행하지 않습니다.

두 방식의 차이는 다음과 같습니다.

그래서 콘텐츠 중심 사이트라면 SSR이나, 미리 HTML을 만들어 두는 프리렌더링을 기본값으로 잡는 편이 유리합니다. 리액트나 뷰 같은 프레임워크를 쓰더라도 서버 렌더링 옵션을 켜면 되고, 이 선택은 구축 초기에 정해야 나중에 갈아엎지 않습니다.

읽힘의 다른 축은 크롤러 접근입니다. robots.txt에서 GPTBot·PerplexityBot·ClaudeBot·Google-Extended 같은 AI 봇을 막지 않았는지 확인하고, 보안 플러그인이나 방화벽이 이들을 차단하지 않도록 설계합니다.

llms.txt는 2024년 제안된 방식으로, 사이트가 AI에게 핵심 문서를 안내하는 파일입니다(llmstxt.org, 2024). 아직 모든 AI가 공식 지원하지는 않지만 구축 시 함께 준비해 두면 좋고, 실제 작성 코드는 JSON-LD와 llms.txt 설정법에 정리해 두었습니다.

구조화 데이터와 저자 신뢰 신호는 어떻게 준비하나요?

구조화 데이터는 페이지 유형마다 어떤 스키마를 넣을지 설계 단계에서 미리 정해 두는 것이 핵심입니다. 스키마는 이 페이지가 무엇에 관한 글이고 누가 썼는지를 기계가 읽도록 표시한 꼬리표라, 콘텐츠 템플릿을 만들 때 함께 설계하면 페이지마다 자동으로 붙습니다.

유형별 매핑은 단순합니다. 회사 소개에는 Organization, 블로그 글에는 Article이나 BlogPosting, 자주 묻는 질문에는 FAQPage, 단계형 안내에는 HowTo, 사이트 위계에는 BreadcrumbList를 배정합니다. 어떤 페이지에 무엇을 넣을지 표로 정리해 두면 개발자가 템플릿에 심기 쉽습니다.

구글은 생성형 AI 검색에 구조화 데이터가 필수는 아니라고 밝히므로(Google 검색 센터, 2025), 스키마는 인용을 보장하는 장치가 아니라 검색 리치 결과와 엔티티 이해를 돕는 기초 신호로 봅니다. 코드를 몰라도 스키마를 만드는 방법은 코드를 몰라도 만드는 구조화 데이터에서 다룹니다.

스키마를 설계할 때는 브랜드를 한 이름으로 통일하는 것도 함께 챙깁니다. 회사명과 대표 저자, 자매 사이트 주소를 Organization과 Person 스키마의 sameAs로 이어 두면, AI가 여러 페이지에 흩어진 언급을 같은 주체로 묶어 이해합니다. 이 연결도 콘텐츠 모델에 미리 넣어 둘 항목입니다.

저자 신뢰 신호는 구축 단계에서 저자 페이지와 프로필 구조를 콘텐츠 모델에 포함하는 것으로 시작합니다. 실명 저자와 소개는 경험·전문성·권위·신뢰를 뜻하는 E-E-A-T 신호의 핵심이라, AI는 누가 썼는지 분명한 글을 더 안전하게 인용합니다.

구체적으로는 글마다 실명 저자와 직함, 한 줄 소개가 붙도록 필드를 설계하고, 저자마다 프로필 페이지(ProfilePage)와 Person 스키마를 연결합니다. 이 구조를 콘텐츠 모델에 처음부터 넣어 두면, 글을 쓸 때마다 신뢰 신호가 자동으로 따라붙습니다.

런칭 전 GEO 설계 검증은 어떻게 하나요?

런칭 전에는 설계한 항목이 실제 페이지에 반영됐는지 눈으로 한 번 확인합니다. 개발이 끝난 화면에서 소스를 열어 본문·스키마·저자·크롤러 설정을 점검하면, 잘못 반영된 부분을 배포 전에 잡을 수 있습니다. 이 마지막 점검이 사후 재작업을 막는 관문입니다.

런칭 전 확인할 항목은 다음과 같습니다.

1. 본문 노출: 핵심 문장이 페이지 소스(HTML)에도 그대로 있는지 봅니다.
2. 제목·설명: 페이지마다 title과 meta description이 다르게 채워졌는지 확인합니다.
3. 스키마: 소스에서 ld+json을 검색해 계획한 유형이 심겼는지 봅니다.
4. 저자: 실명 저자와 프로필 링크가 노출되는지 점검합니다.
5. 크롤러: robots.txt에서 AI 봇이 막히지 않았는지 확인합니다.
6. 주소: 대표 주소가 하나로 고정됐고 중복 주소가 정리됐는지 봅니다.

점검은 실제 서비스에 올리기 전, 개발용 임시 환경에서 먼저 하는 편이 안전합니다. 배포 전에 소스와 스키마를 확인하면 잘못된 설정이 검색엔진과 AI에 노출되기 전에 고칠 수 있습니다. 특히 크롤러 차단 설정은 임시 환경과 실제 환경에서 다르게 걸리는 경우가 많아, 양쪽을 함께 확인합니다.

눈으로 하는 점검만으로는 놓치는 신호가 있습니다. 각 항목을 점수로 환산해 우선순위와 수정안을 문서로 받으려면 정식 진단이 필요한데, 진단이 무엇을 어떻게 보는지는 GEO 진단은 무엇을 보나에 6개 영역으로 정리해 두었습니다.

GEOMKT도 자사 사이트를 같은 기준으로 점검했을 때, 스키마·메타·저자 같은 기본기는 갖췄지만 html lang, og:image, llms.txt, FAQ 스키마 같은 특화 항목에서 개선점이 나왔습니다. 이런 항목은 구축 단계에서 점검표에 넣어 두면 처음부터 반영할 수 있습니다.

기본기를 갖춘 사이트에서도 특화 항목이 남는다는 것은, 그만큼 설계 단계의 점검표가 촘촘해야 한다는 뜻입니다. 처음 만들 때 목록에 한 줄을 더해 두는 편이, 나중에 페이지 전체를 다시 손대는 것보다 언제나 쌉니다.

신규 사이트를 GEO에 맞춰 설계하고 있다면, 기획서 단계에서 설계 결정을 한 번 점검받는 것이 재작업을 줄이는 가장 빠른 길입니다. 30분 무료 상담에서 새로 만드는 사이트인지 이미 운영 중인 사이트인지 지금 상황을 듣고, 맞는 범위를 한 가지 제안합니다.

자주 묻는 질문 (FAQ)

Q1. 이미 사이트가 있는데 이 체크리스트가 소용 있나요?

부분적으로 그렇습니다. 정보 구조·URL·렌더링 같은 뼈대는 이미 정해져 있어 바꾸기 어렵지만, 스키마·크롤러·저자 신호는 운영 중에도 보강할 수 있습니다.

운영 사이트라면 먼저 현재 상태를 진단해 바꿀 수 있는 것부터 손보는 편이 효율적입니다. 뼈대에 해당하는 항목은 다음 개편이나 리뉴얼 시점에 반영하면 됩니다.

Q2. 개발자에게 무엇을 요청해야 하나요?

본문이 서버 HTML에 담기는 렌더링(SSR이나 프리렌더링), 페이지 유형별 스키마 템플릿, 저자 페이지와 프로필 구조, robots.txt의 AI 크롤러 허용 네 가지를 기획서에 명시해 전달하면 됩니다.

스키마와 llms.txt의 실제 코드 예시를 함께 주면 개발자와 소통이 한결 빨라집니다. 값을 채우는 세부는 콘텐츠 작업 단계에서 이어서 정리하면 됩니다.

Q3. 스키마는 설계 단계에서 어디까지 정해 두면 되나요?

페이지 유형과 스키마 유형을 짝지은 매핑 표까지면 충분합니다. 회사 소개는 Organization, 글은 Article이나 BlogPosting, 질문 모음은 FAQPage 식으로 정해 두면 개발자가 템플릿에 심습니다.

실제 값 채우기는 콘텐츠를 만들 때 해도 늦지 않습니다. 설계 단계에서는 어떤 페이지에 어떤 유형을 붙일지 결정만 내려 두면 됩니다.

Q4. 신규 구축이라 트래픽 데이터가 없는데 GEO를 어떻게 잡나요?

데이터가 없을 때는 고객이 던질 질문을 기준으로 설계합니다. 어떤 질문에 답하는 사이트인지 정하고, 그 질문마다 페이지·URL·스키마를 배정하면 됩니다.

트래픽 데이터는 런칭 뒤 쌓이는 대로 반영해 페이지를 다듬어 가면 됩니다. 처음부터 완벽한 구조를 노리기보다, 질문 단위로 나눈 뼈대를 먼저 세우는 것이 순서입니다.

Q5. 설계 단계에서 GEO를 반영하면 개발 비용이 늘지 않나요?

대부분은 크게 늘지 않습니다. 렌더링 방식이나 URL 규칙, 스키마 템플릿은 어차피 구축 중에 정하는 항목이라, GEO 기준을 함께 반영하는 데 드는 추가 작업이 크지 않습니다.

오히려 런칭 뒤에 뼈대를 뜯어고칠 때의 재작업 비용이 훨씬 큽니다. 설계 단계의 점검은 비용을 늘리는 일이 아니라 뒤에 치를 비용을 앞당겨 줄이는 일입니다.

[참고] Google Search Central 구조화 데이터·자바스크립트 SEO 가이드(2025), Schema.org 구조화 데이터 표준, llms.txt 제안 표준(llmstxt.org, 2024), 네이버 AI 브리핑(2025), GEOMKT 자사 GEO 진단 보고서(2026).

실제 적용 결과는 사이트 환경에 따라 달라질 수 있습니다.