sitemap.xml: 검색엔진에 페이지 목록을 알려주는 사이트맵

sitemap.xml: 검색엔진에 페이지 목록을 알려주는 사이트맵

웹사이트를 처음 만들고 나면 SEO 체크리스트에 꼭 끼어 있는 항목이 하나 있는데요. 바로 사이트맵(sitemap) 제출입니다. 그런데 막상 만들려고 보면 궁금한 게 한둘이 아닙니다. 페이지가 수십 개뿐인 작은 사이트에도 필요할까요? priority는 몇으로 줘야 할까요? 날짜는 매번 빌드할 때마다 바꿔도 될까요? 🤔

이 글에서는 사이트맵이 정확히 무슨 일을 하는지, 검색엔진이 실제로 읽는 태그와 무시하는 태그는 무엇인지 살펴보겠습니다. 그리고 Bun으로 사이트맵을 직접 만들어 보고, 페이지가 많을 때 사이트맵 인덱스(sitemap index)로 나누는 방법과 검색엔진에 알리는 방법까지 정리해 보겠습니다.

사이트맵이란?

사이트맵은 검색엔진에게 “우리 사이트에는 이런 페이지들이 있어요”라고 알려주는 목록 파일입니다. 보통 사이트 루트에 sitemap.xml이라는 이름으로 둡니다.

검색엔진의 크롤러(crawler)는 원래 링크를 따라다니며 페이지를 찾습니다. 홈페이지에서 시작해 링크를 하나씩 타고 들어가는 거죠. 그래서 어디에서도 링크되지 않은 페이지나, 클릭을 여러 번 거쳐야 겨우 닿는 깊은 페이지는 놓치기 쉽습니다. 사이트맵은 이런 페이지를 직접 알려주는 지름길 역할을 합니다.

다만 사이트맵은 어디까지나 힌트입니다. 목록에 넣었다고 해서 그 페이지가 반드시 크롤링되거나 검색 결과에 나오는 건 아닙니다. 검색엔진은 사이트맵을 참고할 뿐이고, 무엇을 언제 가져갈지는 스스로 판단합니다.

비슷한 이름의 파일들과 비교하면 역할이 더 분명해집니다. robots.txt가 “어디에 들어가도 되는지”를 정하는 접근 규칙이라면, 사이트맵은 “무엇이 있는지”를 알려주는 목록입니다. AI를 위해 핵심 문서만 요약해 주는 llms.txt와도 성격이 다릅니다. 사이트맵은 중요도와 상관없이 검색 결과에 나오길 바라는 페이지를 빠짐없이 나열하는 쪽이니까요.

모든 사이트에 사이트맵이 필요할까?

꼭 그렇지는 않습니다. Google 문서에서는 다음과 같은 경우라면 사이트맵이 없어도 괜찮다고 안내합니다.

우선 검색 결과에 노출하고 싶은 페이지가 500개 정도 이하인 작은 사이트입니다. 또한 홈페이지에서 링크를 따라가기만 해도 중요한 페이지에 모두 닿는 사이트라면 크롤러가 알아서 다 찾아냅니다.

반대로 사이트맵이 특히 도움이 되는 경우도 있습니다. 페이지가 아주 많아서 모든 페이지가 서로 잘 연결되어 있다고 장담하기 어려운 사이트, 막 만들어서 외부에서 걸린 링크가 거의 없는 새 사이트, 그리고 이미지나 동영상, 뉴스 콘텐츠가 많은 사이트가 그렇습니다.

그렇다고 작은 사이트에서 사이트맵을 만드는 게 손해일 일은 없습니다. 요즘 프레임워크는 대부분 설정 몇 줄이면 사이트맵을 자동으로 만들어 주고, Search Console에서 페이지별 색인(indexing) 상태를 사이트맵 단위로 보여 준다는 장점도 있습니다. 만드는 비용이 거의 없으니 일단 두는 편이 낫습니다. 다만 잘못 만든 사이트맵은 없느니만 못할 수 있는데, 그 이야기는 뒤에서 하겠습니다.

사이트맵의 기본 형식

사이트맵은 sitemaps.org에서 정의한 XML 형식을 따릅니다. 2006년 Google, Yahoo, Microsoft가 함께 내놓은 프로토콜로, 지금도 0.9 버전이 그대로 쓰이고 있습니다. 가장 단순한 사이트맵은 이렇게 생겼습니다.

