Troubleshooting guideReviewed 2026-08-13By HostWithShery technical editorial

Sitemap submitted but pages are not indexed

A successful XML sitemap helps search engines discover preferred URLs, but sitemap submission does not guarantee crawling or indexing. First confirm that important pages are internally linked, crawlable, self-canonical and return useful indexable content.

Start with evidence from your own domain before changing DNS, SSL or mail settings.
Check your own configuration

XML Sitemap Tester

This page is preconfigured with the XML Sitemap Tester that best matches this problem.

No accountPublic evidence only
Live public check

Finds the declared/default sitemap, checks XML/content type and validates child sitemap references.

No account · Public configuration only
On this page

What this symptom usually tells you

A sitemap is a discovery and canonical hint, not an indexing command. When Search Console shows very few known pages, first determine whether Google can reach important URLs through ordinary links and whether the sitemap, internal links and self-canonical all use the same URL form. Only after discovery is established does it make sense to diagnose pages that Google crawled but chose not to index.

Evidence that narrows the cause

Use the live diagnostic to test the exact hostname involved. For this problem, the highest-value evidence is below. Treat each result as one piece of the HTTP routing and redirects diagnosis rather than as a standalone health score.

  • Sitemap URL returns successfullyFetch the directive exactly as a crawler would and check both file-level rules and page/header directives; one healthy signal does not override a blocking signal elsewhere.
  • Important pages have crawlable internal linksVerify important pages have crawlable internal links from the public Internet and compare it with the value the responsible provider says should be live.
  • Canonical points to the same preferred URLFollow every hop rather than checking only the final page. The conflicting rule is usually visible where the chain changes scheme, hostname or destination repeatedly.
  • Robots/noindex do not block indexingFetch the directive exactly as a crawler would and check both file-level rules and page/header directives; one healthy signal does not override a blocking signal elsewhere.
  • Page returns a useful final responseRecord the public status, final URL and relevant response headers. A working DNS answer does not prove that the application is serving a genuine website response.

Record the current state before editing

Before changing HTTP routing and redirects settings, save the exact public values for sitemap URL returns successfully, important pages have crawlable internal links, canonical points to the same preferred URL, robots/noindex do not block indexing, page returns a useful final response and note which hostname or mail path is failing. This creates a rollback point and prevents a later resolver cache, provider dashboard or unrelated working record from being mistaken for the original cause. Change one evidence-backed setting at a time, then compare the same signals again.

Safest repair path

Use one canonical URL format consistently in internal links, metadata and the sitemap. Ensure each important page is reachable from a crawlable hub or navigation path, returns a normal indexable response, and is not blocked by robots.txt, meta robots or X-Robots-Tag. Improve or consolidate pages whose intent and content substantially overlap instead of requesting indexing for weak variants.

How to confirm this specific repair

Fetch the sitemap and representative pages publicly, confirm the sitemap lists the same self-canonical URLs that the pages serve, and navigate from the homepage to those pages through standard links. In Search Console, distinguish “not discovered/known yet” from a reported exclusion such as Crawled — currently not indexed; they are different stages and need different responses.

A common wrong turn

Do not assume every URL missing from the Page indexing report has been rejected. A new site may simply not have had those URLs discovered or processed yet, and repeatedly changing titles or resubmitting the sitemap does not substitute for crawlable internal architecture and useful distinct pages.

When to escalate with evidence

If these public checks match the provider's current documented configuration but the service still fails, give support the exact hostname, the observed HTTP routing and redirects result, a timestamp, and the failing network or message path. That separates a provider-side incident from a DNS change that has not actually become authoritative.

Technical references

These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.