Main area
Agency
technisches-seo

Building XML Sitemaps the Right Way

Redaktion ·

Building XML Sitemaps the Right Way

An XML sitemap is a list of the URLs you consider worth indexing — a discovery aid for search engines, nothing more. It makes it easier for Google to find your pages, but it is not a ranking factor and not a guarantee of indexing. Google says it plainly itself: submitting a sitemap is merely a hint and doesn’t guarantee that the URLs will be crawled or indexed (Google Search Central, as of 2026).

Still, a clean sitemap is worth it — especially for large sites, new sites with few backlinks, and sites with lots of media content. The trick is to keep it honest. A sitemap full of junk URLs does more harm than good.

The structure: loc and lastmod

Each entry in a sitemap consists at its core of two pieces of information:

  • <loc> — the full, absolute URL. Required. Google crawls it exactly as written. Watch trailing slashes and the correct protocol (https).
  • <lastmod> — when the page was last changed in content. Optional, but important.

The decisive point with lastmod: it must be honest. Google only uses the value if it’s “consistently and verifiably” accurate — for example by comparing it to the actual last modification Google detected on the page (Google, as of 2026). If you blanket-write today’s date into every sitemap, you signal “everything changed” — and Google learns to distrust this site’s lastmod. Then the value is ignored entirely. lastmod belongs to genuine content changes, not cosmetic ones like an updated copyright year.

changefreq and priority — ignored

Two tags from the old sitemap protocol are dead letters today: <changefreq> (how often a page changes) and <priority> (how important it is relative to others). Google ignores both values completely. You can leave them out — they only cost upkeep and gain nothing. If you use tools that fill them automatically, don’t worry about it, but don’t attach any meaning to them either.

What belongs in — and what doesn’t

This is the most important part. A sitemap contains only URLs that should actually land in the index:

Only these belong in:

  • URLs with status 200 (reachable, no error),
  • the canonical variant (see canonical tag) — never the filter or parameter version,
  • indexable pages (no noindex).

These don’t belong in:

  • noindex pages — a contradictory signal: “index this” plus “don’t index this”,
  • redirects (301/302) — they burn crawl budget and count as a quality problem,
  • URLs blocked via robots.txt,
  • non-canonical duplicates, parameter URLs, endless pagination loops,
  • 404s and soft 404s.

Rule of thumb: if you don’t want a URL in the Google index, it has no business in the sitemap. Every wrong URL dilutes the trust Google places in your sitemap — and on large sites burns crawl budget.

Limits and the sitemap index

A single sitemap file may contain at most 50,000 URLs or 50 MB uncompressed — whichever comes first (Google / sitemaps.org). If you have more URLs, you split them across multiple sitemaps and bundle these in a sitemap index file: a sitemap that points to other sitemaps. That index file is what you then submit. Compression (.xml.gz) is allowed and sensible — but the 50 MB limit refers to the uncompressed size.

hreflang in the sitemap

Multilingual sites can declare their language variants directly in the sitemap instead of putting every hreflang hint into the HTML. Per URL you list all language variants via xhtml:link rel="alternate" hreflang="…" — including the self-reference. With many languages this is often cleaner and more maintainable than the HTML route, because all alternates sit in one place.

Submitting and diagnosing

Three ways to make a sitemap known:

  1. Search Console — Sitemaps report. The most important way. Here you see whether Google could read the sitemap, how many URLs were discovered and what errors occurred.
  2. robots.txt. A line Sitemap: https://example.com/sitemap.xml makes the sitemap discoverable for all crawlers — not just Google.
  3. Search Console API. For automated pipelines.

The previously common “ping” endpoint has been retired by Google — Search Console and robots.txt are the ways today. For ongoing diagnosis, the Sitemaps report in Search Console is the place to go: it shows “discovered URLs” against actually indexed ones and reveals where pages get lost between discovery and indexing. A large gap there usually means wrong URLs in the sitemap or a quality/canonical problem. The short definition is in the glossary under sitemap.

FAQ

Is a sitemap a ranking factor? No. A sitemap only helps Google find the URLs — it does not influence how well a page ranks, and doesn’t even guarantee indexing. It’s a discovery aid, especially valuable for large, new or weakly linked sites.

Why shouldn’t lastmod always be today’s date? Because Google only uses the value if it’s verifiably accurate. If a sitemap permanently writes “today” although nothing changed, Google learns to distrust this site’s lastmod — and ignores the value entirely. lastmod belongs to genuine content changes.

Do I need changefreq and priority? No. Google ignores both tags completely. You can leave them out; if your tool sets them automatically, it does no harm but also no good.

What happens with more than 50,000 URLs? Then you split across multiple sitemap files (each max. 50,000 URLs or 50 MB uncompressed) and bundle them in a sitemap index file that you submit to Google.

Should noindex pages or redirects go into the sitemap? No. Only canonical, indexable 200 URLs belong in the sitemap. noindex pages, redirects, blocked URLs and 404s dilute the trust in your sitemap and burn crawl budget.

Themenuebersicht

Technisches SEOCrawling & Indexierung