sitemap.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>2026-10-10</lastmod>
  </url>
  <url>
    <loc>https://example.com/about/</loc>
    <lastmod>2026-03-02</lastmod>
  </url>
</urlset>

루트 요소인 <urlset>에는 프로토콜의 네임스페이스(namespace)를 반드시 선언해야 하고, 그 안에 페이지마다 <url> 요소를 하나씩 둡니다. 각 <url> 안에서 필수인 건 페이지 주소를 담는 <loc> 하나뿐입니다.

나머지는 모두 선택 사항인데요. 프로토콜에 정의된 선택 태그는 세 가지입니다. 우선 <lastmod>는 페이지가 마지막으로 바뀐 날짜로, 2026-10-10처럼 날짜만 쓰거나 2026-10-10T09:30:00+09:00처럼 시각까지 쓸 수 있습니다(W3C Datetime 형식). 그리고 <changefreq>는 페이지가 얼마나 자주 바뀌는지를 always, hourly, daily, weekly, monthly, yearly, never 중 하나로 나타냅니다. 마지막으로 <priority>는 사이트 안에서 이 페이지의 상대적인 중요도로, 0.0에서 1.0 사이이며 기본값은 0.5입니다.

XML 대신 RSS나 Atom 피드, 혹은 한 줄에 URL 하나씩 적은 텍스트 파일도 사이트맵으로 제출할 수 있습니다. 하지만 이미지나 동영상 같은 확장 정보까지 담는 건 XML 형식뿐이라 보통은 XML을 씁니다.

lastmod만 제대로 쓰면 됩니다

세 가지 선택 태그를 다 채워야 할 것 같지만, 실제로 의미가 있는 건 <lastmod> 하나입니다.

Google은 사이트맵 작성 가이드에서 <priority>와 <changefreq> 값을 무시한다고 분명히 밝히고 있습니다. Bing도 2025년 웹마스터 블로그 글에서 두 태그가 크롤링이나 순위에 영향을 주지 않는다고 했습니다. 모든 페이지에 priority를 1.0으로 줘서 검색 순위를 끌어올리려는 시도가 흔했으니, 검색엔진 입장에서는 믿을 수 없는 신호였던 셈이죠. 😅

반면 <lastmod>는 다릅니다. Google은 이미 알고 있는 URL을 언제 다시 크롤링할지 정할 때 이 값을 참고합니다. 단, 조건이 붙습니다. 값이 일관되게 정확하다는 게 확인될 때만 씁니다.

여기서 가장 흔한 실수가 나옵니다. 빌드할 때마다 모든 페이지의 lastmod를 현재 시각으로 찍는 거죠. 이렇게 하면 내용이 하나도 안 바뀐 페이지까지 매일 “방금 수정됨”으로 표시됩니다. 검색엔진은 곧 이 사이트의 lastmod가 실제와 맞지 않다는 걸 알아차리고, 그 뒤로는 진짜로 수정한 페이지의 날짜까지 무시하게 됩니다. Bing이 2023년에 발표한 조사에 따르면 사이트맵의 18%가 lastmod를 잘못 쓰고 있었는데, 대부분이 바로 이렇게 사이트맵 생성 시각을 넣은 경우였습니다.

그럼 어떤 변경을 수정으로 봐야 할까요? Google은 본문 내용이나 구조화된 데이터, 링크처럼 페이지의 의미 있는 부분이 바뀌었을 때라고 설명합니다. 푸터의 저작권 연도가 바뀌었다거나 사이드바 광고가 달라진 정도는 수정으로 치지 않습니다. 블로그라면 글의 본문을 고친 날짜를 쓰면 됩니다. 수정일을 따로 관리하지 않는다면 차라리 최초 발행일을 넣거나 lastmod를 아예 빼는 편이 엉터리 날짜를 넣는 것보다 낫습니다.

지켜야 할 제약

사이트맵 파일 하나에는 URL을 최대 5만 개까지, 크기는 압축하기 전 기준으로 50MB까지 담을 수 있습니다. gzip으로 압축한 sitemap.xml.gz를 제출해도 되지만, 이때도 압축을 푼 크기가 50MB를 넘으면 안 됩니다.

