XML Sitemaps That Actually Help You Get Indexed

A sitemap is not a magic indexing button. It is a hint — but it is one of the few direct channels you have for telling Google which URLs you consider important, and a well-maintained one measurably improves discovery on larger sites.

The problem is that most sitemaps are generated once by a plugin, never audited, and quietly full of URLs that contradict everything else on the site.

The single rule that matters

Every URL in your sitemap should be a URL you want indexed, and every URL you want indexed should be in your sitemap.

That sounds obvious. In practice, the average sitemap contains redirects, 404s, noindex pages, canonicalised duplicates and parameter variants. Each one is a small contradiction: you are telling Google "this is important" while the page itself says "do not index me". Enough of those and the sitemap stops being treated as a reliable signal.

What to exclude

• Anything returning a non-200 status. Redirects and errors do not belong in a sitemap.
• noindex pages. A direct contradiction.
• Canonicalised duplicates. Include the canonical, not the variants.
• Pages blocked by robots.txt. Google cannot act on them anyway.
• Thin archives. Empty tag pages and paginated date archives usually add nothing.

Get lastmod right or leave it out

Google has said it uses lastmod when the value is consistently accurate — and ignores it entirely when it is not. Many CMS plugins set lastmod to the sitemap generation time, meaning every URL appears to have changed every day. That is worse than omitting the field, because it trains Google to distrust it.

Rule: update lastmod only when the page content meaningfully changed. A typo fix does not count.

<url>
  <loc>https://example.com/guides/indexing</loc>
  <lastmod>2026-07-14</lastmod>
</url>

The priority and changefreq fields are ignored by Google. You can safely drop them.

Split large sitemaps sensibly

A single sitemap file may contain up to 50,000 URLs and must not exceed 50 MB uncompressed. Beyond that you need a sitemap index file pointing at multiple sitemaps.

Split by content type rather than arbitrarily — products, articles, categories. When Search Console reports coverage per sitemap, you immediately see which section has an indexing problem instead of staring at one undifferentiated number.

Multilingual sites: add hreflang

If you publish the same content in several languages, declaring the alternates in the sitemap is cleaner than stuffing dozens of tags into every page head:

<url>
  <loc>https://example.com/blog/indexing</loc>
  <xhtml:link rel="alternate" hreflang="es"
              href="https://example.com/blog/indexacion"/>
  <xhtml:link rel="alternate" hreflang="de"
              href="https://example.com/blog/indexierung"/>
</url>

Every alternate must point back at the others, including itself. A one-way declaration is ignored.

Submit it, then actually read the report

Add the sitemap URL to robots.txt so any crawler can find it:

Sitemap: https://example.com/sitemap.xml

Then submit it in Search Console and — this is the part people skip — check the coverage report against it weekly. The gap between "discovered" and "indexed" is the number that tells you whether your content is clearing the quality bar.

Where sitemaps stop helping

A sitemap tells Google what exists. It does not tell Google to hurry. On a site with an established crawl rhythm, a new URL in the sitemap may still wait days for attention, and on a low-authority domain it can wait considerably longer.

When timing matters — a product launch, a news piece, a fresh batch of backlinks — a sitemap alone is too passive. That is when a direct submission through indx.it.com is worth the credit: it pushes the URL through priority discovery channels rather than waiting for the next scheduled crawl.

Use both. The sitemap keeps your site legible; direct submission handles the urgent cases.