What happens when noindex and a sitemap entry conflict?
- Published November 6, 2026
- Linked from 1 answer
- In a cluster of 51
The noindex rule decides the outcome: Google does not index the page. The sitemap entry does not override it. What the conflict costs is clarity, not the page’s indexing status. Search Console reports such pages under the status URL marked ‘noindex’, which its Page indexing help explains as Google encountering a noindex directive when it tried to index the page and therefore not indexing it.
Why it is still worth fixing
Listing a URL in the sitemap asks Google to crawl it as a page you want found, while the noindex on the page asks Google to keep it out. The two say opposite things, and the sitemap side of the rule has its own page, whether your sitemap should include every URL or only the important ones. The page stays out of results either way, but the conflict adds three costs:
- Noisy reports. Pages you excluded on purpose appear next to pages excluded by mistake, so real problems are harder to see.
- A less useful sitemap. If you filter the Page indexing report to submitted URLs to spot indexing problems, intentional exclusions dilute the view.
- A hint that something is off. Sometimes the conflict is the clue that a noindex was added by accident to a page that belongs in search, for example by a plugin setting or a staging template that reached production.
The third case matters most, so check before deleting the entry: is the noindex intended?
How to resolve it
| The page should | Do this |
|---|---|
| Stay out of search | Keep the noindex and remove the URL from the sitemap |
| Be in search | Remove the noindex, keep the URL in the sitemap, and request indexing in URL Inspection |
| Be gone entirely | Remove it from the sitemap and let it return 404, or redirect it to a true replacement |
The one temporary exception
When you add noindex to a large batch of pages that are already indexed, the rule only takes effect after Google recrawls each page. Leaving those URLs in the sitemap for a short while is a reporting cost you can accept while that happens, but do not move their lastmod dates for the noindex alone. Google’s sitemap documentation says it uses lastmod only when the value is “consistently and verifiably” accurate, and that the date should reflect the last significant update, naming changes to the main content, structured data or links as examples; a noindex change is not among the examples it gives. Keep each date at the page’s last significant change. If the pages have to be out of results by a set date, use the Removals process set out in when “noindex, then remove” beats deleting a page. Once the pages have dropped out of results, take them out of the sitemap.
Add a comment