Missing or broken XML sitemap

Discovery. It hands a crawler a list of URLs in one document instead of requiring it to find each by following links. On a large site, or one whose newest pages are linked from deep in a section, this is the difference between being found this week and next month.

A modification signal. `<lastmod>` tells a crawler when the content at a URL last changed, which is the one piece of scheduling information you can supply.

It does not affect ranking. Google's documentation is explicit that a sitemap does not guarantee that the URLs in it will be crawled or indexed.

It also does not replace internal linking. A URL reachable only from the sitemap is discoverable but unsupported — nothing on the site tells the crawler, or a reader, that the page matters.

Listing URLs that redirect. The sitemap should name final destinations; a list of redirects wastes a crawl on every entry and states that the wrong URL is the canonical one.

Listing URLs that 404, or that carry `noindex`, or that canonicalise elsewhere. Each is a direct contradiction between what the sitemap advertises and what the page says, and it is reported in Search Console as such.

A `<lastmod>` stamped from the deploy date. If every URL claims to have changed today, on every release, the field stops carrying information. Google has said it ignores `lastmod` when it is demonstrably inaccurate, so a wrong date is worth less than no date.

Exceeding the format's limits: 50,000 URLs or 50 MB uncompressed per file. Beyond that the file needs splitting behind a sitemap index.

Mixing hosts. A sitemap may only list URLs on the host it is served from, unless cross-submission is set up in Search Console.

Fetch it: `curl https://example.com/sitemap.xml`. Confirm it returns 200, is valid XML, and is served as `application/xml` or `text/xml`.

Check that `robots.txt` declares it with a `Sitemap:` line — that is how a crawler that was not told about it finds it.

Sample a dozen URLs from the file and request each one. Every one should return 200, and none should carry `noindex` or point its canonical somewhere else.

Compare the sitemap against a crawl of the site. URLs in the sitemap that no internal link reaches, and pages the crawl reaches that the sitemap omits, are both findings — and the second is usually the more interesting one.

In Search Console, the Sitemaps report shows what was submitted, when it was last read, how many URLs were discovered, and any parsing errors.

Generate it from the same source that decides what is published, so a page cannot exist without being listed and cannot be listed without existing.

Include only canonical, indexable URLs that return 200. Exclude anything that redirects, 404s, carries `noindex`, or canonicalises elsewhere.

Set `lastmod` from a real content-modification date, or omit it. Both are defensible; an invented date is not.

Split by section once the site is large, behind a sitemap index. Search Console reports coverage per submitted file, so separate files tell you which section is not being indexed — one file reports one number for everything.

Declare it in `robots.txt` and submit it in Search Console. The two paths are independent and both are cheap.

`seo.sitemap` looks for the sitemap at the conventional location and at whatever `robots.txt` declares, reports whether it exists and parses, and reports the URLs it lists.

It cross-checks those URLs against what the crawl found: entries that redirect, 404 or carry `noindex` are reported individually, as is the gap between crawled pages and listed pages.

`seo.robots_txt` covers whether the file is advertised at all, which is the most common reason a correct sitemap goes unread.