Index
1. 목적에 맞게 AI 크롤러의 접근 관리하기
테크니컬 GEO의 첫 시작은 AI 크롤러의 접근을 허용하는 것입니다.
물론 테크니컬 GEO를 살펴보기 전에 먼저 짚어야 할 것이 있습니다. 우리 고객은 무엇을 궁금해하고, 우리는 그 질문에 어떤 답을 제공하고 있나요? 고객에게 필요한 답이 준비되어 있어야, 그 답을 발견하고 이해하도록 돕는 기술적 최적화도 의미가 있습니다.
AI 크롤러는 왜 우리 사이트에 접근하나요?
AI 크롤러는 웹사이트를 방문해 글과 정보를 자동으로 수집하는 프로그램입니다. 사람이 브라우저로 페이지를 열어 읽듯, AI 크롤러도 사이트에 접속해 내용을 읽습니다. AI가 우리 콘텐츠를 검색하고 답변의 근거로 활용하려면, 먼저 이 접근이 가능해야 합니다.
AI 크롤러가 우리 사이트에 접근하려는 목적은 크게 세 가지입니다. AI 검색에서 관련 정보를 찾을 수 있도록 콘텐츠를 수집하거나, 사용자의 질문에 답하기 위해 특정 페이지를 읽거나, AI 모델 학습에 사용할 자료를 수집하기 위해서입니다.
따라서 모든 AI 크롤러의 접근을 똑같이 허용할 필요는 없습니다. 검색에 활용하기 위한 접근과 모델 학습을 위한 수집을 구분하고, 우리 콘텐츠의 활용 방침에 맞게 허용 범위를 정해야 합니다.
robots.txt에서 접근 규칙 확인하기
이러한 접근 정책은 robots.txt에 작성합니다. 서버에 텍스트 파일로 저장하기도 하고, 워드프레스처럼 요청을 받으면 내용을 자동으로 생성해 제공하기도 합니다. 따라서 실제 파일이 없더라도 보통 홈페이지 주소 뒤에 /robots.txt를 붙이면 내용을 확인할 수 있습니다. SEO 플러그인에 따라 이 규칙을 관리하거나 수정하는 기능도 제공합니다.
https://example.com/robots.txtrobots.txt는 Google 같은 검색엔진과 AI 크롤러에게 웹사이트의 어떤 페이지를 수집해도 되는지 안내하는 규칙 파일입니다. 크롤러별로 사이트 전체의 수집을 허용하거나, 특정 경로의 수집을 제한하는 규칙을 작성할 수 있습니다.
다만 robots.txt는 크롤러가 따라야 할 규칙을 안내할 뿐, 접근을 강제로 막는 보안 장치는 아닙니다. 외부에 공개하면 안 되는 자료는 로그인이나 서버의 접근 권한 설정으로 별도 보호해야 합니다.
콘텐츠 활용 목적에 맞게 허용 범위 정하기
따라서 크롤러의 접근은 무조건 허용하거나 차단하기보다, 우리 콘텐츠를 어떤 목적으로 활용하도록 할 것인지에 맞춰 설정해야 합니다. 검색을 통한 발견은 허용하면서 모델 학습용 수집은 제한하는 식으로, 서비스별 역할과 제어 범위를 살펴볼 필요가 있습니다.
크리에이티브밴드는 고객사의 콘텐츠 활용 방침에 맞춰 크롤러별 접근 정책을 정리하고, 서버 보안 설정이 필요한 접근까지 막고 있지는 않은지 함께 점검하고 있습니다. 뿐만 아니라 호스팅 제공 업체의 AI 크롤러의 접근 제한 여부 및 상황별 변동에도 대처가 필요합니다.
2. 콘텐츠의 의미와 구조를 정리하는 시맨틱 청킹과 DOM 최적화
AI 크롤러가 사이트에 접근할 수 있다면, 다음은 콘텐츠를 의미 있는 단위로 나누고 문서 구조를 정리해 각 내용의 주제와 관계를 명확하게 전달하는 작업입니다.
하나의 주제나 질문을 중심으로 내용 구성하기
이를 설명하는 개념이 시맨틱 청킹(Semantic Chunking)입니다. 콘텐츠를 단순히 일정한 글자 수로 나누는 것이 아니라, 하나의 주제나 질문에 대한 설명이 하나의 단위로 모이도록 구성하는 것입니다.
예를 들어 서비스 소개 페이지라면 ‘어떤 문제를 해결하는지’, ‘어떻게 진행되는지’, ‘비용은 무엇에 따라 달라지는지’를 각각 소제목과 설명으로 구분할 수 있습니다. 이렇게 구성하면 독자가 필요한 정보를 찾기 쉽고, 문서에서도 각 내용의 범위와 관계가 분명해집니다.
화면의 구분을 HTML 구조에도 반영하기
이러한 구분은 화면의 디자인뿐 아니라 HTML 구조에도 반영되어야 합니다. 소제목을 단순히 큰 글씨나 볼드체로 표시하더라도 코드에서는 일반 문단으로 작성되어 있다면, 제목과 본문의 관계가 구조적으로 드러나지 않을 수 있습니다.
브라우저가 HTML을 해석해 구성한 문서 구조를 DOM(Document Object Model)이라고 합니다. DOM 최적화에서는 제목은 제목 태그로, 비교 정보는 표로, 나열된 항목은 목록으로 표현했는지 살펴봅니다. 또한 의미 없이 중첩된 요소를 줄여 문서 구조를 간결하게 정리합니다.
편집기와 완성된 페이지에서 제목 구조 확인하기
홈페이지 담당자라면 먼저 편집기에서 중간 제목이 실제 ‘제목’으로 지정되어 있는지 확인해보세요. 워드프레스에서는 제목 블록의 H2, H3 설정으로 내용의 계층을 구분할 수 있습니다. 글자 크기를 맞추기 위해 제목 단계를 선택하기보다, 큰 주제는 H2로, 그 안의 세부 주제는 H3로 구성하는 방식입니다.
비교 정보에는 표(<table>)를, 여러 항목(<ul>)이나 진행 순서(<ol>)에는 목록을 사용하면 정보 사이의 관계도 명확해집니다. 다만 편집 화면만으로 실제 HTML 구조를 모두 확인하기는 어렵기 때문에, 완성된 페이지에서 의도한 구조로 출력되는지 점검하는 과정이 필요합니다.
크리에이티브밴드는 콘텐츠의 주제와 흐름을 먼저 정리하고, 그 구분이 HTML 구조에도 반영되도록 작업합니다. 화면에 보이는 배치와 문서의 의미 구조를 함께 살펴보는 것입니다.
3. 회사와 작성자 정보를 명확하게 전달하는 구조화 데이터
콘텐츠의 구조를 정리했다면, 다음은 그 정보가 어떤 회사나 사람에 관한 것이며 누가 작성하고 제공했는지 명확하게 전달하는 작업이 필요합니다.
사람은 회사소개와 로고, 작성자 소개를 보며 정보의 주체를 파악합니다. 검색엔진과 AI에도 이러한 관계를 일정한 형식으로 전달할 수 있는데, 이를 구조화 데이터(Structured Data)라고 합니다. 회사·인물·아티클 등의 유형에 맞춰 이름과 주소, 작성자, 발행 주체 등의 정보를 정리하는 방식입니다.
회사와 공식 프로필 연결하기
같은 이름을 사용하는 회사나 사람이 있다면 이름만으로는 대상을 구분하기 어려울 수 있습니다. 이때 공식 홈페이지와 외부 프로필의 관계를 표시하는 데 사용하는 속성이 sameAs입니다.
예를 들어 회사 정보에 공식 SNS 프로필이나 해당 회사를 설명하는 외부 페이지의 주소를 연결할 수 있습니다. 중요한 것은 관련 있는 페이지가 아니라, 같은 대상을 나타내는 페이지를 연결해야 한다는 점입니다. 유명한 사이트나 업계의 참고 자료를 넣는 항목은 아닙니다. Schema.org 안내
홈페이지 담당자라면 회사소개와 하단 정보, 공식 SNS에서 회사명과 연락처 등이 일관되게 표시되는지 먼저 확인해보세요. 구조화 데이터에 연결된 프로필이 실제 공식 계정인지도 함께 점검해야 합니다.
작성자와 발행 주체, 출처 표시하기
아티클에는 누가 작성했는지, 어느 회사가 발행했는지, 어떤 자료를 참고했는지 표시할 수 있습니다. 구조화 데이터에서는 콘텐츠 유형에 따라 author, publisher, reviewedBy, citation 등의 속성으로 이러한 관계를 설명합니다.
이 정보는 보통 JSON-LD라는 형식의 코드로 페이지에 추가합니다. 워드프레스에서는 SEO 플러그인이나 테마가 일부 정보를 자동으로 생성하기도 합니다.
다만 작성자와 검토자 정보를 코드에 넣는다고 전문성이나 신뢰성이 검증되는 것은 아닙니다. 실제 작성·검토한 사람을 표시하고, 독자도 그 사람의 역할과 관련 경험을 확인할 수 있어야 합니다. 참고 자료 역시 본문에서 출처를 확인할 수 있도록 연결하는 것이 좋습니다.
질문과 답변도 내용에 맞게 구분하기
질문과 답변, 진행 절차를 표현하는 구조화 데이터도 있습니다. FAQPage는 자주 묻는 질문과 답변, QAPage는 하나의 질문에 여러 답변을 제출할 수 있는 페이지, HowTo는 작업을 수행하는 절차를 설명할 때 사용하는 유형입니다.
이름이 비슷해 보여도 용도는 다르므로 실제 페이지에 맞게 적용해야 합니다. 또한 이러한 코드를 추가한다고 AI 답변에 채택되거나 인용되는 것은 아닙니다. Google도 AI 검색을 위한 특별한 구조화 데이터가 필요한 것은 아니라고 안내합니다. Google 공식 안내
적용된 정보 확인하기
구조화 데이터는 화면에 별도로 보이지 않을 수 있습니다. 적용 여부는 Schema Markup Validator에 페이지 주소를 입력해 확인할 수 있습니다. 회사나 아티클 정보가 있는지, 이름과 주소·작성자 등이 실제 내용과 일치하는지 살펴보세요.
검사에서 오류가 없다는 것은 문법과 구조가 유효하다는 의미이며, 정보의 정확성이나 신뢰성을 인증받았다는 뜻은 아닙니다. 잘못된 회사명이나 이전 담당자의 정보가 들어 있다면 플러그인 설정이나 제작사를 통해 수정해야 합니다.
크리에이티브밴드는 화면에 표시되는 회사·작성자 정보와 구조화 데이터가 일치하도록 정리하고, 공식 프로필과 출처의 연결도 함께 점검합니다. 콘텐츠의 내용뿐 아니라 누가 제공한 어떤 정보인지도 명확하게 전달하기 위한 작업입니다.
4. 핵심 내용을 처음부터 전달하는 서버 사이드 렌더링
문서의 구조와 정보의 주체를 정리했다면, 다음은 그 내용이 실제로 어떤 방식으로 전달되는지 확인해야 합니다. 브라우저 화면에 보이는 내용이 크롤러가 처음 받은 문서에도 모두 들어 있는 것은 아니기 때문입니다.
SSR과 사전 렌더링은 무엇인가요?
웹페이지는 서버에서 받은 HTML을 표시한 뒤, 자바스크립트를 실행해 내용을 추가하기도 합니다. 사람의 브라우저에서는 자연스럽게 보이지만, 크롤러마다 자바스크립트를 실행하고 추가 정보를 불러오는 능력에는 차이가 있습니다.
Vercel과 MERJ가 2024년에 공개한 조사에서도 관찰 대상 AI 크롤러의 자바스크립트 처리에 제한이 나타났습니다. 다만 조사 시점과 대상에 따른 결과이므로 모든 AI 크롤러가 항상 같은 방식으로 작동한다고 일반화할 수는 없습니다. Vercel 조사
서버 사이드 렌더링(SSR)은 서버에서 콘텐츠가 포함된 HTML을 만들어 전달하는 방식입니다. 사전 렌더링(Pre-rendering)은 페이지를 미리 생성해 제공하는 방식입니다. 두 방식 모두 크롤러가 별도의 스크립트를 실행하지 않아도 핵심 내용을 읽을 수 있도록 구성하는 데 활용할 수 있습니다.
모든 웹사이트를 새로 구축해야 한다는 의미는 아닙니다. 먼저 현재 홈페이지의 주요 정보가 초기 HTML에 포함되어 있는지 확인하는 것이 순서입니다.
탭과 아코디언 안의 내용도 초기 HTML에 포함하기
탭이나 아코디언으로 내용을 접어두는 것 자체가 문제는 아닙니다. 이미 전달된 내용을 펼쳐 보여주는지, 클릭한 뒤에야 서버에서 가져오는지를 구분해야 합니다.
예를 들어 자주 묻는 질문의 답변이 처음부터 HTML에 들어 있고 클릭으로 표시 상태만 바뀐다면, 크롤러가 내용을 읽기 위해 반드시 버튼을 누를 필요는 없습니다. 반면 클릭할 때마다 AJAX로 답변을 불러오는 구조라면 수집 방식에 따라 내용이 누락될 수 있습니다.
페이지 소스에서 핵심 문장 확인하기
컴퓨터 브라우저의 페이지 소스 보기를 열고, 서비스 설명이나 FAQ 답변의 특징적인 문장을 검색해보세요.
문장이 없다면 나중에 불러오는 구조인지 확인이 필요합니다. 문장이 있더라도 실행용 데이터 안에만 포함되어 있을 수 있으므로, 정확한 판단은 제작사에 요청하는 것이 좋습니다.
주요 서비스 설명과 FAQ 답변이 초기 HTML 본문에 포함되는지 확인해주세요. 클릭 후에만 불러오는 내용이라면 검색 크롤러에도 전달되는지 점검 부탁드립니다.
5. 필요한 내용을 찾고 공유하기 쉬운 요약과 앵커 링크
콘텐츠가 전달된 다음에는 독자가 필요한 부분을 빠르게 찾을 수 있도록 정리할 차례입니다. 긴 글의 핵심 요약과 특정 위치로 이동하는 링크는 내용을 읽고 공유하는 데 도움이 됩니다.
프래그먼트 식별자로 특정 위치 연결하기
프래그먼트 식별자(Fragment Identifier)는 웹주소 뒤에 붙는 #이름으로, 페이지 안의 특정 위치를 가리킵니다.
https://example.com/guide/#server-hosting이 주소를 열면 페이지의 server-hosting 위치로 이동합니다. 이를 위해 해당 제목이나 요소에 같은 이름의 id를 지정합니다.
워드프레스에서는 제목 블록을 선택하고 고급 → HTML 앵커에 이름을 입력할 수 있습니다. 예를 들어 server-hosting을 입력한 뒤, 목차나 다른 글에서 해당 주소를 연결하는 방식입니다. 같은 페이지 안에서는 이름이 중복되지 않아야 합니다.
이 기능은 특정 설명이나 표를 다른 사람에게 전달할 때도 유용합니다. 다만 앵커를 추가한다고 AI가 반드시 해당 위치를 인용 링크로 사용하는 것은 아닙니다.
크리에이티브밴드의 검색자산 웹사이트에서는 이러한 링크를 활용할 수 있도록 HTML 앵커를 자동 생성하는 기능을 제공하고 있습니다.
핵심 요약을 페이지 상단에 제공하기
글의 핵심을 앞에서 먼저 전달하는 방식을 BLUF(Bottom Line Up Front)라고 합니다. 긴 글을 짧게 요약하는 TL;DR(Too Long; Didn’t Read)도 비슷한 목적으로 사용됩니다.
요약에는 글이 다루는 질문과 핵심 답변을 담습니다. 결론이 특정 조건에서만 성립한다면 그 조건도 함께 적어야 합니다.
예를 들어 “VPS가 공유 호스팅보다 좋습니다”라는 문장보다 다음과 같이 정리할 수 있습니다.
VPS는 운영 환경을 분리하고 서버 설정을 조정하기에 유리합니다. 다만 보안 업데이트와 백업을 담당할 관리 주체가 필요합니다.
요약은 이미지 안에만 넣기보다 본문 텍스트로 제공하는 것이 좋습니다. 크리에이티브밴드의 검색자산 관리 시스템에서 생성하는 초안에도 상단 요약 블록이 포함됩니다.
6. 콘텐츠의 변경 사항을 알리는 IndexNow와 사이트맵
새 글을 발행하거나 내용을 수정해도 검색엔진이 그 변화를 즉시 확인하는 것은 아닙니다. 변경 사실을 알리고 정확한 수정 정보를 제공하면, 검색엔진이 갱신된 콘텐츠를 발견하고 처리하는 데 도움을 줄 수 있습니다.
IndexNow로 URL 변경 사실 알리기
IndexNow는 콘텐츠가 생성·수정·삭제되었을 때 참여 검색엔진에 해당 URL의 변경 사실을 알리는 프로토콜입니다.
일반적인 수집에서는 크롤러가 사이트를 다시 방문해 변경 사항을 발견합니다. IndexNow는 웹사이트가 먼저 변경을 알리는 푸시(Push) 방식입니다.
다만 변경 알림과 실제 색인은 다릅니다. 알림을 받았다고 검색엔진이 즉시 페이지를 수집하거나 검색 결과에 포함하는 것은 아닙니다. 따라서 ‘실시간 색인’보다는 ‘URL 변경 알림’으로 이해하는 것이 정확합니다. IndexNow 공식 안내
워드프레스에서는 사용 중인 SEO 플러그인이나 별도 도구가 IndexNow를 지원하는지 확인할 수 있습니다. 이미 전송 기능이 있다면 중복으로 설치하기보다 활성화 상태와 전송 기록을 살펴보세요.
IndexNow는 이를 지원하는 검색엔진을 위한 기능입니다. Google과 Naver의 사이트 등록 및 사이트맵 관리까지 대체하는 것은 아닙니다.
사이트맵에서 페이지와 수정 시각 확인하기
사이트맵은 검색엔진에 웹사이트의 페이지 목록을 전달하는 파일입니다. 워드프레스에서는 설정에 따라 다음과 같은 주소에서 확인할 수 있습니다.
https://example.com/sitemap.xml
https://example.com/sitemap_index.xml사이트맵이 여러 파일로 나뉘어 있다면 게시글이나 페이지에 해당하는 목록을 열어 확인합니다.
여기에 포함되는 lastmod는 해당 페이지가 마지막으로 의미 있게 수정된 시점을 나타냅니다. 날짜와 시간은 ISO 8601 같은 표준 형식으로 표현할 수 있습니다.
<lastmod>2026-10-24T09:00:00+09:00</lastmod>이 예시는 한국 시간으로 2026년 10월 24일 오전 9시를 의미합니다. 다만 모든 사이트맵이 시간까지 표시해야 하는 것은 아니며, 중요한 것은 실제 변경을 정확하게 반영하는 것입니다.
Google도 본문의 주요 내용이나 구조화 데이터처럼 의미 있는 변경에 맞춰 lastmod를 제공하도록 안내합니다. 내용은 그대로인데 최신 글처럼 보이도록 날짜만 바꾸는 방식은 피해야 합니다. Google 사이트맵 안내
발행일과 수정일이 일치하는지 점검하기
Yoast SEO 같은 플러그인은 사이트맵과 페이지의 메타데이터·구조화 데이터에 날짜 정보를 생성할 수 있습니다. 실제 출력 항목은 콘텐츠 유형과 설정에 따라 달라집니다.
홈페이지 담당자라면 글을 수정한 뒤 다음을 확인해보세요.
- 본문에 표시되는 수정일이 정확한지
- 사이트맵의 해당 URL에 수정 날짜가 반영되는지
- 페이지 소스의 발행일과 수정일이 실제 이력과 맞는지
서로 다른 날짜가 표시된다면 각 날짜의 의미와 생성 기준을 제작사에 확인해야 합니다. 모든 페이지가 같은 시각으로 갱신되거나, 실제 수정 후에도 오래된 날짜가 유지되는 경우도 점검 대상입니다.
크리에이티브밴드는 콘텐츠를 발행하는 것과 함께, 변경된 정보가 검색엔진에 전달될 수 있는 설정과 날짜 정보도 점검하고 있습니다.
Index