Sitemap Errors That Block Google Indexing (and How to Fix Them)
Direct answer
A sitemap helps Google find your pages, but errors in it can block indexing. Remove stale and noindex URLs, keep lastmod dates honest, submit the sitemap in Search Console, and keep each sitemap file within Google's size limits. A clean sitemap does not guarantee indexing, but a broken one quietly stops pages from being discovered.
TL;DR / Key takeaways
- A sitemap is a list of a site's pages, offered to search engines to help them discover content.
- It does not force Google to index a page, but errors in it can prevent discovery.
- The five errors that matter most: stale URLs, noindex pages listed, wrong lastmod dates, a sitemap that was never submitted, and a sitemap that is too large.
- Each error has a simple fix and a simple check in Search Console.
- Check the sitemap after every major site change, not just when something goes wrong.
What is a sitemap, and what does it actually do?
A sitemap is a file, usually in XML format, that lists the pages on a website that the owner wants search engines to find. A typical entry gives the page's URL and, optionally, the date it was last modified. Larger sites may use a sitemap index file that points to several smaller sitemap files.
It is important to be clear about what a sitemap does not do. It does not promise that Google will index a listed page, and it does not improve a page's ranking. Google's own sitemap documentation says this plainly: a sitemap helps Google discover pages, especially on new or large sites, but inclusion is a hint, not a promise.
What a sitemap does do is make discovery easier and more reliable. Google can find pages by following links, but links can be missed, especially on a new site with few incoming links, or on a large site where some pages sit several clicks from the homepage. A sitemap gives Google a direct list, so a page does not depend entirely on being linked from somewhere crawlable.
For a blogger, the sitemap is therefore a quiet piece of infrastructure. When it is correct, nothing dramatic happens; pages get discovered a little more reliably. When it is wrong, pages can sit undiscovered for months while the owner wonders why a post never appears in search. The errors below are the ones that cause that silence.
Error 1: Stale URLs — pages that no longer exist
Crawl waste from stale sitemaps also strains crawl budget.
A stale URL is a sitemap entry pointing to a page that has been deleted, moved, or renamed without a redirect. The sitemap says the page exists; the server says it does not.
Why it blocks indexing
Every stale URL wastes a little of Google's attention on a page that cannot be indexed, and a sitemap full of dead ends signals that the sitemap is not maintained. Google may start trusting the sitemap less, which hurts the new pages that actually need discovery. Stale URLs also hide real problems: if old URLs keep appearing in the sitemap, nobody notices that the redirects were never set up.
How to spot it
Open the sitemap in a browser and click through a sample of entries, or run a crawler or link checker over it. The broken link checker is useful here, since a sitemap is, in effect, a list of links. In Search Console, the sitemap report and the Page indexing report will also show URLs that return errors.
The fix
Remove deleted pages from the sitemap. If a page moved, either update the entry to the new URL or set up a proper redirect from the old URL to the new one and list only the new URL. Then regenerate the sitemap from the live site rather than editing it by hand, so the list reflects reality. Most content systems and static site generators can regenerate a sitemap automatically; if yours cannot, regenerate it after every batch of deletions or renames, and make that step part of the publishing routine.
Error 2: Noindex pages listed in the sitemap
A noindex instruction tells Google not to index a page. Listing that same page in the sitemap tells Google that the page is worth discovering. Those two signals contradict each other.
This happens more often than owners expect. Common cases include thank-you pages, staging pages that leaked into production, filtered or sorted versions of a category page, and drafts that were published briefly and then hidden. A plugin or generator that builds the sitemap from every page in the database, without checking each page's indexing status, will include all of them.
Why it blocks indexing
Google has to resolve the contradiction, and the noindex instruction wins: the page is not indexed. But the contradiction also wastes crawl effort and, in larger quantities, muddies the sitemap's signal. Google's sitemap guidance is explicit that sitemaps should list only pages the owner wants indexed, and that listing noindex pages is a common mistake.
How to spot it
Compare the sitemap against the site's noindex list. In Search Console, the Page indexing report shows pages that were "discovered but not indexed" or "excluded by noindex tag" — if those URLs also appear in the sitemap, you have found the overlap. A crawler that reports both sitemap membership and noindex status makes the comparison quick.
The fix
Remove every noindex page from the sitemap, and fix the generator so it excludes noindex pages automatically. The rule is simple: if a page carries a noindex tag or header, it does not belong in the sitemap, full stop. Check this after installing any new plugin or theme, since those are the moments when a previously correct sitemap starts including pages it should not.
Error 3: Wrong lastmod dates
The lastmod field records when a page was last modified. It is optional, but when it is present, Google may use it to decide whether a page is worth re-crawling. The error is not missing lastmod — that is harmless — but wrong lastmod: dates that are wrong in a systematic way.
The most common versions are: every page stamped with today's date on every sitemap regeneration, regardless of whether anything changed; every page stamped with the site's launch date, forever; and lastmod dates in the future, caused by a timezone or server-clock problem.
Why it blocks indexing
If every page claims to have changed today, Google cannot tell which pages actually changed, so the signal becomes useless and may be ignored. If no page ever claims to have changed, Google has no reason to re-crawl a page that did change, so updates can take longer to be picked up. In both cases the sitemap stops helping Google prioritise, which is one of its main jobs for an existing site. Google's documentation warns against using lastmod values that do not reflect real changes.
How to spot it
Open the sitemap and look at the lastmod values. If dozens of untouched pages all show today's date, the generator is stamping blindly. If a page you edited yesterday still shows a date from months ago, the generator is not tracking changes. Future dates are the easiest to spot and the clearest sign of a configuration problem.
The fix
Make lastmod reflect the actual last modification of each page: the date the content, not just the template, changed. Most content systems do this correctly if the sitemap is generated from the content database. If your generator stamps every page on every build, either configure it to use real modification dates or drop the lastmod field entirely — an absent lastmod is better than a false one. After fixing, spot-check a recently edited page and an untouched page to confirm their dates differ sensibly.
Error 4: A sitemap that was never submitted
This is the simplest error and the easiest to overlook. A site can have a perfectly correct sitemap sitting at its standard address, but if it was never submitted in Search Console and never referenced in robots.txt, Google may take much longer to find it, especially on a new site with few incoming links.
This commonly happens when a site is rebuilt, migrated, or launched in a hurry: the sitemap exists, the owner assumes Google knows about it, and nobody ever checks the Search Console sitemap report. It also happens after a move to a new domain or a new Search Console property, where the old property had the sitemap but the new one does not.
Why it blocks indexing
Without submission, discovery depends entirely on Google finding the sitemap by crawling or by following a robots.txt reference. That usually happens eventually, but "eventually" can mean weeks on a new site, and in the meantime new posts sit undiscovered. Submission does not force indexing, but it removes an unnecessary delay and gives the owner a report that shows errors, which is valuable in itself.
How to spot it
Open Search Console, go to the Sitemaps report, and look for your sitemap's URL. If it is absent, it was never submitted. Also check robots.txt for a sitemap reference. If neither exists, the sitemap is effectively invisible except to a crawler that happens to guess its address.
The fix
Submit the sitemap in Search Console under the correct property, and add a sitemap reference to robots.txt pointing at the sitemap's full URL. Then check the Sitemaps report after a day or two: it should show the sitemap as successfully read, with a count of discovered URLs. If it shows an error, fix that error first — a submitted sitemap with errors is still better than silence, because at least the error is visible. Our guide to measuring blog SEO results in Google Search Console explains where these reports live and how to read them.
Error 5: A sitemap that is too large
Google's limits for a single sitemap are 50,000 URLs and 50 MB uncompressed. A small blog will never come close to the URL limit, but the size limit can be reached in surprising ways: image or video extensions, very long URLs, or a generator that stuffs every tag, category, author, and attachment page into one file.
More commonly for bloggers, "too large" means too indiscriminate rather than literally over the limit. A sitemap that lists every thin tag page, every paginated archive, and every attachment page is technically valid but practically noisy. Google has to sort the pages that matter from the pages that do not, and the important new posts can get lost in the crowd.
Why it blocks indexing
An oversized sitemap may be rejected outright, in which case none of its URLs get the discovery benefit. An indiscriminate sitemap is not rejected, but it dilutes attention: crawl effort spent on tag archives is effort not spent on new articles.
How to spot it
Check the sitemap's URL count and file size in the Search Console Sitemaps report, or by counting entries in the file. Then scan the entries: if tag pages, paginated archives, and media attachment pages outnumber real articles, the sitemap is too indiscriminate.
The fix
Split a large sitemap using a sitemap index file, with each child sitemap under the limits. More importantly, prune the entries: list posts, pages, and key category pages, and exclude thin tag pages, paginated archives, and attachment pages unless they genuinely deserve indexing. A smaller, honest sitemap is more useful than a comprehensive one that lists everything the database contains.
Comparison: the five errors at a glance
| Error | What Google sees | Symptom a blogger notices | Fix |
|---|---|---|---|
| Stale URLs | Dead ends in the sitemap | Old URLs in Search Console error reports | Remove deleted pages; regenerate from the live site |
| Noindex pages listed | Contradictory signals | Pages "excluded by noindex" that are also in the sitemap | Remove noindex pages; exclude them automatically |
| Wrong lastmod | Untrustworthy change dates | Updates slow to appear; every page dated today | Use real modification dates, or drop lastmod |
| Never submitted | No sitemap on record | Sitemaps report empty; new posts slow to appear | Submit in Search Console; reference in robots.txt |
| Too large or indiscriminate | A file too big to trust, or too noisy to prioritise | Sitemap rejected, or new posts buried among tag pages | Split with an index file; prune thin entries |
Step-by-step: a sitemap health check a blogger can run
Step 1: Find the sitemap
Check the standard addresses first, usually /sitemap.xml, and check robots.txt for a sitemap reference. If neither exists, the site may not have a sitemap at all, and creating one is the first job.
Step 2: Open it and read a sample
Open the sitemap in a browser. Scan for obviously wrong entries: URLs from an old domain, staging subdomains, tag pages, or pages you know were deleted. A five-minute scan often finds the biggest problem.
Step 3: Check Search Console's Sitemaps report
Confirm the sitemap is submitted, successfully read, and showing a plausible count of discovered URLs. Note any errors or warnings, and fix those before anything else.
Step 4: Compare against the indexing report
Open the Page indexing report and look for patterns: many pages excluded by noindex, many not found, or many discovered but not indexed. Cross-check the affected URLs against the sitemap. Overlap between an exclusion reason and sitemap membership points straight at error 1 or error 2.
Step 5: Fix, regenerate, and resubmit
Make the fixes at the source — the generator's settings, not a hand-edited sitemap file — so the next regeneration does not undo them. Then regenerate, resubmit if the URL changed, and re-check the Sitemaps report after a day or two.
Step 6: Repeat after every major change
Re-run this check after a redesign, a migration, a domain change, or installing a new SEO plugin. Those are the moments when a healthy sitemap quietly breaks, and catching it in the same week is far easier than diagnosing months of missing traffic later. A related routine worth pairing with this one is refreshing older content, covered in how to refresh old blog content for SEO.
How this looks on Rankenza
The manual way to keep a sitemap healthy is a recurring chore: remember to regenerate it, remember to check Search Console, remember to prune it after a redesign. It is exactly the kind of chore that gets skipped, which is why sitemap errors are usually discovered months after they started.
Rankenza's way reduces the surface for these errors on the content side. New articles are researched from the top 10 search results, checked against search intent, and reviewed by a human before delivery, and internal links are built from the customer's own sitemap — which means the sitemap itself becomes part of the working process, not a file nobody opens. When the sitemap is used as the source for internal links, a stale or bloated sitemap becomes visible quickly, because the links it produces point at the wrong places.
The first article is free, then $3.60 per article or $89 for 50 articles, with no subscription. A blogger fixing their indexing can start with one free article and check that it links sensibly into the existing site, then build out new posts on a clean foundation. For the underlying concepts, see the sitemap and crawl budget glossary entries, and check new posts with the redirect checker when URLs have moved.
No. A sitemap helps Google discover pages, but indexing depends on the page's quality, uniqueness, and whether Google considers it worth indexing. A clean sitemap removes obstacles to discovery; it does not override Google's judgement about the page itself. Pages can also be indexed without a sitemap, through links, but a sitemap makes discovery more reliable, especially for new sites.
Check the Page indexing report for that specific URL to see Google's stated reason: it may be marked as duplicate, low quality, blocked by robots.txt, or simply not yet crawled. A sitemap error is only one possible cause. If the reason is "discovered, currently not indexed", the page is known but not yet prioritised, and improving the page's content and its internal links is usually more productive than resubmitting the sitemap repeatedly.
Only if those images or videos are important to the site and you want them discoverable through search. For most blogs, the standard page sitemap is enough, and image or video extensions add size and complexity without a clear benefit. If you do add them, keep the entries accurate: an image sitemap pointing at removed images has the same staleness problem as a page sitemap pointing at removed pages.
After every major site change, and otherwise a quick check every few months is enough for a small blog. The check itself is short: submitted, readable, plausible URL count, no obvious stale or noindex entries. Pair it with a content refresh cycle so that infrastructure and content stay healthy together.
Sources
- Google Search Central, "Build and submit a sitemap": https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
- Google Search Central, "Sitemap common mistakes": https://developers.google.com/search/docs/crawling-indexing/sitemaps/common-mistakes
- Google Search Central, "Sitemap index files": https://developers.google.com/search/docs/crawling-indexing/sitemaps/sitemap-index
- Sitemaps protocol: https://www.sitemaps.org/protocol.html