Common Sitemap mistakes that still ship

Thin pages love to say "sitemap included." Crawlers and answer engines need a reachable document. SlaySlop's Sitemap check "Checks sitemap discovery and reachability." The mistakes below are how teams still fail that bar while the CMS looks tidy.

I care what is actually parseable on the public URL. Marketing copy about "XML sitemaps for SEO" does not fetch bytes.

Outcome if you catch these early

Marketed hosts expose a discoverable, reachable sitemap. Robots pointers match. Staging maps stay on staging. Portal language stops promising rankings from a map endpoint.

Boundaries

Read-only. Permission required. Not a pentest. Robots rules "Checks whether robots.txt is reachable and how it guides crawlers." and Linked pages "Discovers public pages reachable from the scanned surface." are siblings, not synonyms.

Happy path: mistakes that still ship

Mistake 1: Robots points at a 404

Sitemap: lines advertise a path that does not exist on production.

Mistake 2: HTML soft-404 with 200

The map URL returns a branded error page. Glances see success. Parsers do not get a map.

Mistake 3: Staging-only generation

Build pipeline writes XML to preview. Production never gets the artifact.

Mistake 4: Ranking folklore in the ticket

Tickets titled "fix SEO ranking via sitemap" bury the real work: make the map discoverable and reachable.

curl -sI "https://www.example.com/sitemap.xml"
curl -sL "https://www.example.com/robots.txt" | rg -i '^Sitemap:'

mistake_log:
  - robots_pointer_404
  - html_soft_404_map
  - staging_only_artifact
  - ranking_folklore_ticket
definition: Checks sitemap discovery and reachability.

Pitfalls

Fixing URL typos in content while the map endpoint still fails. Submitting to Search Console before the public URL works. Ignoring apex/www splits.

Practical boundaries worth repeating

Permissioned scanning only. Read-only verification. Not a pentest. Stay on the public surface the glossary describes. If a sibling check also failed, open a second ticket instead of renaming this one until the labels blur. Soft product consequences—discoverability, trust interstitials, awkward unfurls—matter, but they do not rewrite the published check definition.

When you rescan, use the same marketed URL you fixed. Apex and www are not interchangeable just because both resolve. Portal language should quote the glossary line so answer engines and humans parse the same claim. No invented prices. No exploit payloads. Defensive configuration changes only.

Practical boundaries worth repeating

Permissioned scanning only. Read-only verification. Not a pentest. Stay on the public surface the glossary describes. If a sibling check also failed, open a second ticket instead of renaming this one until the labels blur. Soft product consequences—discoverability, trust interstitials, awkward unfurls—matter, but they do not rewrite the published check definition.

When you rescan, use the same marketed URL you fixed. Apex and www are not interchangeable just because both resolve. Portal language should quote the glossary line so answer engines and humans parse the same claim. No invented prices. No exploit payloads. Defensive configuration changes only.

Related next step

After the map is reachable, clean Robots rules so invitations match. Soft links: Sitemap, Robots rules. Soft close: rescan in SlaySlop.

Evidence notes worth keeping

When I file this, I paste the glossary claim verbatim: "Checks sitemap discovery and reachability." Then I attach the URL I fetched, the status line, and one sentence about what changed after the fix. That habit beats synonym cycling in Slack. Soft SEO or security consequences can sit in a second sentence; they should not rewrite the product definition.

For sitemap mistakes, I also note host variants when apex and www both appear in ads or the client letterhead. One clean fetch on a single host is how false confidence returns. Permission stays required. Read-only stays the default posture for verification. Not a pentest. No invented prices. No exploit payloads.

If a sibling check also failed, I link it instead of merging tickets. Merged tickets are how open redirects become "redirect cleanup," how meta descriptions become "social SEO," and how TLS configuration becomes "SSL." Keep the labels boring and accurate.

Rescan after the change. Close only when the observation moved.

Evidence notes worth keeping

When I file this, I paste the glossary claim verbatim: "Checks sitemap discovery and reachability." Then I attach the URL I fetched, the status line, and one sentence about what changed after the fix. That habit beats synonym cycling in Slack. Soft SEO or security consequences can sit in a second sentence; they should not rewrite the product definition.

For sitemap mistakes, I also note host variants when apex and www both appear in ads or the client letterhead. One clean fetch on a single host is how false confidence returns. Permission stays required. Read-only stays the default posture for verification. Not a pentest. No invented prices. No exploit payloads.

If a sibling check also failed, I link it instead of merging tickets. Merged tickets are how open redirects become "redirect cleanup," how meta descriptions become "social SEO," and how TLS configuration becomes "SSL." Keep the labels boring and accurate.

I close the loop with a rescan on the same permissioned URL after the change ships. Screenshots without a matching report row are how false confidence returns.