Why Google Ignores My Sitemap (And How to Actually Fix It)

Submitting a sitemap feels like it should be a guarantee — you handed Google an explicit list, so why isn't every URL on it indexed? Because a sitemap was never a command. It's a hint about which URLs exist and that you consider indexable, and Google is free to disregard any of them if its own crawling and quality checks disagree.

That reframe matters because it changes where you look. The fix usually isn't "resubmit the sitemap" — it's finding which layer actually rejected the URL: the sitemap file itself, a contradicting signal elsewhere on your site, or the page's own quality.

Start with the Sitemaps report, not the pages

Before diagnosing individual URLs, check whether Google is even processing your sitemap cleanly. In Search Console → Sitemaps, click into your submitted sitemap and look at:

• Status — should read "Success." "Couldn't fetch" or "Has errors" means Google isn't reading the file at all, which explains everything downstream at once.
• Discovered URLs — compare this count to how many URLs you actually expect. A big gap here (not per-page indexing, but total discovery) usually means a malformed or truncated sitemap, not individual page problems.
• Last read date — if this is old, Google hasn't re-fetched your sitemap recently. It won't pick up new or changed URLs until it does.

If the sitemap itself is broken or stale, fix that first — every downstream diagnosis is meaningless until Google is actually reading a current, valid file.

The four real causes for individual stuck URLs

Once the sitemap itself is confirmed healthy, check each stuck URL against these, in order.

1. The sitemap disagrees with your own canonical signals

If a URL is in your sitemap but its own rel=canonical tag points somewhere else, Google trusts the canonical over the sitemap listing — you're telling it two different things about the same URL. This is a very common auto-generated-sitemap bug: the sitemap lists the raw URL, but the page's canonical (correctly) points to a cleaned-up version.

Tell: open the URL, view source, check its canonical tag — it points at a different URL than the one in your sitemap.

2. The sitemap lists URLs that redirect, 404, or are noindexed

A sitemap entry should be a live, indexable, 200 OK page. If it's actually a redirect, a dead link, or carries a noindex, Google won't index it from the sitemap — and worse, a sitemap full of these damages Google's trust in the file as a whole.

Tell: curl -I the URL directly — anything other than a clean 200 with no noindex header is the cause.

3. Google crawled it and passed on quality grounds

Being in a sitemap doesn't exempt a page from Google's normal indexing judgment. Thin content, heavy duplication with another page on your site, or an orphaned page with no real internal links can all still result in exclusion — sitemap or not. This shows up as Crawled – currently not indexed in the Pages report, and the sitemap listing didn't change that outcome.

Tell: URL Inspection shows a recent crawl date but "not indexed" — Google saw it and said no anyway.

4. Google hasn't gotten to it yet

On a new or lower-authority site, or a very large sitemap, Google prioritizes which listed URLs to actually crawl rather than working through the whole file immediately. Being listed increases the odds of eventual discovery — it doesn't guarantee a timeline.

Tell: URL Inspection shows no crawl date at all — this is a priority/timing issue, not a rejection. See how long indexing actually takes.

How to fix each

1. Fix the sitemap file itself first

   If the Sitemaps report shows fetch errors, check the file is valid XML, under the 50,000-URL / 50MB per-file limit (split into an index of multiple sitemaps if you're over), and reachable without requiring authentication or a redirect. Resubmit only after the file itself loads clean in a browser.

2. Align sitemap entries with canonical tags

   For cause 1: your sitemap generator should pull the same canonical URL your pages actually declare — not a raw or unprocessed version. If you're hand-maintaining a sitemap, audit it against your canonical tags directly; if it's auto-generated, the bug is in the generation logic, not something to patch per-URL.

3. Strip dead weight from the sitemap

   For cause 2: remove redirecting, 404ing, and noindexed URLs from the sitemap entirely. Most CMS sitemap plugins do this automatically going forward, but a stale or hand-edited sitemap can carry dead entries for a long time. A clean sitemap with fewer, all-valid URLs is more trustworthy to Google than a large one with dead links mixed in.

4. Treat quality misses as a content problem

   For cause 3: being listed in the sitemap doesn't change what earns indexing. Follow the fixes in Crawled – currently not indexed — strengthen thin content, resolve duplication, or add real internal links. The sitemap did its job (Google found the URL); the content didn't clear the bar.

5. For priority gaps, raise the page's profile

   For cause 4: add internal links from already-indexed, relevant pages — this does more to raise crawl priority than anything sitemap-related. A sitemap entry alone is a weak signal compared to a real link from a page Google already trusts.

By platform: where sitemap generation actually breaks

WordPress — Yoast/Rank Math sitemaps are usually reliable, but a "Content Types" setting can silently exclude a post type, or a plugin conflict can produce a malformed file. Check Search Appearance settings before assuming a per-page issue.

Shopify — /sitemap.xml is fully automatic; you can't hand-edit it. If URLs are missing, the cause is almost always the page/product's own visibility or search-engine-listing setting, not the sitemap mechanism itself.

Next.js / React — the most common break is a sitemap.ts (or next-sitemap config) that queries a data source that's out of sync with what actually renders pages — new content types added to the app but never added to the sitemap query.

Webflow — check each CMS Collection's own SEO settings for the "include in sitemap" toggle; it's per-Collection, so one new Collection type can be silently excluded while others work fine.

How to know it's fixed

1. Confirm sitemap processing is clean

   Sitemaps report should show "Success" with a recent "Last read" date and a Discovered count matching your expectations.

2. Re-check individual URLs in URL Inspection

   For URLs you fixed, confirm "URL is on Google," and that User-declared and Google-selected canonical match.

3. Give it real time

   Sitemap re-processing plus a subsequent crawl-and-index decision realistically takes days to a couple of weeks. Don't resubmit the sitemap repeatedly hoping to speed this up — it doesn't.

When it's not actually a problem

If only a small number of low-priority URLs (old content, minor variants) are sitting unindexed despite being in your sitemap, and your important pages are all indexed fine, this usually isn't worth chasing. Google's selectivity here is often correct — not every URL you generate needs to rank on its own.