PHP Sitemap Index Generator: 5 Steps to Get Lastmod Right

Hey! If your site has grown past one tidy sitemap.xml file, or you're already running separate sitemaps for posts, pages, and images, this one's for you.

A PHP sitemap index generator sounds like a small addition once you already have real sitemap files, right up until Google quietly stops trusting the dates inside them. Built correctly it points search engines to every sitemap you actually have. Built carelessly, the one signal meant to tell Google what changed recently gets ignored completely, with nothing in Search Console ever telling you that happened.

A single sitemap file has a real ceiling: per the sitemap protocol that Google, Bing, and every other search engine follow, one sitemap can list at most 50,000 URLs and must stay under 50 KB per URL, adding up to a real 50 MB uncompressed size limit. The sitemap protocol's own documented limits apply whether you hit the ceiling from URL count or from unusually long URLs and rich attributes.

A sitemap index file is the fix: instead of one file, you generate several smaller ones and list them inside a single index file using the real sitemapindex root tag. Per Google's own documentation, a sitemap index can reference up to 50,000 individual sitemaps, and every sitemap it lists has to live in the same directory as the index file or somewhere lower in the site hierarchy, never a different path entirely.

Search Engine Land's own sitemap guide makes the practical case well: as a site grows, maintaining one enormous file becomes fragile, one bad URL or a single slow database query can break the whole thing, while several smaller files behind one index isolate that risk to a single file instead of the entire site's crawl signals. That's the real operational reason a growing site reaches for this pattern long before it technically hits the URL ceiling.

The genuinely useful case for a PHP sitemap index generator isn't just splitting one huge sitemap by URL count, it's organizing several genuinely different sitemap files, posts, pages, and images being a common real split, under one index a search engine only has to fetch once. Yoast SEO's own documentation confirms this is exactly how a major, widely used real WordPress plugin structures its own sitemap index, referencing separate sitemaps for posts, pages, authors, categories, and tags rather than one combined file.

Here's a real function generating that structure from an array of sitemap entries, run straight from the PHP command line:

buildSitemapIndex([
  ['loc' => 'https://brandella.in/sitemaps/posts.xml', 'lastmod' => '2026-09-01T10:15:00+00:00'],
  ['loc' => 'https://brandella.in/sitemaps/pages.xml', 'lastmod' => '2026-08-30T09:00:00+00:00'],
  ['loc' => 'https://brandella.in/sitemaps/images.xml', 'lastmod' => '2026-08-28T14:22:00+00:00'],
])
// -> a real <sitemapindex> XML document with 3 <sitemap> entries, one per file

That output is a genuinely valid, minimal sitemap index, nothing more than three files listed with a location and a modification date each, which is all the format actually requires.

A real production PHP sitemap index generator usually pulls that array from somewhere other than a hard coded list, a database table tracking each generated sitemap file, or a directory scan filtered to real .xml and .xml.gz files. Either source works, as long as the same builder function validates every entry the same way regardless of where the array came from, so a bad row in a database can't produce broken output any more easily than a bad hand written array would.

This is the gotcha most PHP sitemap index generator tutorials skip entirely: the lastmod date is optional in the specification, but the moment you include it, Google holds it to a real standard. Per Google's own documentation, lastmod is only used "if it's consistently and verifiably accurate," checked against the page's actual modification date.

That "binary trust" detail matters more than it sounds. It isn't a minor styling nitpick, since lastmod is one of the few real signals a site can use to hint which pages changed recently and deserve a fresh crawl sooner. Losing that signal across an entire sitemap because a handful of entries were stale or hand typed means every genuinely fresh page in that file loses its chance at faster recrawling too, not just the pages with bad dates.

The fix a PHP sitemap index generator can enforce directly: never type a lastmod value by hand. Read it straight off the actual file on disk instead.

function realLastmodFromFile(string $path): string
{
    if (!file_exists($path)) {
        throw new InvalidArgumentException("Cannot read a real lastmod, file does not exist: $path");
    }
    return date(DATE_W3C, filemtime($path));
}

A second, real check catches the other common mistake: a malformed date that isn't even valid in the first place.

buildSitemapIndex([['loc' => '...', 'lastmod' => '07/16/2026']])
// -> InvalidArgumentException: Invalid lastmod value, not real W3C datetime format

Per Google's own documentation, a sitemap index cannot list more than 50,000 individual sitemaps, the same style of hard ceiling as the 50,000 URL limit on each individual sitemap. A PHP sitemap index generator that reads its file list from a database or a directory scan should check this limit explicitly rather than assuming it will never be reached:

if (count($sitemaps) > MAX_SITEMAPS_PER_INDEX) {
    throw new InvalidArgumentException(
        'A sitemap index cannot list more than ' . MAX_SITEMAPS_PER_INDEX . ' sitemaps, got ' . count($sitemaps)
    );
}

Five real test cases against this exact builder function, run through the PHP command line rather than assumed to work: a standard three file index, a genuine rejection at 50,001 sitemaps, a genuine rejection of a malformed lastmod string, a real lastmod value pulled straight off an actual file's own modification time, and a real gzip round trip that decodes back to the exact original XML. All five pass against the real function, not a simulation of one.

Testing the limit at exactly 50,001 rather than some smaller stand in number matters here too. A test written against an arbitrary smaller threshold, say 10 or 100, would pass cleanly while quietly proving nothing about the actual real ceiling the specification defines, so this test suite generates the genuine boundary condition every time it runs.

Per PHP's own manual for the gzencode function, a single real function call compresses a sitemap index into the gzip format search engines already know how to decompress, and per Bing's own webmaster documentation, a compressed sitemap still has to stay under the real 50 MB limit once decompressed, gzip only reduces what travels over the network.

header('Content-Encoding: gzip');
echo gzencode($xml, 9);

Per MDN's own reference for the Content-Encoding header, that header is what tells a client the body was compressed and how, so a real client decompresses it automatically rather than receiving raw compressed bytes it doesn't know what to do with. Leaving that header off while still sending compressed bytes is a real, easy mistake that breaks the response for anything that doesn't guess the encoding on its own.

Here's that exact real endpoint proven against a real running PHP server, first serving the plain XML with real lastmod values read off three actual files, then the gzip compressed version:

The real lastmod values come straight off each file's own modification time, not a hand typed guess.

The gzip compressed response decodes back to the identical original XML content.

If you're splitting one already large sitemap purely because it crossed the URL count ceiling, our guide to large scale XML sitemaps and index files in PHP covers that specific chunking problem in depth. This article's focus is different on purpose: organizing genuinely separate sitemap types under one index, with lastmod values a PHP sitemap index generator can actually prove are accurate, rather than splitting a single content type by count alone.

Once the index file exists, two real places need to know about it. Your dynamic robots.txt PHP script should list it on its own Sitemap: line, and Search Console's own Sitemaps report needs only the index URL submitted, never every individual sitemap file one at a time.

Worth checking too: the same directory rule from section 01 applies just as strictly to a real deployment as it does on paper. A sitemap index served from the site root that lists a sitemap living on a completely different subdomain will genuinely be rejected, even though the file itself is perfectly valid XML. Keeping every generated file, index included, under one predictable real path avoids that entirely.

Every real mistake covered so far comes back to the same handful of habits a working PHP sitemap index generator needs to get right, so here they are together as one checklist worth running through before this ever reaches production.

For the surrounding pieces this pairs naturally with, building an XML sitemap generator in PHP and the IndexNow API in PHP are worth reading alongside this one, and creating a dynamic robots.txt in PHP covers exactly where this index file gets referenced for crawlers that check there first.