이전 글에서, 크롤링 봇이 이해하기 좋은 페이지를 만드는 것이 중요하다고 언급한 바 있다. 크롤링 봇이 사이트의 내용을 이해하지 못한다면 크롤링이 불가능하고, 당연히 검색 결과에도 페이지가 표시될 수 없다.
그렇다면 크롤링 봇은 단순히 사람처럼 페이지 내용을 읽는 것 만으로 사이트를 이해하는 것일까? 물론 아니다. 봇이 페이지를 이해하기 쉽도록 정보를 제공해 주는 수단은 여러 가지 있는데, 오늘은 사이트맵과, 구조화된 데이터 및 메타 데이터에 대해 다룰 것이다.

## 사이트맵 - 봇에게 사이트의 지도를 제공하자

사이트맵이란, 사이트에 있는 페이지, 동영상 및 기타 파일과 각 관계에 관한 정보를 제공하는 파일이다.([사이트맵이란 무엇인가요? - Google 검색 센터](https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview?hl=ko)) 통상 사이트맵은 이 사이트에 어떤 페이지들이 있는지, 그 주소의 목록을 제공한다. 그 외에 동영상이나 이미지 같은 콘텐츠에 대한 정보를 포함할 수도 있다. 사이트맵은 보통 아래와 같이 생긴 xml 문서이다.

```xml
<?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" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:mobile="http://www.google.com/schemas/sitemap-mobile/1.0" xmlns:image="http://www.google.com/schemas/sitemap-image/1.1" xmlns:video="http://www.google.com/schemas/sitemap-video/1.1">
    <url>
        <loc>https://prayinforrain.github.io</loc>
        <lastmod>2025-06-25T01:22:43.182Z</lastmod>
    </url>
    <url>
        <loc>https://prayinforrain.github.io/about</loc>
        <lastmod>2025-06-25T01:22:43.183Z</lastmod>
    </url>
    
</urlset>
```

사이트맵에 대해 알아야 할 정보들을 나열해보자.

