Building an XML Sitemap Google Uses

An XML sitemap is one of the few places where you get to speak to search engines directly: here are my URLs, and here's when they last changed. It's also one of the most misunderstood files on the average site — stuffed with redirects and noindexed pages, decorated with priority values nobody reads, and generated by a plugin whose defaults nobody ever checked.

The stakes are worth stating honestly. A sitemap will not get a bad page ranked, and a small site with clean internal links barely needs one. But a trustworthy sitemap does two valuable things: it helps search engines discover new and orphaned URLs faster, and — via an accurate lastmod — tells them which of your existing pages changed, so recrawls go where they're useful. A sloppy sitemap does the opposite: it teaches Google that your metadata lies, after which your sitemap becomes decoration. This post covers what actually belongs in one, which fields matter (fewer than you think), and how to set it up properly on WordPress.

What a Sitemap Is — and Isn't

An XML sitemap is a machine-readable list of URLs, optionally annotated with metadata, discoverable by search engines via Search Console submission or a Sitemap: line in robots.txt. Clear expectations up front:

• It's a discovery aid, not a command. Listing a URL doesn't force crawling, and definitely doesn't force indexing. Google treats it as a hint about what exists.
• It's not a substitute for internal linking. A page reachable only through the sitemap (an "orphan") may get crawled, but it inherits no link signals and usually ranks like the afterthought it is.
• It is a statement of canonicals. Google explicitly uses sitemap inclusion as a canonicalization signal. This is why junk in the sitemap has real cost: you're voting for the wrong URLs.

The Golden Rule: Only Canonical, Indexable, 200-Status URLs

If you remember one thing, make it this. Every URL in your sitemap should satisfy all four:

1. Returns 200 OK. Not a 301, not a 404, not a soft error. Every redirect in a sitemap is you telling Google "index this" and the server replying "no, over there" — a contradiction that erodes trust in the whole file.
2. Is the canonical version. Not a parameter variant, not the http version, not the trailing-slash twin. If the page's canonical tag points elsewhere, the sitemap should list the elsewhere.
3. Is indexable. No noindexed pages, nothing blocked by robots.txt. "Indexed, though blocked" and "Excluded by noindex" rows in your sitemap report are self-inflicted contradictions.
4. Is worth indexing. This is the judgment call plugins can't make for you. Thin tag archives, paginated comment pages, attachment pages — technically indexable, strategically worthless. Leave them out.

A useful mental model: your sitemap is the guest list, not the phone book. It should describe the site you want Google to see — every page on it something you'd be happy to have ranking.

The Fields: One Matters, Two Are Ignored

Each sitemap entry can carry three optional fields, and the industry spent a decade optimizing the wrong ones:

lastmod is the sitemap's real payload. Google has confirmed it uses lastmod to prioritize recrawling — provided the values prove trustworthy over time. That trust is fragile and site-wide: sitemap generators that stamp every URL with the current date on every regeneration, or update lastmod when a footer widget changes, poison the signal for the entire file. Truthful means: the date the page's meaningful content last changed. Fixing a typo, yes arguably; a rotated "related posts" block, no. Good plugins tie lastmod to the post's modified date, which is the right default.

changefreq and priority were reasonable ideas that turned into universal lies — every site declaring everything "daily" and "1.0" — so Google publicly stopped reading them years ago. If your sitemap still includes them, nothing breaks; they're just dead weight.

Structure and Limits

The format constraints, so your generator's behavior makes sense:

• 50,000 URLs or 50MB (uncompressed) per sitemap file, whichever comes first. Beyond that, you split into multiple sitemaps referenced by a sitemap index file — a sitemap of sitemaps.
• Even below the limits, splitting by content type is good practice: post-sitemap.xml, page-sitemap.xml, product-sitemap.xml. Not because Google cares, but because Search Console reports indexing per sitemap — segmentation turns "3,100 of 4,000 URLs indexed" from a mystery into a diagnosis ("ah, it's the product variants").
• URLs must be absolute and consistent with your canonical host (https, correct www choice). Cross-host entries get ignored unless ownership is established.
• Compression (.xml.gz) is fine and supported; the 50MB limit applies to the uncompressed size.