<loc>에는 반드시 프로토콜과 호스트를 포함한 절대 URL을 씁니다. /about/ 같은 상대 경로는 유효하지 않습니다. 그리고 Google은 사이트맵에 적힌 URL을 적힌 그대로 크롤링하므로, 페이지의 표준 URL(canonical URL)과 정확히 같은 형태로 적어야 합니다. http와 https, www 유무, 그리고 URL 끝 슬래시까지 모두 맞춰야 하는데요. 이 중 끝 슬래시 문제는 Trailing slash 글에서 자세히 다뤘습니다.

사이트맵이 다루는 범위에도 제한이 있습니다. 프로토콜상 사이트맵은 자기가 놓인 디렉토리와 그 하위 경로의 URL만 담습니다. /blog/sitemap.xml에 둔 사이트맵은 /shop/ 아래 페이지를 나열할 수 없다는 뜻이죠. 사이트맵을 사이트 루트에 두라고 권하는 이유입니다. (Search Console로 제출하면 이 제한이 풀리고, 소유권을 확인한 다른 사이트의 URL까지 한 사이트맵에 담을 수도 있습니다.)

마지막으로 파일은 UTF-8로 인코딩해야 하고, URL에 XML 특수 문자가 들어가면 이스케이프(escape)해야 합니다. 쿼리 문자열의 &는 &amp;로, <와 >는 &lt;와 &gt;로, 따옴표는 &quot;와 &apos;로 바꿉니다. 한글처럼 ASCII가 아닌 문자가 들어간 경로는 퍼센트 인코딩(percent-encoding)을 해서 넣는 게 안전합니다.

Bun으로 사이트맵 만들기

규칙을 알았으니 직접 만들어 보겠습니다. 페이지 목록을 받아 사이트맵을 만드는 함수를 작성하고, Bun.serve로 /sitemap.xml과 /robots.txt를 서빙해 보겠습니다.

server.ts
const SITE = "https://example.com";

const pages = [
  { path: "/", updatedAt: "2026-10-10" },
  { path: "/about/", updatedAt: "2026-03-02" },
  { path: "/posts/hello-bun/", updatedAt: "2026-09-21" },
  { path: "/tag/자바스크립트/", updatedAt: "2026-08-15" },
  { path: "/shop/?item=42&color=red", updatedAt: "2026-07-30" },
];

