XML Sitemaps Done Right: Indexes, lastmod and Images

An XML sitemap is a file that lists the URLs on your site you want search engines to know about, with optional details such as when each page last changed. Google uses sitemaps as a hint for discovery and for choosing canonical URLs, especially on large sites, new sites with few links and sites whose content changes often.

A good sitemap lists only canonical, indexable pages that return a 200 response, uses honest last-modified dates and stays within Google's limits of 50,000 URLs or 50 MB uncompressed per file, splitting into several files under a sitemap index when needed. A poor sitemap, full of redirects, noindexed pages and dates that change on every request, wastes crawler attention and teaches Google to ignore your hints.

This guide walks through what to include, how to structure large sitemaps, how to generate them in PHP and how to check that Google is using them.

What an XML sitemap does and does not do

Google's guide to building and submitting a sitemap describes it as a way to tell Google about the pages you consider important. It helps Google discover pages it might miss through links and understand when pages changed.

It does not guarantee crawling or indexing. Google still decides which URLs to crawl and whether to index them. A page listed in a sitemap but linked from nowhere, thin or duplicated is unlikely to perform well. Treat the sitemap as a complement to good internal linking, not a substitute.

Sitemaps matter most in a few situations: very large sites where some pages sit deep in the structure, new sites with few external links, sites that publish or change content often, and sites with rich media such as many images or videos. For a ten-page brochure site with good navigation, a sitemap is still useful for reporting, but Google would find the pages anyway.

What belongs in a sitemap

The simplest rule is to list the URLs you would be happy to see in search results, in exactly the form you want them to appear.

• Include: canonical pages that return 200: home, services, products, categories, articles, location pages and important help content.
• Exclude: redirects, 404s, pages marked noindex, URLs blocked in robots.txt, duplicates that canonicalise elsewhere and pages behind a login.
• Exclude: filter, sort, search-result and tracking-parameter URLs, unless a specific filter page is meant to rank.
• Use absolute URLs on the same scheme and host as the canonical version.

Every excluded type sends a mixed signal if it appears. A sitemap listing a URL that redirects says "this is important" while the server says "this has moved". Our guides to canonical URLs and robots.txt and noindex explain how those signals interact.

Sitemap indexes for larger sites

Once a site has many URLs or several content types, split sitemaps into separate files and list them in a sitemap index. Each child sitemap stays within the limits, and the index itself can list up to 50,000 sitemaps.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemaps/posts.xml</loc>
    <lastmod>2026-10-10T08:15:00+05:30</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemaps/services.xml</loc>
  </sitemap>
</sitemapindex>

Splitting by content type, such as pages, services, products, posts and categories, has a practical benefit beyond the limits. Search Console reports indexing per submitted sitemap, so you can see at a glance whether products or articles have an indexing problem. Our own site uses this structure, with separate sitemaps for posts, services, locations and other sections.

Sitemaps are machine-readable, but people open them too, usually when checking whether a page is listed. An optional XSL stylesheet referenced at the top of the file can render the XML as a readable table in a browser, while search engines continue to read the raw XML. It is a small touch that saves confusion for editors and clients.

Honest lastmod dates

The lastmod value should reflect the last meaningful change to the page's main content. Google says it uses the value only if it is consistently accurate. If every URL shows today's date on every request, or dates change when only a footer link changes, Google has good reason to ignore them.

• Store a content-updated timestamp separately from a generic updated timestamp that changes on every single save.
• Update it when the main text, price, availability or key details change.
• Do not update it for template changes, view counts or navigation edits.
• Use W3C date-time format, such as 2026-10-23T10:00:00+05:30, or a plain date.

For a sitemap index, the lastmod of each child sitemap can be the latest lastmod of the URLs it contains.

Accurate dates are especially valuable for sites with many pages. When Google can trust them, it can prioritise recrawling the pages that actually changed instead of revisiting everything, which helps updated prices, stock and articles appear in results sooner.

Image entries in sitemaps

Google supports an image extension that lists important images for each page. It helps Google find images that might otherwise be missed, such as those loaded by scripts, though standard image elements in the page remain the main source.

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
  <url>
    <loc>https://example.com/work/jewellery-store</loc>
    <image:image>
      <image:loc>https://example.com/uploads/jewellery-store-1600.webp</image:loc>
    </image:image>
  </url>
</urlset>

List the main image of each page, such as a product photo, article cover or case study image. Our guide to image SEO for online stores covers alt text, formats and other image signals.

Generating sitemaps in PHP

Generate sitemaps from the same data and URL builders as the pages themselves, so the two can never disagree. Query only published, indexable records, build each URL with the same helper the templates use, and escape everything.

// Minimal sitemap controller (PHP 8). $posts come from published, indexable rows only.
$xml = '<?xml version="1.0" encoding="UTF-8"?>' . "\n"
     . '<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">' . "\n";
foreach ($posts as $post) {
    $xml .= '  <url><loc>' . htmlspecialchars(url('/blog/' . $post['slug']), ENT_XML1) . '</loc>'
          . '<lastmod>' . date(DATE_ATOM, strtotime($post['content_updated_at'])) . '</lastmod></url>' . "\n";
}
$xml .= '</urlset>';
header('Content-Type: application/xml; charset=UTF-8');
echo $xml;

• Cache the output for large sites, and regenerate it when content changes or on a regular schedule.
• Stream very large sitemaps rather than building huge strings in memory.
• Compress with gzip if files are large; Google accepts compressed sitemap files.
• Apply the same rules as the pages: if a page is noindexed because it is thin, it should drop out of the sitemap automatically.

Submitting and referencing sitemaps

Tell Google where your sitemap is in two ways. Add a Sitemap: line with the full URL to robots.txt, which any crawler can read. Then submit the sitemap or sitemap index in Search Console, which gives you reporting.

You only need to submit once. Google refetches sitemaps periodically, so there is no benefit in resubmitting the same file every day or using services that "ping" search engines repeatedly. After major changes, such as a migration, you can resubmit to prompt a fresh read. Our guide to Google Search Console explains the reports you will see afterwards.

Monitoring sitemaps over time

The sitemaps report in Search Console shows when each sitemap was last read, whether it could be fetched and how many URLs were discovered. The page indexing report can be filtered by sitemap, which is where the real insight lies.

1. Check that every submitted sitemap shows a recent successful read and no fetch errors.
2. Filter the page indexing report by each sitemap and compare indexed URLs with submitted URLs.
3. Investigate large gaps: thin pages, duplicates or crawl problems in one section.
4. Add automated tests that fetch each sitemap, parse it and confirm every URL returns 200 with a matching canonical.
5. Watch for sitemaps that suddenly shrink or grow after a deployment, which often signals a query, filter or base URL bug in the generator.

Common XML sitemap mistakes

• Listing staging or development URLs because the generator uses the wrong base URL.
• Including every filter and parameter combination, producing millions of low-value URLs.
• Setting lastmod to the request time, so every page looks changed every day.
• Forgetting new content types, such as location pages or help articles added months after launch.
• Returning HTML error pages from the sitemap URL when the generator fails, instead of an error status.
• Leaving old sitemaps submitted after a migration, still listing redirected URLs.
• Mixing hosts or protocols, such as HTTP URLs in an HTTPS sitemap, which contradicts your canonical signals.

Frequently asked questions

Want sitemaps that match your site exactly and update themselves? Our SEO services include technical audits, and our developers can build the generator.