- 페이지의 url(`loc`), 최근 수정일(`lastmod`), 페이지 갱신 빈도(`changefreq`) 등의 속성이 있지만, 대부분의 경우 `loc` 속성만이 활용된다.
- 사이트맵 파일 하나가 지나치게 많은 링크를 포함하거나 용량이 크면 크롤링이 안될 수 있다. 구글의 경우, 하나의 파일에 50MB 및 50,000개 이하의 URL만을 허용한다.
- 사이트맵이 지나치게 큰 경우 [사이트맵 색인 파일](https://developers.google.com/search/docs/crawling-indexing/sitemaps/large-sitemaps?hl=ko)로 여러 개의 사이트맵 목록을 제공하는 하나의 색인 파일을 제출하면 된다.

### 사이트맵 만들고 제출하기

사이트맵을 생성하는 방법은 여러 가지가 있다. 보편적으로 적용할 수 있는 방법은 [XML-sitemaps](https://www.xml-sitemaps.com/)를 사용하는 것이다. 여기에 사이트 URL을 넣으면 사이트맵을 자동으로 생성해준다. 또는 사용하는 기술스택(`React`, `Next.js` 등)에 따라 사이트맵을 생성해 주는 라이브러리를 활용해서 배포 시 자동으로 사이트맵이 생성되도록 할 수도 있다. 이 블로그의 경우 [next-sitemap](https://www.npmjs.com/package/next-sitemap)을 사용하여 배포시 자동으로 사이트맵을 생성한다.

이제 생성한 사이트맵을 봇이 찾을 수 있도록 해야 한다. `robots.txt`에 `Sitemap` 속성을 사용해 사이트맵의 위치를 명시하거나, [검색 엔진 콘솔](https://search.google.com/search-console/sitemaps)에서 직접 사이트맵을 제출할 수도 있다.

![구글 검색 콘솔에서 사이트맵 제출](/images/seo/submit-sitemap.png)

## 페이지 메타데이터와 구조화된 데이터

HTML의 `head` 요소에는 페이지에 대한 정보들이 포함된다. `<meta name="description" content="..."/>`과 같은 태그를 본 적이 있을 것이다. 이런 태그들은 브라우저와 봇에게 이 페이지가 어떤 내용을 담고 있는지에 대한 요약된 정보를 제공한다. 여기서 작성된 내용이 검색 결과에 바로 반영되기도 하고, 일부 SNS는 `meta` 요소에 opengraph 등의 속성을 정의하여 링크 미리보기 등에 사용하기도 한다. 그러니 반드시 신경써서 관리하는 것이 좋다. [구글 검색 센터](https://developers.google.com/search/docs/crawling-indexing/valid-page-metadata?hl=ko)와 [Opengraph](https://ogp.me/)를 참고하자

`meta` 요소 외에도 페이지에 대한 요약을 제공하기 위해 사용되는 것이 있다. **구조화된 데이터**라고 하는 것인데, 웹에 게시된 콘텐츠에 대한 정보를 담은 데이터로, 단순히 페이지에 대한 설명이나 썸네일 정도만 정의할 수 있는 `meta` 요소와 다르게, 콘텐츠 작성자에 대한 정보나 평점, 페이지 내에서 취할 수 있는 액션같은 정보도 상세하게 정의할 수 있다.

![구글의 ChatGPT 검색 결과](/images/seo/chatgpt-snippet.png)

예를 들어, 어플리케이션에 대한 정보를 검색하면 단순히 썸네일과 페이지 내용만 표시되는 것이 아니라, 앱의 가격이나 평점까지 같이 표시되기도 한다. 검색 결과에서 콘텐츠가 표시되는 형태를 **검색 스니펫**이라고 부르는데, 애플 앱스토어 역시 구조화된 데이터를 활용하여 추가 정보를 제공하고 있다.

### 구조화된 데이터를 작성하자

구조화된 데이터는 [schema.org](https://schema.org/docs/gs.html)에 자세한 설명이 나와 있다. 필요한 정보에 대한 요약만이 필요하다면 [Google 검색 센터](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data?hl=ko)나 [네이버 웹마스터 가이드](https://searchadvisor.naver.com/guide/structured-data-intro)를 참고하면 편하다. 검색엔진마다 지원하는 속성은 조금씩 다르지만, 서로 다르게 이해하는 경우는 없다. 따라서 사이트에서 스니펫이 지원되는 콘텐츠를 제공하고 있다면 그 부분만 선택해서 추가하면 된다. 이를테면 애플 앱스토어처럼 소프트웨어 앱을 제공하는 경우 `head` 요소에 다음과 같이 작성한다. 내용은 [Google 검색 센터의 구조화된 소프트웨어 앱 데이터](https://developers.google.com/search/docs/appearance/structured-data/software-app?hl=ko)를 참고해서 작성했다.

```html
<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "SoftwareApplication",
    "name": "ChatGPT",
    "description": "iOS용 ChatGPT를 소개합니다. 이제 OpenAI의 최신 기술을 손끝에서 경험해 보세요.\n\n이 공식 앱은 무료이며, ...",
    "operatingSystem": "iOS 17.0 버전 이상이 필요. iPhone, iPad 및 iPod touch와(과) 호환.",
    "applicationCategory": "생산성",
    "aggregateRating": {
      "@type": "AggregateRating",
      "ratingValue": 4.8,
      "ratingCount": 313779
    },
    "offers": {
      "@type": "Offer",
      "price": 0,
      "priceCurrency": "KRW",
      "category": "free"
    },
    "author": {
      "@type": "Person",
      "name": "OpenAI",
      "url": "https://apps.apple.com/kr/developer/openai/id1684349733"
    }
  }
</script>
```

그 외에 추가할 만한 것들은 QnA, 영화 정보, 뉴스와 같은 것들이 있다. 검색엔진들은 각각의 가이드에서 자신들이 지원하는 스니펫들을 모두 알려주고 있으니 가이드의 예제들을 참고하면 쉽게 작성할 수 있으며, 이것들을 작성하더라도 스니펫이 100% 적용되는 것은 아니니 지나치게 집착하지 않도록 하자. 느낌 상 트래픽이 많고 일관된 콘텐츠를 제공할수록 더 잘 적용해 주는 듯함..

## 마치며 - AI 검색의 시대

최근에는 SEO의 중요성에 대해 의문을 제기하는 글들이 많이 보인다. 이유인 즉슨, 사용자들은 점점 직접 검색하는 대신 LLM에게 정보를 찾아오라 시키기 때문에 SEO의 가치가 예전 만큼 높지 않다는 것이다. 꽤 오랜 시간 SEO에 시간을 투자한 나에게는 반갑지 않은 주장이지만, 나도 예전에 비해 LLM을 사용해 1차 가공된 정보에서 원문을 찾아가는 식으로 검색을 하기 때문에 어느 정도 공감하는 바이다.

그럼 SEO는 이제 필요 없는 구시대적인 요소일까? 그건 아니다. 사용자가 직접 검색을 하진 않지만 LLM도 결국 검색을 해서 사용자에게 정보를 제공한다. 즉 사이트와 사용자 사이에 검색엔진이 껴있던 상황에서 LLM이 새롭게 추가된 상황이다.

정리하면, AI 검색의 시대에는 SEO의 패러다임이 바뀌는 것이 아니라 기존 SEO에 +@가 추가된 셈이다. 여전히 1차적으로는 검색엔진에서 상단에 노출되기 위해 노력해야 하고, 그렇게 LLM이 페이지에 유입되었을 때 만족한 정보를 얻어갈 수 있어야 한다. 다만 현재로서는 검색엔진과 LLM 둘 다 봇이기 때문에 기존의 SEO 방법론에서 무엇이 달라지는지 뚜렷한 결론이 나고 있지는 않다.

그럼에도 SEO에 대한 이해가 개발자에게 주는 인사이트는 뚜렷하다. SEO의 기조는 _(콘텐츠의 질을 제외하면)_ 봇이 이해하기 쉬운 페이지를 만드는 것이다. 봇은 당연히 시맨틱 HTML이나 웹 표준에 기반하여 크롤링을 할 수 밖에 없고, 이 것이 인간의 브라우징에도 긍정적인 영향으로 이어지는 지점을 많이 경험했다. 또 개발 방향성을 정할 때 명확한 근거가 되어 주기도 했다. 앞으로도 SEO, 웹 표준, 접근성으로 이어지는 이 맥락을 놓지는 않을 듯 하다.

이전 글에서, 크롤링 봇이 이해하기 좋은 페이지를 만드는 것이 중요하다고 언급한 바 있다. 크롤링 봇이 사이트의 내용을 이해하지 못한다면 크롤링

봇에게 페이지 요약을 제공하자

SEO - 3. 사이트맵과 구조화된 데이터


![구글의 페이지 색인 과정](/images/seo/indexing-process.png)

위는 구글의 색인 과정을 나타낸 그림이다. 네이버는 비슷하게 [렌더링 후 색인을 진행함](https://searchadvisor.naver.com/guide/seo-advanced-javascript)을 간접적으로 이야기한 내용이 있고, 다음은 공식적으로 공개된 내용이 별로 없어서 생략함

우선 검색 엔진이 이미 가지고 있는 페이지에서, 또는 새로운 주소 제출로 새 페이지가 **크롤링 대기열**에 추가된다. 그리고 검색 엔진이 이 크롤링 대기열의 순서에 맞춰 페이지에 GET 요청을 보내고, 응답으로 받은 HTML 파일을 파싱한다. 이 때 부터 페이지는 검색 엔진에 노출될 수 있는 상태가 된다.

한 편, HTML만으로는 페이지의 내용이 온전하게 표시되지 않는 경우가 있다. `React`나 `Vue`같은 라이브러리로 만들어진 경우인데, 이런 사이트들을 위해 HTML 파싱이 완료된 페이지는 **렌더링 대기열**에 추가된다. 렌더링 대기열도 크롤링 대기열과 마찬가지로 순서가 다가올 때 까지 기다렸다가 페이지의 자바스크립트를 실행하여 렌더링을 진행하고, 결과물을 다시 파싱한다. 이렇게 최종적으로 페이지가 검색 엔진에 인덱싱되고, 크롤링한 결과물에 a태그(링크)가 있다면 다시 이들을 크롤링 대기열에 등록한다.

이 과정에서 중요한 포인트는 두 개의 대기열이다. 각 대기열을 통과하는데는 시간이 걸린다. 그런데 걸리는 시간은 아무도 예측할 수 없다. 구글을 기준으로 이야기하면, 구글이 내부적으로 판단하는 도메인의 우선순위와 페이지 렌더링 비용이 영향을 준다. 유명한 사이트는 1시간 전 콘텐츠도 인덱싱이 되는 반면, 어떤 사례는 **2달이 넘어서야 인덱싱이 완료**된 경우도 있다고 한다.

즉, 언제 통과될지 모르는 대기열을 두 번이나 기다릴 수 없으니, **최초 크롤링에서 모든 콘텐츠를 크롤링할 수 있도록 하는 것이 중요**하다.

> 네이버는 사이트에서 콘텐츠 갱신을 직접 알릴 수 있는 [IndexNow 프로토콜](https://searchadvisor.naver.com/guide/indexnow-about)을 지원한다.

### 렌더링 큐에 관한 더 자세한 이야기

내가 이전 회사에 있을 때의 사례이다. `Next.js`로 만들어진 사이트인데, 어떤 오류로 인해 콘텐츠 목록 페이지의 `useEffect`가 한 번 실행되어야만 페이지네이션이 보이는 문제가 있었다. 페이지네이션은 스크롤을 내려야만 보이는 위치에 있었기 때문에 여태까지는 이를 인지하지 못한 상태였다.

당시 [구글 검색 콘솔](https://search.google.com/search-console/index)로 콘텐츠의 인덱싱 과정과 유입률을 매일 추적하고 있었는데, 매일 업로드되는 콘텐츠의 일부만 빠르게 인덱싱되고, 나머지는 한 달이 지나도록 인덱싱이 완료되지 않는 현상을 발견했다. 나중에 알아보니 콘텐츠 리스트의 1페이지만 인덱싱이 일어나고 있던 것이다.

![렌더링 큐에 의한 인덱싱 지연](/images/seo/blocked-rendering.png)

이를 확인한 방법은 구글의 [URL 검사 도구](https://search.google.com/search-console?action=inspect&utm_medium=referral&utm_campaign=9012289)의 테스트된 페이지를 통해 확인하였다. 여기서 색인을 생성하던 당시의 페이지 HTML을 확인할 수 있는데, 이 HTML에서 페이지네이션 링크가 보이지 않았던 것이다. 목록에서 각 페이지 링크를 크롤링해서 재귀적으로 콘텐츠를 인덱싱해야 하는데, 모든 리스트 페이지가 렌더링 대기열을 통과해야만 했으니 당연히도 인덱싱이 지연될 수 밖에 없었다.

물론 사이트맵을 제출해도 크롤링이 이루어진다. 하지만 저 한 달의 시간 동안, 콘텐츠가 포함된 사이트맵을 아무리 제출해도 색인이 생성되지 않았다. 사이트맵 기반 크롤링 주기가 위의 과정보다 더 길었던 것일까? 아무튼 어느 쪽이 먼저 이루어질지는 아무도 모르니 모든 경우에 인덱싱이 빠르게 이루어지게끔 준비하는 것이 중요할 것이다.

## SEO를 위한 페이지 최적화

검색 엔진이 어떤 과정을 통해 사이트를 크롤링하는지 알았다. 눈여겨 볼 부분은 HTML 크롤링 및 렌더링이 즉시 이루어지는 것이 아니고 어떤 스케쥴링에 의해 순차적으로 진행된다는 점이다. 대기열에 등록되고, 크롤링이 진행되는 과정에는 크롤링 예산(컴퓨팅 리소스)과 수요가 관여하는데, 이 제한 때문에 대기열을 통과하기까지 시간이 사이트마다, 상황마다 천차만별이 될 수 있는 것이다.

이 기간을 지연시키는 요소는 매우 많겠지만 우리가 예방할 수 있는 요소가 하나 있다. **페이지 크롤링 및 렌더링에 크롤링 예산이 초과되는 경우**이다. 만약 각 페이지의 용량이 매우 크고 렌더링하는 데 많은 컴퓨팅 자원을 사용한다면 색인 속도가 상대적으로 낮아질 것이다. 이런 관점에서 SEO를 위해 렌더링 성능 최적화를 진행하는 것이다. [구글 검색 블로그 참고](https://developers.google.com/search/blog/2024/12/crawling-december-resources?hl=ko#googlebot-and-crawling-page-resources)

또 하나, 구글에서는 [검색 순위 시스템에 Core Web Vitals를 참고한다](https://developers.google.com/search/docs/appearance/page-experience?hl=ko)고 밝히고 있다. Core Web Vitals란 페이지 렌더링 성능을 측정하는 지표로 **렌더링 성능 최적화가 필요한 직접적인 이유**이기도 하다.

이 꼭지에서 다루는 내용이 하나 더 있는데, 바로 봇이 페이지를 우리의 의도대로 이해하도록 만드는 것이다. 가끔 구글 검색에서 사이트명이 이상하게 표시되거나, 페이지 설명에 콘텐츠 내용이 제대로 들어가지 않는 경우를 봤을 것이다. 이를 방지하기 위한 숙지사항을 함께 언급할 것이다.

### 렌더링 성능 최적화

![Lighthouse 검사 결과 리포트](/images/seo/lighthouse.png)

렌더링 성능 최적화는 기본적으로 [Lighthouse](https://chromewebstore.google.com/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk?hl=ko)를 기반으로 작업하는 것이 좋다. 특히 `Next.js`나 `React`같은 특정 환경에서 개선할 수 있는 권고사항들을 같이 보여주니 더욱 편하다.

단, 이 점수는 기기와 브라우저의 환경에 영향을 받는다. 로컬에 존재하지 않는 폰트를 사용해서 웹폰트를 다운받는 경우, **다른 크롬 확장(특히 React 개발자 도구)가 실행되면서 렌더링이 지연되는 경우**, 크롬 개발자 도구에서 쓰로틀링이 걸려 있는 경우 모두 영향을 주기 때문에 환경을 잘 분리해서 측정하는 것이 좋다.

추가로 `Lighthouse`에는 SEO에 문제가 되는 케이스도 찾아주고, 접근성 권고 사항도 짚어주니 함께 개선하면 좋다. 다만 여기는 반드시 지켜야 할 내용만 있는 것은 아니므로 필요한 부분만 챙기면 된다.

나같은 경우에는 특정 요구사항 때문에 사용자에게 보일 필요 없는 a태그를 두었던 적이 있는데, `innerText`가 없는 링크이다보니 경고를 받은 적이 있었다. 그치만 이런 케이스는 인덱싱 될 필요 없는 링크이니 무시해도 괜찮은 상황이다. 즉, `Lighthouse`가 경고한다 해서 무조건 SEO 감점! 이런 의미는 아니라는 것.

### 모바일 대응하기

검색 엔진마다 다르겠지만, 구글의 경우 [모바일 사이트를 기준으로 크롤링을 시도](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing?hl=ko)한다. 물론 모바일 레이아웃을 지원하지 않는 사이트도 PC 레이아웃으로 크롤링하여 정상적으로 인덱싱이 된다. 단, 모바일과 PC 레이아웃에서 보여지는 정보가 다르면 문제가 될 수 있다.

반응형 디자인이든, 모바일 페이지를 분리하든 어떻게 모바일 웹을 서브하는가는 중요하지 않지만, PC와 모바일 페이지 모두에서 같은 콘텐츠를 제공해야 한다는 것이다. 이는 보여지는 요소 외에도 meta 태그나 구조화된 데이터 등을 포함한다.

특히 모바일 웹의 경우 좁은 화면에 기능을 담기 위해 Drawer처럼 사용자의 상호작용 이후에 보여지는 UI를 자주 활용하는데, 이 요소가 접혀있을 때 아예 DOM에서 사라지는 형태라면 크롤러가 인식하지 못하므로 `display: none`으로 숨겼다가 보여주는 방식으로 구현해야 하고, `emotion`같은 CSS-in-JS 라이브러리를 사용하여 반응형 UI를 구현한다면 이로 인해 렌더링 비용이 지나치게 커지지 않도록 주의한다.

### 시맨틱 태그 사용하기

성능 최적화의 꼭지는 아니지만, 구글을 포함한 검색 엔진이 페이지를 이해할 수 있도록 하는 가장 쉬운 방법은 시맨틱 태그의 사용이다. `h1` ~ `h6`에 해당하는 헤딩 태그, `button`, `nav`, `section`, `aside` 등등 사람이 시각적으로 구분 할 수 있는 것처럼 봇 역시 HTML 태그로 페이지의 맥락을 이해할 수 있어야 한다. 이 내용을 이 위치에서 언급하는 이유는, 이 부분을 알고 성능 최적화를 진행하면 어떻게 고쳐나갈지 옳은 방향을 잡기가 쉽기 때문이다.

이 부분은 방대한 내용에 비해 얻는 이득이 많지 않으니 알아야 할 부분만 정리하고, 그 외에 시맨틱 태그의 역할에 대해 알고 싶다면 MDN의 [HTML 요소 참고서](https://developer.mozilla.org/ko/docs/Web/HTML/Element)에 잘 나와있다.

- `a`태그는 앞서 언급했듯 페이지를 재귀적으로 확장하여 탐색할 수 있게 하는 중요한 요소이다. 다른 페이지로 이동하게 하는 요소라면 반드시 `button`이나 `div` 말고 `a`태그를 사용한다.
- `h1`태그는 헤딩 태그 중에서도 페이지의 제목을 나타내는 특수한 요소이다. 한 페이지에 `h1` 태그를 여러 개 사용하지 않기를 권장하고, 사이트 이름보다 콘텐츠 제목을 우선적으로 `h1` 태그로 사용하는 것이 좋다.
- 사이트의 메뉴를 `nav` 태그에 제공하면 검색 결과에서 메뉴가 좀 더 명확히 나타나는 경향이 있다. 네이버가 이 쪽에 많이 정직하고, 구글은 사용자가 사이트에 접속했을 때 실제로 많이 클릭하는 요소의 데이터를 더 활용하는 것으로 보인다.
- 그 외의 요소들은 접근성 권고 사항, 또는 웹 표준을 참고해서 최대한 맞춰서 구현하는 것이 좋다. 이는 사용자 환경에 의존하지 않는 일관성 있는 페이지 경험을 제공하는데 큰 도움이 된다.


![구글의 페이지 색인 과정](/images/seo/indexing-process.png)

위는 구글의 색인 과정을 나타낸 그림이다. 네이버는

검색 엔진이 페이지를 읽는 방법과 최적화

devWoo

이우재 | WooJae Lee

Recent Blog PostsView All

SEO - 3. 사이트맵과 구조화된 데이터

SEO - 2. 검색 엔진의 인덱싱 과정