WordPress: Getting It Right in Practice

WordPress core ships a basic sitemap at /wp-sitemap.xml, and every major SEO plugin (Yoast, Rank Math, SEOPress) replaces it with a better one — typically at /sitemap_index.xml or /sitemap.xml. Use the plugin's version; it respects your noindex settings, which core's does not fully. Then spend ten minutes on the settings almost nobody opens:

1. Exclude attachment/media pages. WordPress historically created a page per uploaded image — pure thin content. Modern SEO plugins redirect these to the file by default; verify yours does, and that they're out of the sitemap.
2. Decide taxonomy inclusion deliberately. Categories with curated descriptions and real traffic: include. The 4,000 tags used once each: exclude from the sitemap and noindex them — the sitemap exclusion and the indexability decision should always agree.
3. Exclude formats and stubs: author archives on single-author sites, date archives, search results, and any custom post type that exists for internal plumbing (sliders, testimonials embedded elsewhere) rather than as standalone pages.
4. Check what your e-commerce or events plugin contributes. WooCommerce products belong in; individual product variations, cart/checkout/account pages do not. Past events: decide whether expired event pages should live on (often no — and if they 410, they must leave the sitemap).
5. Verify the robots.txt reference. One line — Sitemap: https://yourdomain.com/sitemap_index.xml — makes the sitemap discoverable to every crawler, not just the ones you submitted to.

Submitting and Reading the Reports

Submit the sitemap index once in Search Console → Sitemaps (and Bing Webmaster Tools while you're at it). After that, the value is in the Pages report filtered by sitemap. What the common statuses actually mean:

• "Crawled – currently not indexed" on sitemap URLs: Google fetched the page and declined to index it. This is a quality verdict, not a sitemap bug. The fix is better content or consolidation, not resubmission.
• "Discovered – currently not indexed": Google knows the URL exists but hasn't bothered fetching. On small sites, again a demand/quality signal; on very large sites, possibly crawl scheduling.
• "Duplicate without user-selected canonical" / "Google chose different canonical": your sitemap is voting for URLs Google disagrees about. Reconcile — either the sitemap lists the wrong variant, or your canonical tags contradict it.
• Errors (couldn't fetch, parse errors): usually a plugin conflict or a security rule blocking Googlebot from the sitemap URL itself. Test the sitemap URL in an incognito window and with a user-agent switcher.

One habit worth building: after any migration, redesign, or permalink change, fetch your own sitemap and spot-check 10 URLs. Migrations are where sitemaps rot — the plugin regenerates faithfully, but now half the entries redirect. Five minutes of curl or clicking catches it.

Special Sitemaps Worth Knowing About

• News sitemap: if you publish news and want Google News surfaces, a separate news sitemap (articles from the last 48 hours, with publication metadata) is required equipment. Irrelevant for everyone else.
• Image and video extensions: image entries can help media-heavy sites (recipes, portfolios, stock) get images indexed against the right pages; video sitemaps matter if video landing pages are a traffic strategy. For a typical business site, skip both.
• hreflang in sitemaps: multilingual sites can declare language alternates in the sitemap instead of page markup — often cleaner at scale, but pick one method and never both.

Do You Even Need One?

Honest answer: a 30-page brochure site with clean navigation gets close to zero incremental benefit from a sitemap — Google will find everything through links within a crawl or two. Where sitemaps genuinely earn their keep: sites with hundreds of pages or more, sites that publish frequently (the lastmod signal accelerates recrawl of what changed), sites with deep archives or weak internal linking, and any site mid-migration. Since every SEO plugin generates one for free, have it anyway — just calibrate your expectations to your size.

The Bottom Line

A sitemap earns influence by being boringly accurate. The checklist that gets you there: only canonical, indexable, 200-status, worth-indexing URLs; truthful lastmod; no changefreq or priority theater; split by type; referenced in robots.txt; submitted once; reviewed after every migration and, per the Search Console report, once a month. That's maybe an hour of setup and ten minutes of maintenance — after which every claim your sitemap makes is one search engines have learned they can act on. In technical SEO, being reliably honest with crawlers is an actual competitive advantage, mostly because so few sites manage it.

Photo: Tahir Xəlfəquliyev on Pexels