function escapeXml(value: string) {
  return value
    .replace(/&/g, "&amp;")
    .replace(/</g, "&lt;")
    .replace(/>/g, "&gt;")
    .replace(/"/g, "&quot;")
    .replace(/'/g, "&apos;");
}

function buildSitemap() {
  const urls = pages
    .map(
      (page) => `  <url>
    <loc>${escapeXml(new URL(page.path, SITE).href)}</loc>
    <lastmod>${page.updatedAt}</lastmod>
  </url>`,
    )
    .join("\n");

  return `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${urls}
</urlset>
`;
}

const server = Bun.serve({
  port: 3000,
  routes: {
    "/sitemap.xml": () =>
      new Response(buildSitemap(), {
        headers: { "Content-Type": "application/xml; charset=utf-8" },
      }),
    "/robots.txt": () =>
      new Response(`User-agent: *\nAllow: /\n\nSitemap: ${SITE}/sitemap.xml\n`),
  },
});

console.log(`Listening on ${server.url}`);

여기서 눈여겨볼 부분이 두 군데 있는데요. 먼저 new URL(page.path, SITE)로 경로를 절대 URL로 바꾸고 있습니다. 이렇게 하면 문자열을 이어 붙일 때 슬래시가 빠지거나 겹치는 실수를 막을 수 있고, 한글 경로의 퍼센트 인코딩도 URL API가 알아서 처리합니다. 그다음 escapeXml()에서 &를 가장 먼저 바꾸는 순서가 중요합니다. <를 &lt;로 바꾼 뒤에 &를 바꾸면 방금 만든 &lt;의 &까지 다시 &amp;lt;로 바뀌어 버리니까요.

서버를 띄우고 요청을 보내 보겠습니다.

bun run server.ts
curl -i http://localhost:3000/sitemap.xml
결과
HTTP/1.1 200 OK
Content-Type: application/xml; charset=utf-8
Date: Fri, 16 Oct 2026 23:41:04 GMT
Content-Length: 653

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-10-10</lastmod>
  </url>
  <url>
    <loc>https://example.com/about/</loc>
    <lastmod>2026-03-02</lastmod>
  </url>
  <url>
    <loc>https://example.com/posts/hello-bun/</loc>
    <lastmod>2026-09-21</lastmod>
  </url>
  <url>
    <loc>https://example.com/tag/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8/</loc>
    <lastmod>2026-08-15</lastmod>
  </url>
  <url>
    <loc>https://example.com/shop/?item=42&amp;color=red</loc>
    <lastmod>2026-07-30</lastmod>
  </url>
</urlset>

한글 경로는 퍼센트 인코딩되었고, 쿼리 문자열의 &는 &amp;로 바뀌었습니다. lastmod에는 빌드 시각이 아니라 각 페이지가 실제로 수정된 날짜가 들어갔고요. 실제 서비스라면 pages 배열 자리에 데이터베이스나 CMS에서 가져온 목록과 수정일이 들어가면 됩니다.

사이트맵 인덱스로 나누기

페이지가 5만 개를 넘으면 사이트맵을 여러 파일로 나눠야 합니다. 그리고 나눈 파일들을 묶는 사이트맵 인덱스 파일을 하나 만들어 그것만 제출하면 됩니다. 사이트맵 인덱스는 <urlset> 대신 <sitemapindex>를 루트로 쓰고, 그 안에 사이트맵 파일의 위치를 나열합니다.

상품 페이지가 12만 개 있는 쇼핑몰을 가정하고, 5만 개씩 끊어 정적 파일로 써 보겠습니다.

build-sitemap.ts
const SITE = "https://example.com";
const MAX_URLS = 50_000;

// 12만 개의 상품 페이지가 있다고 가정
const paths = Array.from({ length: 120_000 }, (_, i) => `/products/${i + 1}/`);

const chunks: string[][] = [];
for (let i = 0; i < paths.length; i += MAX_URLS) {
  chunks.push(paths.slice(i, i + MAX_URLS));
}

for (const [i, chunk] of chunks.entries()) {
  const urls = chunk
    .map((path) => `  <url><loc>${SITE}${path}</loc></url>`)
    .join("\n");
  await Bun.write(
    `dist/sitemap-${i + 1}.xml`,
    `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${urls}
</urlset>
`,
  );
}

const entries = chunks
  .map(
    (_, i) => `  <sitemap>
    <loc>${SITE}/sitemap-${i + 1}.xml</loc>
  </sitemap>`,
  )
  .join("\n");

await Bun.write(
  "dist/sitemap-index.xml",
  `<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${entries}
</sitemapindex>
`,
);

실행하고 결과를 확인해 보겠습니다.

bun run build-sitemap.ts
ls -l dist
cat dist/sitemap-index.xml
결과
total 14096
-rw-r--r--@ 1 dale  wheel  2989004 Oct 16 19:41 sitemap-1.xml
-rw-r--r--@ 1 dale  wheel  3000111 Oct 16 19:41 sitemap-2.xml
-rw-r--r--@ 1 dale  wheel  1220110 Oct 16 19:41 sitemap-3.xml
-rw-r--r--@ 1 dale  wheel      344 Oct 16 19:41 sitemap-index.xml
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-1.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-2.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-3.xml</loc>
  </sitemap>
</sitemapindex>

12만 개가 5만, 5만, 2만 개로 나뉘어 세 파일이 되었고, 인덱스 파일이 이 셋을 가리킵니다. 5만 개를 담은 파일도 3MB 정도라 50MB 제한은 URL이 아주 길거나 이미지 확장 정보를 많이 넣을 때가 아니면 걱정할 일이 거의 없습니다. 보통은 개수 제한에 먼저 걸립니다.

꼭 5만 개를 채울 때까지 기다릴 필요는 없습니다. 오히려 상품, 카테고리, 블로그 글처럼 페이지 종류별로 사이트맵을 나눠 두면 Search Console에서 종류별 색인 비율이 따로 보여서 문제를 찾기가 쉬워집니다. 인덱스 파일 하나에는 사이트맵을 최대 5만 개까지 넣을 수 있고, 인덱스에 담는 사이트맵은 같은 사이트에 있어야 합니다.

프레임워크에서 사이트맵 만들기

직접 만드는 게 원리를 이해하기엔 좋지만, 실무에서는 프레임워크가 제공하는 방법을 쓰는 경우가 많습니다.

Astro라면 공식 통합 패키지인 @astrojs/sitemap을 설치하고 설정에 추가하기만 하면 됩니다. 빌드할 때 모든 정적 페이지를 모아 sitemap-index.xml과 sitemap-0.xml을 만들어 줍니다.

bunx astro add sitemap
astro.config.mjs
import { defineConfig } from "astro/config";
import sitemap from "@astrojs/sitemap";

export default defineConfig({
  site: "https://example.com",
  integrations: [
    sitemap({
      filter: (page) => !page.includes("/drafts/"),
    }),
  ],
});

절대 URL을 만들어야 하니 site 옵션은 반드시 지정해야 합니다. 그리고 filter로 사이트맵에서 뺄 페이지를 고를 수 있습니다.

Next.js의 App Router에서는 app/sitemap.ts 파일에서 URL 배열을 반환하는 함수를 내보내면 /sitemap.xml이 생깁니다. 페이지가 많을 때는 generateSitemaps()로 여러 파일로 나눌 수도 있고요.

app/sitemap.ts
import type { MetadataRoute } from "next";

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const posts = await getPosts();

  return posts.map((post) => ({
    url: `https://example.com/posts/${post.slug}/`,
    lastModified: post.updatedAt,
  }));
}

여기서 한 가지 조심할 점이 있습니다. 공식 문서를 비롯해 많은 예제가 lastModified: new Date()를 쓰는데, 그대로 복사하면 앞에서 말한 “모든 페이지가 방금 수정됨” 문제가 그대로 생깁니다. 위 코드처럼 각 페이지의 실제 수정일을 넣도록 바꿔 주세요. 프레임워크의 자동 생성 기능도 마찬가지입니다. 플러그인이 lastmod를 어떤 값으로 채우는지 한 번은 확인해 보는 게 좋습니다.

검색엔진에 사이트맵 알리기

사이트맵을 만들었다면 검색엔진에 그 위치를 알려야 합니다. 방법은 크게 두 가지입니다.

첫 번째는 robots.txt에 Sitemap: 줄을 추가하는 겁니다. 크롤러는 사이트에 오면 가장 먼저 robots.txt를 읽으니, 여기에 적어 두면 Google, Bing, 네이버를 포함한 대부분의 검색엔진이 따로 제출하지 않아도 사이트맵을 찾아갑니다.

robots.txt
User-agent: *
Allow: /

Sitemap: https://example.com/sitemap-index.xml

Sitemap: 줄은 User-agent 그룹과 상관없이 어디에 써도 되고, 여러 줄을 써서 사이트맵을 여러 개 알릴 수도 있습니다. 주소는 반드시 절대 URL로 씁니다.

두 번째는 각 검색엔진의 웹마스터 도구에서 직접 제출하는 겁니다. Google은 Search Console의 Sitemaps 보고서, Bing은 Bing Webmaster Tools, 네이버는 서치어드바이저에서 사이트맵 URL을 등록합니다. 이렇게 제출하면 사이트맵을 마지막으로 읽은 시각, 발견한 URL 수, 파싱 오류 같은 정보를 볼 수 있어서 처음 한 번은 직접 제출해 두는 걸 추천합니다.

예전에는 https://www.google.com/ping?sitemap=... 주소로 요청을 보내 사이트맵이 바뀌었다고 알리는 방법도 있었습니다. 하지만 Google은 2023년 6월에 이 핑(ping) 엔드포인트를 더 이상 지원하지 않는다고 발표했고, 지금은 요청을 보내도 404만 돌아옵니다. 오래된 플러그인이나 배포 스크립트에 이 코드가 남아 있다면 지워도 됩니다. 인증 없이 누구나 보낼 수 있다 보니 들어오는 핑 대부분이 스팸이었다고 하네요. 대신 Google은 정확한 lastmod를 보고 다시 크롤링할 시점을 정하겠다고 했습니다.

변경 사항을 바로 알리고 싶다면 IndexNow라는 프로토콜도 있습니다. 페이지가 추가되거나 바뀔 때 URL을 API로 보내는 방식인데, Bing과 네이버, Yandex 등이 지원하지만 Google은 지원하지 않습니다. 사이트맵을 대체하는 게 아니라 사이트맵과 함께 쓰는 보조 수단으로 생각하면 됩니다.

사이트맵에 넣지 말아야 할 페이지

사이트맵에는 검색 결과에 나오길 원하는 페이지만 넣어야 합니다. 당연한 말 같지만, 사이트맵을 자동으로 만들다 보면 엉뚱한 페이지가 섞여 들어가기 쉽습니다.

우선 noindex 메타 태그가 붙은 페이지입니다. 사이트맵으로는 “검색에 넣어 주세요”라고 하고 페이지에서는 “검색에서 빼 주세요”라고 하는 셈이라 서로 모순되는 신호를 보내게 됩니다. noindex를 비롯한 메타 태그는 메타 태그로 검색엔진 최적화하기에서 다뤘습니다.

또한 다른 주소로 리디렉션되는 URL이나 404 상태 코드를 반환하는 URL도 빼야 합니다. 글의 주소를 바꿨다면 사이트맵에는 옛 주소가 아니라 새 주소가 들어가야 하죠. 옛 주소를 새 주소로 보내는 리디렉션 규칙은 _redirects 글에서 다뤘습니다. canonical 태그로 다른 페이지를 표준 URL로 가리키는 중복 페이지도 마찬가지입니다. 사이트맵에 적힌 URL과 canonical, 리디렉션, 내부 링크가 모두 같은 주소를 가리켜야 검색엔진이 헷갈리지 않습니다.

마지막으로 robots.txt에서 크롤링을 막아 둔 경로입니다. 사이트맵에 있는 URL을 크롤러가 정작 가져갈 수 없으니 Search Console에 경고가 뜹니다. 검색 결과 페이지, 로그인 페이지, 장바구니처럼 검색에 노출할 이유가 없는 페이지도 여기에 해당합니다.

이런 페이지가 많이 섞이면 사이트맵 전체의 신뢰도가 떨어집니다. Search Console의 페이지 색인 보고서에서 사이트맵으로 필터링해 “제출됨, 색인 생성되지 않음” 같은 항목이 쌓여 있는지 가끔 확인해 보세요.

마치며

사이트맵은 검색엔진에게 우리 사이트의 페이지 목록을 건네는 단순한 XML 파일입니다. 이 글에서 살펴본 내용을 정리하면 다음과 같습니다.

  • <loc>에는 표준 URL과 똑같은 형태의 절대 URL을 씁니다.
  • <priority>와 <changefreq>는 Google과 Bing 모두 무시하니 신경 쓰지 않아도 됩니다.
  • <lastmod>에는 빌드 시각이 아니라 페이지의 실제 수정일을 넣습니다.
  • 파일 하나에 5만 개, 50MB를 넘으면 사이트맵 인덱스로 나눕니다.
  • robots.txt의 Sitemap: 줄과 Search Console 제출로 위치를 알리고, Google 핑은 더 이상 쓰지 않습니다.
  • noindex, 리디렉션, 404, 중복 페이지는 사이트맵에서 뺍니다.

한마디로 사이트맵이 거짓말을 하지 않게 만들면 됩니다. 정확한 사이트맵은 검색엔진이 우리 사이트를 더 믿게 만들고, 그만큼 새 글이나 수정한 글이 빨리 반영됩니다. 지금 운영 중인 사이트의 sitemap.xml을 한번 열어서 lastmod가 모두 오늘 날짜로 찍혀 있지는 않은지 확인해 보세요. 😉

더 자세한 내용은 Google 검색 센터의 사이트맵 문서를 참고하세요.

This work is licensed under CC BY 4.0CCBY

개발자를 위한 뉴스레터

달레가 정리한 AI 개발 트렌드와 직접 만든 콘텐츠를 전해드립니다.

관련 포스트

검색엔진과 AI 크롤러를 안내하는 robots.txt 사용법

웹사이트를 개발하고 배포하다 보면 한 번쯤 robots.txt라는 파일에 대해서 듣게 됩니다. 저도 처음에는 검색 엔진이 크롤링할 때 필요한 정보를 제공해주는 수단으로 이해했었죠. 하지만 개인 블로그를 운영하면서 느낀 건, 이 작고 단순한 파일이 생각보다 많은 역할을 한다는 겁니다. 검색 결과에 어떤 페이지가 보이고 안 보이는지, 트래픽 낭비를 줄일 수 있는지 등, 의외로 중요한 결정들이 이 한 장짜리 텍스트 파일에 달려 있습니다. 특히 요즘처럼 데이터 학습을 위해서 AI 크롤러가 우후죽순 등장하는 시대에는, 단순한 SEO 도구를

Trailing slash: URL 끝 슬래시, 붙일까 뗄까?

웹사이트를 만들다 보면 한 번쯤 이런 고민을 하게 되는데요. /about이라고 쓸까, /about/이라고 쓸까? 끝에 슬래시 하나 붙는 게 뭐 그리 대수일까 싶지만, 막상 운영해 보면 이 작은 문자가 검색 순위, 깨진 이미지, 끝나지 않는 리디렉션(redirect) 같은 문제로 돌아오곤 합니다. 😅 URL 끝에 붙는 이 슬래시를 트레일링 슬래시(trailing slash)라고 부릅니다. 결론부터 말씀드리면 이렇게 하면 됩니다. 빌드 결과물 모양에 맞춰 한쪽을 고릅니다. about/index.html처럼 페이지마다 디렉터리를 만든다

메타 태그로 검색엔진 최적화하기 (SEO)

웹사이트를 개발하다 보면 아무래도 사람들에게 보여질 부분에만 치중하기 쉬워집니다. 그런데 알고보면 사람뿐만 아니라 기계가 웹사이트를 읽어야하는 경우가 의외로 많은데요. 여기서 기계라함은 유저가 사용하는 브라우저가 될 수도 있고 웹사이트의 데이터를 수시로 수집해가는 검색엔진이 될 수도 있겠습니다. 또한 어떤 웹페이지의 링크를 공유하면 링크를 열기 전에 해당 콘텐츠를 미리보여주는 SNS나 메신저가 될 수도 있겠네요. 이번 포스팅에서는 이러한 기계들이 웹페이지를 효과적으로 이해할 수 있도록 도와주는 메타 태그에 대해서 알아보겠습니다. 메

llms.txt: LLM을 위한 웹사이트 안내서

요즘 ChatGPT나 Claude 같은 AI 서비스를 사용해서 웹사이트에 대해 질문해본 적 있으신가요? 예를 들어, "FastHTML 사용법 알려줘"라고 물어보면 AI가 답변을 해주는데요. 그런데 가끔 AI가 엉뚱한 답변을 하거나 오래된 정보를 알려줄 때가 있습니다. LLM 초창기에는 주로 학습된 데이터가 오래되서 그랬지만 최근에는 LLM이 스스로 웹사이트 검색도 하는데... 왜 그럴까요? 이유는 간단합니다. 대부분의 웹사이트는 사람을 위해 설계되어 있기 때문이죠. 복잡한 HTML 구조, 내비게이션, 광고, 자바스크립트 등이 섞여

URL 인코딩이 무엇이고 왜 필요할까?

웹 개발을 하다 보면 한글이나 공백이 들어간 URL이 깨지거나, 쿼리 스트링에 특수 문자가 포함되어 의도치 않은 동작을 하는 경우를 종종 마주치게 되는데요. 이런 문제의 원인은 대부분 URL 인코딩과 관련이 있습니다. 이번 포스팅에서는 URL 인코딩이 무엇이고 왜 필요한지부터 짚어보겠습니다. 어떤 문자는 그대로 써도 되고 어떤 문자는 변환해야 하는지, 그리고 자바스크립트의 encodeURI와 encodeURIComponent 함수가 어떻게 다른지도 함께 살펴보겠습니다. URL 인코딩이 왜 필요할까요? URL은 인터넷에서 자원의 위치

RSS: 새 글을 구독자에게 전해 주는 웹 피드

"RSS는 이제 아무도 안 쓰지 않나요?"라는 이야기를 종종 듣는데요. 2013년 Google Reader가 문을 닫으면서 RSS가 죽었다는 말이 한동안 유행했지만, 사실 RSS는 우리가 모르는 사이에 곳곳에서 일하고 있습니다. 팟캐스트 앱이 새 에피소드를 가져오는 것도, 뉴스레터 서비스가 블로그 새 글을 메일로 보내 주는 것도, 검색엔진이 최근 글을 빨리 찾아가는 것도 대부분 RSS 덕분입니다. 🤔 이 글에서는 웹 피드(web feed)가 무엇인지, RSS 2.0과 Atom, JSON Feed는 어떻게 다른지 살펴보겠습니다. 그