사이트맵의 개념과 필요성
사이트맵이란 웹 사이트 내의 페이지, 동영상, 이미지, 뉴스 등 콘텐츠의 목록을 나열하고, 그 관계에 관한 정보를 체계적/계층적으로 명시한 것을 말합니다.
Google 등의 주요 검색엔진들이 해당 정보를 바탕으로 조금 더 효율적으로 페이지를 크롤링할 수 있도록 돕는 역할을 합니다.
웹 사이트(관리자)의 입장에서는 중요하거나 강조하고 싶은 정보를 명시적으로 검색엔진에 알려주고자 하는 목적과 의도를 가집니다만, 검색엔진의 입장에서는 어디까지나 이것을 가이드라인 정도로만 참고하기 때문에, 사실 막상 사이트맵을 추가한다고 해서 괄목할 만한 최적화(SEO) 효과를 기대하기는 어려울 수 있습니다.
기본적으로 웹 사이트의 페이지 구조와 링크 관계가 정상적으로 잘 구성되어 있다면, 굳이 사이트맵이 없어도 검색엔진이 대부분의 페이지를 찾아 크롤링 및 인덱싱할 수 있기 때문입니다.
다만 사이트의 규모가 크고 복잡하거나, 중요한 페이지의 링크가 적절히 연결되어 있지 않은 경우 등에는 사이트맵이 도움이 될 수 있습니다.
어떠한 경우에 사이트맵이 필요하고, 필요하지 않은지에 대해 Google의 문서를 인용하여 정리해 보자면 아래와 같습니다.
사이트맵이 필요한 경우
규모가 큰 사이트
- 일반적으로 사이트 규모가 클 수록 검색엔진이 페이지 간의 링크 관계를 파악하기 어렵거나 발견하지 못할 가능성이 높아지기 때문에, 이 때는 사이트맵이 적절한 힌트가 될 수 있습니다.
연결되는 외부 링크가 많지 않은 새로운 사이트
Googlebot등의 웹 크롤러들은 한 페이지에서 다른 페이지로 연결되는 링크를 따라가면서(follow) 크롤링을 수행하기 때문에, 다른 사이트가 페이지에 링크되어 있지 않으면 페이지를 찾지 못하게 될 수 있습니다.- 사이트 내부적으로도 페이지 간의 링크 관계가 잘 구성되어 있지 않은 경우에는 사이트맵이 도움이 될 수 있습니다. 또한 새롭게 추가되거나 업데이트된 페이지를 크롤링하도록 유도하는 힌트가 될 수 있습니다.
리치 미디어 콘텐츠(동영상, 이미지)가 많거나 뉴스에 노출되는 사이트
- 미디어 콘텐츠가 많은 페이지는 크롤러가 페이지를 정확히 분석하지 못할 가능성이 있기 때문에, 이러한 콘텐츠에 대한 부가 정보를 제공하면 도움이 될 수 있습니다. 검색엔진이 사이트 내의 콘텐츠 정보를 이해하고 검색 결과로 노출할 때, 사이트맵에 명시되어 있는 부가 정보를 참고하게 됩니다.
사이트맵이 필요하지 않은 경우
규모가 작은 사이트
- 문서 내용에 따르면, 구체적으로는 사이트를 구성하는 페이지의 개수가 500여개 이하인 경우를 의미합니다.
내부적으로 링크 관계가 긴밀하게 구성된 사이트
- 검색엔진이 사이트의 시작(홈) 링크를 진입점으로 따라가면서, 다른 모든 중요한 내부 페이지들을 잘 발견할 수 있는 경우라면 사이트맵이 굳이 필요하지 않을 수 있습니다.
검색 결과에 노출하려는 미디어 콘텐츠(동영상, 이미지) 또는 뉴스 페이지가 많지 않거나 없는 사이트
- 미디어, 뉴스 콘텐츠를 검색 결과에 노출할 필요가 없는 경우, 사이트맵을 사용하지 않아도 무방합니다.
사이트맵 생성하기
일반적으로 검색엔진들은 사이트맵 프로토콜을 준수하여 정의된 사이트맵을 지원하고 있습니다.
XML, RSS, 단순 Text 포맷으로 사이트맵을 구성할 수 있는데, 상황에 따라 취사선택할 수 있습니다.
Google 문서를 인용하자면 아래와 같습니다.
XML
가장 다양한 용도로 사용할 수 있는 포맷입니다. 확장이 쉽고 이미지, 동영상, 뉴스 콘텐츠뿐만 아니라 현지화된 버전(i18n)에 대한 정보도 제공할 수 있습니다.
장점
- 확장 가능하고 다용도로 사용 가능
- URL에 대해 가장 많은 정보를 제공할 수 있음
- CMS를 사용하는 경우 플러그인의 도움을 받기 용이함
단점
- 사용하기에 번거로울 수 있음
- 규모가 큰 사이트 또는 URL이 자주 변경되는 사이트에서는 유지 관리가 복잡하고 번거로울 수 있음
RSS / mRSS / Atom 1.0
XML과 비슷한 구조이지만, CMS를 사용하는 경우라면 일반적으로 자동 생성되는 경우가 많아 상대적으로 간편하게 제공할 수 있습니다.
장점
- 대부분의 CMS에서 자동으로 생성
- 동영상 정보를 제공할 때 활용
단점
- HTML 및 기타 색인 생성이 가능한 페이지 외 이미지 또는 뉴스가 아닌 동영상에 대한 정보만 제공 가능
- 사용하기에 번거로울 수 있음
Text
가장 단순한 포맷으로, 페이지의 URL 정보만 한 줄에 하나씩 명시하는 방식으로 구성됩니다.
장점
- 규모가 매우 큰 사이트에서 쉽게 사용하고 관리할 수 있음
단점
- HTML 및 기타 색인 생성이 가능한 페이지에서만 사용 가능
아래는 일반적인 XML 포맷의 사이트맵 샘플입니다.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/</loc>
<lastmod>2023-01-01</lastmod>
<changfreq>monthly</changefreq>
<priority>0.8</priority>
</url>
</urlset><!-- Image (Google) -->
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
<url>
<loc>https://example.com/image.html</loc>
<image:image>
<image:loc>https://example.com/image.jpg</image:loc>
</image:image>
</url>
</urlset><!-- Video (Google) -->
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:video="http://www.google.com/schemas/sitemap-video/1.1">
<url>
<loc>https://example.com/video.html</loc>
<video:video>
<video:thumbnail_loc>https://example.com/thumbs/thumb1.jpg</video:thumbnail_loc>
<video:title>Grilling steaks for winter</video:title>
<video:description>
In the freezing cold, Roman shows you how to get perfectly done steaks every time.
</video:description>
<video:content_loc>
http://stream.example.com/video1.mp4
</video:content_loc>
<video:player_loc>
https://example.com/videoplayer?video=1
</video:player_loc>
</video:video>
</url>
</urlset><!-- News (Google) -->
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:news="http://www.google.com/schemas/sitemap-news/0.9">
<news:news>
<news:publication>
<news:name>The Example Times</news:name>
<news:language>en</news:language>
</news:publication>
<news:publication_date>2023-01-01</news:publication_date>
<news:title>Companies A, B in Merger Talks</news:title>
</news:news>
</urlset>사이트맵의 모든 데이터 값은 반드시 엔티티 이스케이프 처리되어야 하며, 파일의 캐릭터셋 인코딩은 UTF-8이어야 합니다. 또한 구체적으로 사이트맵은 아래에서 설명하는 것처럼 정해진 규칙을 따라야 합니다.
<urlset>여는 태그로 시작하고,</urlset>닫는 태그로 끝나야 합니다.<urlset>태그에는 네임스페이스(프로토콜 표준)이 속성으로 지정되어야 합니다.- 각 URL은
<url>태그를 상위로 포함한 형태로 구성되어야 합니다.- 각
<url>태그는 하위에<loc>태그가 포함되어야 합니다.- 이외의 다른 태그들은 모두 선택사항이며, 검색엔진에 따라 지원 여부가 다를 수 있습니다.
- 사이트맵의 모든 URL은 단일 호스트에서 가져와야 합니다.
- 사이트맵에 포함될 수 있는 URL은 사이트맵의 파일 위치에 따라 결정됩니다. 예를 들어
https://example.com/catalog/sitemap.xml에 위치한 사이트맵 파일에는https://example.com/catalog/로 시작하는 URL만 포함될 수 있으며,https://example.com/images/같은 URL은 포함될 수 없습니다.
즉, <urlset> 요소를 루트로 하고, 각 페이지의 URL들은 <url> 요소로 반복되는 구조입니다.
<url> 요소는 페이지의 URL을 명시하는 <loc> 요소 외에도 <lastmod>, <changefreq>, <image>, <news>, <video> 등이 올 수 있고 이를 통해 부가적인 정보를 확장할 수 있지만, 위에서 언급했듯 검색엔진에 따라 지원 여부가 다릅니다. 가령 <image>, <news>, <video>들은 Google 검색엔진에서 사용되는 경우입니다.
각 요소에 대한 개략적인 설명을 나열하자면 아래와 같습니다.
<loc>
- 페이지의 URL을 명시합니다. URL은
https:와 같이 반드시 프로토콜(scheme)로 시작해야 하며, 웹 서버에서 요구하는 경우에는 후행 슬래시(trailing slash)로 끝나야 합니다. 또한 최대 2,048자 미만이어야 합니다.
<lastmod>
- 해당 URL이 가리키는 페이지가 마지막으로 수정된 날짜입니다. 이때 날짜는 W3C 날짜/시간 포맷이어야 합니다.
- 날짜는 사이트맵이 생성된 날짜가 아니라, 페이지가 마지막으로 수정된 날짜여야 합니다.
<changefreq>
- 페이지가 업데이트되는 빈도를 명시합니다. 검색엔진의 크롤링 빈도를 조정할 힌트를 제공할 수는 있지만, 어디까지나 힌트입니다.
- Google 검색엔진은 이 값을 무시합니다.
- 다음과 같은 값이 올 수 있습니다.
always,hourly,daily,weekly,monthly,yearly,never
<priority>
- 다른 URL에 대비한 해당 URL의 상대적인 우선순위입니다.
- 검색엔진에게 페이지의 중요도를 직접 알려주려는 의도를 나타냅니다.
- Google 검색엔진은 이 값을 무시합니다.
- 값은 0.0 ~ 1.0으로 지정되어야 하며, 기본 우선순위는 0.5입니다. 이 수치가 검색 결과 페이지에서 노출되는 순서에 영향을 미치지는 않습니다. 다만 색인 대상에 포함될 가능성을 높일 수는 있습니다.
<image> / <news> / <video>
- Google 검색엔진에서 사용되는 확장 요소입니다. 각각 이미지, 뉴스, 동영상 콘텐츠를 직접적으로 명시하여 Googlebot 크롤러가 발견하지 못할 수 있는 콘텐츠를 알릴 수 있습니다. 예를 들면 자바스크립트 코드에 의해 로드되는 콘텐츠가 이런 경우에 해당합니다.
- 각 요소에 대한 상세한 명세는 아래 Google 문서를 참고합니다.
이미지 사이트맵
동영상 사이트맵
뉴스 사이트맵
샘플 XML에서도 확인할 수 있었듯, 사용하려는 확장 요소에 따라 <urlset> 요소의 속성으로 네임스페이스 프로토콜을 정의해야 합니다.
여기서 hreflang 속성은 보통 다국어 페이지 정보를 명시하려는 경우, 즉 i18n 지원시 사용하거나, 데스크톱 페이지와 모바일 페이지의 URL이 분리되어 있어 다른 한 쪽의 대체(alternate) URL로 명시하려는 경우 등에 사용할 수 있습니다.
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://example.com/ko/page.html</loc>
<xhtml:link
rel="alternate"
hreflang="en"
href="https://example.com/en/page.html"/>
</url>
</urlset><?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://example.com/</loc>
<xhtml:link
rel="alternate"
media="only screen and (max-width: 640px)"
href="https://m.example.com/"/>
</url>
</urlset>사이트맵 제약사항 및 권장사항
사이즈 제한
사이트맵의 포맷과는 무관하게, 50MiB(52,428,800bytes) 또는 URL 50,000개를 초과할 수 없다는 제약이 있습니다.
만약 사이트맵이 이것보다 더 크거나 많다면, 분할해서 생성한 다음 사이트맵 색인(sitemapindex) 파일을 만들어 분할된 각 사이트맵 파일의 경로를 명시해주어야 합니다.
색인 파일을 생성하면, 추후 Google Search Console 등의 검색 관리 웹 마스터 도구에서 사이트맵을 제출할 때 각 사이트맵 파일이 아닌 색인 파일 하나만 제출해도 됩니다.
사이트맵 색인 파일은 아래와 같이 작성합니다.
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap1.xml</loc>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap2.xml</loc>
</sitemap>
</sitemapindex>이때, 사이트맵 파일은 gzip 압축을 통해 사이즈를 줄일 수도 있습니다. 즉, 일반적으로 검색엔진은 사이트맵 파일에 대한 콘텐츠 협상(content negotiation) 과정에서 gzip 인코딩 형식도 허용합니다.
다만 사이즈 제한은 압축 이전의 원본을 기준으로 하므로, 50MiB를 초과할 수 없다는 것은 변하지 않습니다.
아래와 같이 사이트맵 파일의 확장자를 명시하는 방식으로 압축된 파일임을 나타낼 수 있습니다.
<loc>https://example.com/big-sitemap.xml.gz</loc>프로토콜
URL의 프로토콜(scheme)은 HTTPS가 바람직합니다. 아래와 같이 특별한/예외적인 경우가 아니라면, 검색엔진은 기본적으로 HTTPS를 선호하기 때문입니다.
- 페이지에 잘못된 TLS/SSL 인증서가 존재하는 경우
- 페이지에 보안이 취약한 종속 콘텐츠(이미지는 제외)가 존재하는 경우
- HTTPS 페이지에서 사용자를 HTTP 페이지로 리디렉션하는 경우
- HTTPS 페이지에 HTTP 페이지로 연결되는
rel="canonical"link가 존재하는 경우
URL이 HTTP더라도, 아래와 같이 HTTPS 페이지에 대한 선호도를 나타낼 수 있습니다.
- HTTPS 페이지로 연결되는 리디렉션 추가
- HTTP 페이지의
el="canonical"link를 HTTPS 페이지에 추가- HTTPS 연결을 강제하는
HSTS정책을 구현
지원 중단된 페이지의 URL에 301 리디렉션 사용
다음과 같이 페이지를 여러 경로로 접근할 수 있는 상황일 때,
https://example.com/homehttps://home.example.comhttps://www.example.com
이 중 하나의 페이지만 사이트를 대표하는 '표준 URL'로 선택하고, 나머지 페이지에서는 301 리디렉션으로 트래픽을 우회시키면 검색엔진이 정확한 페이지로 연결되도록 제어할 수 있습니다.
HTTP 301 상태 코드는 moved permanently, 영구적으로 페이지가 새로운 위치로 이동했음을 나타내므로 의미론적으로 적절합니다.
표준 / 대표 페이지
사이트맵에서 명시하는 모든 URL은 정규화된 절대 URL이어야 합니다. 검색엔진은 명시된 URL 그대로를 크롤링하기 때문입니다.
예를 들어 https://example.com/page.html 일 때, /page.html 과 같은 상대 URL 형태로 지정해서는 안 됩니다.
Google의 경우를 예로 들면, 일반적으로 검색 결과에 표시하는 URL은 표준 URL입니다. 이때 '표준 URL'이란, 여러 페이지의 URL이 중복될 때 그 사이트를 가장 대표(canonical)할 수 있는 URL을 말합니다.
https://example.com/search?keyword=iphone, https://example.com/search/iphone 와 같이 여러 URL이 존재할 때, 검색엔진은 이 중 하나를 표준 URL로 선택합니다.
서로 다른 페이지가 HTML 레벨에서 서로 완전하게 일치해야만 중복으로 간주되는 것은 아닙니다. 가령 쇼핑몰 사이트를 예를 들면, 어떤 리스트 형태의 상품 검색 결과 페이지에서 정렬이나 필터링 조건 등을 변경하여 콘텐츠가 변경되었다고 해도 그 변경된 페이지들이 각각 고유한 페이지로 간주되지는 않습니다.
페이지의 메인 콘텐츠가 무엇인지, 가장 온전하고 유용한 정보가 포함된 페이지가 무엇인지 등은 검색엔진이 직접 판단하며, 여러 중복된 URL들 중 표준 페이지를 지정하게 됩니다.
그리고 표준 페이지는 가장 높은 빈도로, 정기적으로 크롤링되며, 나머지 중복 페이지들은 사이트의 부담을 줄이기 위해 상대적으로 적게 크롤링됩니다.
페이지가 HTTP/HTTPS 프로토콜인지, 페이지의 품질은 어떠한지, 사이트맵에서 명시하고 있는 URL인지, rel="canonical" 라벨이 있는지 등의 복합적인 요인으로 표준 페이지가 선정됩니다.
표준 페이지는 사이트 콘텐츠의 품질을 평가하는 주요 기준이자 대상이며, 검색 결과 또한 대부분 표준 페이지를 노출하기 때문에 매우 중요합니다.
다만 예외도 있는데, 예를 들어 데스크톱 페이지가 표준 페이지이지만, 사용자가 모바일 디바이스에서 이용하고 있는 경우와 같이, 명백하게 더 적합한 중복 페이지가 존재하는 경우에는 중복 페이지를 노출할 수도 있습니다.
여기서 '유사한', '중복된' 페이지란 구체적으로 다음과 같은 경우를 가리킵니다.
- 사이트가 여러 디바이스/플랫폼을 지원하는 경우
https://example.com/news/koala-rampage
https://m.example.com/news/koala-rampage
https://amp.example.com/news/koala-rampage- 쿼리 파라미터에 의한 동적 URL이 사용되는 경우
https://www.example.com/products?category=dresses&color=green
https://example.com/dresses/cocktail?gclid=ABCD
https://www.example.com/dresses/green/greendress.html- 같은 페이지에 대해 여러 접근 경로(URL)을 지정한 경우
https://blog.example.com/dresses/green-dresses-are-awesome/
https://blog.example.com/green-things/green-dresses-are-awesome/- www가 있는 버전과 없는 버전, http/https 프로토콜, 포트 등에 의해 같은 콘텐츠이지만 다른 형태로 설정된 경우
http://example.com/green-dresses
https://example.com/green-dresses
https://www.example.com/green-dresses
https://example.com:80/green-dresses
https://example.com:443/green-dresses- 다른 사이트에 신디케이션*하기 위해 제공한 콘텐츠가 이러한 도메인에 부분적/전체적으로 복제된 경우
https://news.example.com/green-dresses-for-every-day-155672.html (신디케이션)
https://blog.example.com/dresses/green-dresses-are-awesome/3245/ (원본)'신디케이션'이란 웹 사이트가 보유한 콘텐츠를 다른 웹 사이트가 이용할 수 있도록 제공하는 방식 중 하나를 의미합니다. 예를 들면, 사이트의 어떤 콘텐츠가 신규 등록되었음을 검색엔진에게 알려서(ping) 보다 빠르고 정확하게 색인될 수 있도록 하는 경우가 있습니다.
표준 페이지가 적절하고 명확하게 지정되면, 결과적으로 다음과 같은 이점이 있습니다.
- 검색 결과에 노출할 URL을 제어/지정할 수 있음
- 유사하거나 중복된 페이지의 링크를 단일 URL로 쉽게 통합할 수 있음
- 단일 제품 또는 주제와 관련된 측정/트래킹 항목을 단순화할 수 있음
- 신디케이션 콘텐츠를 관리할 수 있음
- 중복된 페이지에 대한 불필요한 크롤링을 방지할 수 있음
모바일 우선 (mobile-first)
일반적으로 웹 개발에서 모바일 플랫폼을 우선으로 개발하는 것처럼, Google 검색엔진 역시 모바일 페이지를 우선으로 크롤링 및 인덱싱합니다. 스마트폰 에이전트로 크롤링된 모바일 버전의 페이지를 먼저 확인하고 사용하는데, 이것을 Google은 모바일 중심 색인 생성(mobile-first-indexing)이라고 설명합니다.
꼭 모바일 버전의 페이지가 존재해야만 검색결과에 노출될 수 있는 것은 아니지만, 가급적이면 모바일 버전의 페이지가 존재하는 상황을 강력하게 권장합니다. 때문에 같은 URL, 같은 HTML로 사용자 환경에 따라 콘텐츠를 다른 형태로 표시할 수 있는 반응형 웹 디자인을 선택하는 것이 바람직하다고 설명하고 있습니다.
하지만 적응형 웹, 즉 데스크톱 페이지와 모바일 페이지가 물리적으로 구분되어 있는 사이트인 경우에는 고민이 될 수 있습니다. 어쨌든 URL이 두 개가 존재하는 상황이고, 모바일 페이지가 우선한다고 하니 무조건 모바일 URL을 대표 URL로 명시하는 것이 맞겠구나 하고 생각할 수 있습니다만, 상황에 따라 그렇지 않을 수도 있습니다.
일단, 사이트의 URL이 두 가지 버전이 존재한다면 원칙적으로 하나만 명시하는 것이 좋습니다. 다만 위에서 언급한 것처럼 alternate 링크를 추가하여 힌트를 제공하는 것도 가능합니다. 아래는 관련 Google 문서를 인용한 것입니다.
Google은 일반적으로 검색결과에 표준 URL을 표시하는데, 사이트맵을 사용해 이 표준 URL에 영향을 줄 수 있습니다. 페이지의 모바일 버전과 데스크톱 버전 URL이 다르다면 사이트맵에서 한 버전에만 연결하는 것이 좋습니다. 하지만, 두 URL을 모두 가리키도록 하려면 URL에 주석을 추가하여 데스크톱 버전과 모바일 버전을 표시합니다.
대표 URL은 그 사이트의 구조와 콘텐츠에 따라 달라질 수 있습니다. 이는 데스크톱 페이지와 모바일 페이지의 콘텐츠가 서로 동일한지를 확인하여 판단해야 합니다.
같은 콘텐츠라고 해도, DOM 또는 레이아웃에서 차이가 발생한다면 검색엔진은 이것을 다른 콘텐츠, 별개의 페이지라고 이해할 수 있습니다. 모바일 페이지는 데스크톱 페이지에 비해 물리적인 공간 등의 문제로 콘텐츠가 생략되어 있는 경우가 많은데, 이런 경우 아코디언, 탭 등을 활용한다거나, 실제로 노출은 하지 않더라도 페이지 HTML에는 존재하게끔 하는 식으로 모든 콘텐츠를 포함하게끔 하는 편이 바람직합니다.
만약 모바일 페이지의 콘텐츠가 데스크톱에 비해 더 적은데도 모바일 중심의 색인이 이루어지는 경우에는, 검색엔진에서 그만큼 가져갈 수 있는 정보가 적어지므로 부분적인 트래픽 손실이 발생할 수 있습니다. 서로 동일한 콘텐츠라고 간주되어야만 데스크톱, 모바일 두 버전 모두 동일한 검색 순위가 지정될 수 있습니다.
사이트맵 제출하기
앞에서도 언급했듯, 사이트맵을 Google Search Console 또는 Naver Search Advisor 같은 웹 마스터 도구에 제출하더라도 검색엔진은 이를 힌트 정도로만 참고합니다.
검색엔진이 실제로 사이트맵 파일을 다운로드한다거나, 사이트를 크롤링할 때 사이트맵에 명시된 URL을 그대로 사용한다는 보장은 없습니다. 페이지를 크롤링하고 인덱싱하는 메커니즘은 전적으로 검색엔진의 알고리즘으로 결정됩니다.
Google 기준으로 사이트맵을 제출하는 방법은 아래와 같습니다.
Google Search Console페이지에서 직접 제출합니다. 이 경우Googlebot크롤러가 사이트맵에 액세스한 시점, 잠재적인 오류 처리 내역 등도 함께 확인할 수 있습니다. 다만 이 방법은 해당 사이트에 대한 소유권을 가진 상태여야 합니다.Search Console Sitemaps API를 사용하여 프로그래매틱 방식으로 제출할 수도 있습니다. 다만 이 경우에는 OAuth 인증이 요구되므로, 사이트에 대한 소유권은 물론 별도의 인증 절차가 필요합니다.ping도구를 사용합니다. 브라우저나 CLI 등을 통해 아래 주소로 HTTP GET 요청을 보내 사이트맵의 전체 URL을 알릴 수 있습니다. 이 방식은 Google에만 해당하는 내용이 아니라, 공식적으로 사이트맵 프로토콜에서 명시하는 방법이기도 합니다.
# <searchengine_URL>/ping?sitemap=<sitemap_URL>
curl -X GET https://www.google.com/ping?sitemap=https://example.com/sitemap.xml이때 확인해야 할 공통적인 사항은 봇이 해당 사이트맵에 접근이 가능한 상태인지 여부입니다. 만약 robots.txt에서 거부하도록 명시하고 있다거나 웹 서버 설정 등으로 인해 외부에서의 접근에 문제가 있는 경우라면, 사이트맵을 가져가지 않습니다.
Googlebot의 경우 접근 가능 여부는 라이브 URL 검사 도구 등을 사용하여 확인해볼 수 있으며,Naver Search Advisor라면 웹 마스터 도구 페이지에서 확인할 수 있습니다.
robots.txt 파일 내 아무 곳에 아래의 행을 삽입하여 사이트맵 URL을 지정하면, 크롤러가 다음 크롤링을 수행할 때 경로를 확인하게 됩니다.
Sitemap: https://example.com/sitemap.xml이후로는 사이트맵이 검색엔진에 의해 확인되었는지, 사이트맵을 적용한 이후로 검색 결과나 트래픽 등에 변화가 있었는지 등을 체크해 보면서, 지속적으로 사이트맵 파일을 적절하게 관리하면 됩니다. 다만 변경 사항이 즉시 반영되는 것은 아니어서, 확인하기까지는 다소 시간이 소요될 수 있습니다.
참고 문서
