Sitemaps and canonicals: the boring pair that decides what gets read

Sitemaps and canonical tags do unglamorous jobs, get set up once, and then rot silently. Both failures are cheap to fix and neither announces itself, which is a poor combination.

Two different jobs

They are often mentioned together and are frequently confused. A sitemap says which URLs exist and are worth reading. A canonical says which URL should represent a page when the same content is reachable at several addresses. One is discovery; the other is consolidation.

How sitemaps break

Listing URLs that no longer resolve

The most common defect. Pages are removed, the sitemap is not regenerated, and it advertises addresses that return errors. A sitemap full of dead links is a statement that the site is not maintained.

Listing URLs that are blocked or non-canonical

A sitemap listing a URL that robots.txt disallows sends contradictory instructions. So does listing a URL whose canonical points elsewhere: it says 'read this' and 'actually, read that instead' simultaneously. Only list URLs you want read, that are reachable, and that are canonical.

lastmod that means nothing

Many systems set lastmod to build time, so every page claims to have changed on every deploy. Once the field is known to be unreliable it stops carrying information. Either reflect genuine content changes or omit the field.

How canonicals break

Every page pointing at the homepage

A template bug that appears periodically and is unusually damaging: it tells a reader that every page on the site is really the homepage. Worth checking on a handful of pages after any template change.

Missing entirely on parameterised URLs

Filtering, sorting, tracking parameters, and session identifiers produce many addresses for the same content. Without a canonical, each is a separate page as far as a reader is concerned, splitting whatever attention and references the content earns.

Relative, protocol-relative, or inconsistent

Use one absolute URL, with a consistent choice of scheme, host, and trailing slash. A canonical differing from the actual address only by a trailing slash or www prefix creates precisely the ambiguity it exists to resolve.

Every page should name itself

A frequent question is whether a page with no duplicates needs a canonical at all. It does, and the reason is that duplicates arrive without being created deliberately.

Any page can be reached with a tracking parameter appended by a campaign, an analytics platform, or someone sharing a link from an app that adds one. A self-referencing canonical means every one of those variants resolves back to the same address. Without it, a single shared link can quietly fork a page into several.

When a site outgrows one sitemap

The protocol caps a single sitemap file at 50,000 URLs and 50MB uncompressed. Past that, split into multiple files and reference them from a sitemap index.

Splitting by content type rather than arbitrarily is worth the small extra effort — products, articles, and category pages in separate files. Doing so makes it possible to see which section has coverage problems, which a single undifferentiated file hides entirely.

A five-minute check

1. Fetch your sitemap. Does it load, and are the URLs current?
2. Pick five entries at random and request each. Do they return 200?
3. View source on three different pages. Does each declare a canonical, and does each point at itself?
4. Load a page with a tracking parameter appended. Does the canonical still point at the clean URL?
5. Confirm robots.txt declares the sitemap location.

Worth repeating after any migration, replatform, or template change, which is when these break. They rarely break on their own — they break when something else changes and nobody thought to look.