The crawling and indexing guide in this section covers the basic XML sitemap: what it is, what it's for and the general quality rules. This guide focuses on what's needed once a single file isn't enough: sites with more URLs than one sitemap can hold, or with content types (images, video, news) that have their own specialized sitemap format with their own required fields.
The limit that forces a sitemap index: 50,000 URLs or 50 MB
A single XML sitemap can't exceed 50,000 URLs or 50 MB uncompressed, whichever comes first. On truly large sites (an ecommerce with tens of thousands of SKUs, a news outlet with years of archive) it's common to hit that limit by URL count long before hitting it by file weight. The fix isn't truncating the sitemap but splitting it into several child files and declaring a sitemap index, a separate file whose only job is to list the location of each child sitemap:
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://www.yourdomain.com/sitemap-products.xml</loc>
<lastmod>2032-02-15</lastmod>
</sitemap>
<sitemap>
<loc>https://www.yourdomain.com/sitemap-blog.xml</loc>
<lastmod>2032-02-10</lastmod>
</sitemap>
</sitemapindex>The sitemap index is declared in robots.txt and submitted in Search Console exactly like a regular sitemap; the difference is that Google processes it as an index of indexes, entering each child sitemap separately. Each child sitemap in turn still has its own 50,000-URL / 50 MB limit, and a sitemap index can itself point to up to 50,000 child sitemaps, a ceiling almost no site in practice ever comes close to.
Image sitemaps: helping Google discover images that have no indexable URL of their own
An image usually doesn't have its own indexable URL in the sense an HTML page does; it lives embedded inside the HTML of a product or article page. The image extension of the sitemap protocol lets you declare, inside each <url> entry of the sitemap, one or more images associated with that page, which helps Google discover and associate them correctly even if they're lazy-loaded or loaded via JavaScript in a way that makes them harder to detect during a normal crawl:
<url>
<loc>https://www.yourdomain.com/products/nordic-chair</loc>
<image:image>
<image:loc>https://www.yourdomain.com/img/nordic-chair-1.webp</image:loc>
<image:title>Nordic oak chair</image:title>
</image:image>
<image:image>
<image:loc>https://www.yourdomain.com/img/nordic-chair-2.webp</image:loc>
</image:image>
</url>The only strictly required field per image is image:loc; image:title and other optional fields (like a license or a geolocation) add context but aren't a requirement. A single <url> can include several images if the page shows a gallery, and there's no need for an image sitemap separate from the main sitemap: the extension is added inside the same file.
Video sitemaps: required fields that actually matter
Unlike the image sitemap, the video one requires several mandatory fields because Google uses them directly to build the video rich result in search (thumbnail, duration, publication date):
<url>
<loc>https://www.yourdomain.com/blog/how-to-assemble-the-chair</loc>
<video:video>
<video:thumbnail_loc>https://www.yourdomain.com/img/thumb-assembly.jpg</video:thumbnail_loc>
<video:title>How to assemble the Nordic chair in 3 minutes</video:title>
<video:description>A step-by-step tool-free assembly guide.</video:description>
<video:content_loc>https://www.yourdomain.com/video/assembly.mp4</video:content_loc>
<video:duration>180</video:duration>
<video:publication_date>2032-01-20T10:00:00+01:00</video:publication_date>
</video:video>
</url>video:thumbnail_loc, video:title and video:description are mandatory in every case; you also need either video:content_loc (the direct URL of the video file) or video:player_loc (the URL of an embedded player) depending on how the video is served. video:duration is declared in seconds and has a bounded valid range (between 1 second and 28,800 seconds, eight hours); a value outside that range invalidates the entry. Video hosted on external platforms (YouTube, Vimeo) generally already generates its own video sitemap automatically, so this extension is more relevant for self-hosted video.
News sitemaps: the recency requirement that changes everything
The news sitemap has a restriction no other type has: it should only include articles published in the last 48 hours. Past that window, the article must be removed from the news sitemap (even though it remains perfectly indexable and visible on the site through the regular sitemap), because this sitemap type is specifically designed to feed Google News and featured news sections, contexts where content recency is the dominant signal:
<url>
<loc>https://www.yourdomain.com/news/product-launch</loc>
<news:news>
<news:publication>
<news:name>Publication name</news:name>
<news:language>en</news:language>
</news:publication>
<news:publication_date>2032-02-18T09:00:00+01:00</news:publication_date>
<news:title>Exact article title</news:title>
</news:news>
</url>This requires a kind of news-sitemap upkeep no other type needs: it isn't enough to generate it once and regenerate it on a routine schedule, it has to automatically purge any entry past 48 hours on every regeneration, usually via a scheduled process that runs far more often than a regular sitemap's regeneration (several times a day, not once a week). A site that publishes frequently and neglects this purge ends up with a news sitemap bloated with articles already stale for that purpose, which doesn't produce a technical error but does dilute the recency signal this sitemap exists to convey.
Splitting strategy on very large sites: by type, by date or by section
When a sitemap index with many child sitemaps is needed, the splitting criterion matters as much as the fact of splitting itself. Splitting by content type (one sitemap for products, another for categories, another for the blog) is the most common approach and makes Search Console diagnostics easier, since each child sitemap can be reviewed separately and an indexing problem is immediately localized to the affected content type. Splitting by date (one sitemap per year or month of publication) is common on editorial content sites with a lot of archive, since it lets recent content (which benefits from more frequent crawling) be treated differently from older, already-stable content. Splitting by business section or category (fashion, home, electronics on an ecommerce site) is more common on very large catalogs where the volume of a single content type (all products) already comfortably exceeds the 50,000-URL limit on its own and needs subdividing regardless. All three strategies are compatible with each other and are often combined on very large sites.
Monitoring sitemap health in Search Console: the gap between submitted and indexed
For every submitted sitemap, Search Console shows how many URLs were discovered in it and how many of those are actually indexed. A small, stable gap between the two figures is normal (Google always discards a percentage of URLs for legitimate reasons: near-duplicates, low value, or pending an upcoming crawl visit). A gap that grows over time, or that suddenly appears in one specific child sitemap, is the most reliable signal of a real problem worth investigating: it could be a new template generating near-duplicate content en masse, a sitemap that started including non-canonical or redirected URLs by mistake, or an entire section that lost crawl priority due to low-quality signals. Reviewing this report regularly, child sitemap by child sitemap rather than just the site's total aggregate, is what lets you catch that kind of problem in a specific section before it spreads to the rest of the site.
Frequently asked questions
Do I need a sitemap index if my site has fewer than 50,000 URLs?
It isn't mandatory, but splitting by content type can still be useful even below the limit, simply to be able to monitor each section separately in Search Console instead of having a single aggregated report for the whole site.
Does a video hosted on YouTube need me to generate its own video sitemap?
Usually not: YouTube and other major video platforms already generate and maintain their own video sitemap for content hosted on their domain. The video extension in your own sitemap matters mainly for video self-hosted on your own server.
What happens if a news article stays in the sitemap past 48 hours?
It doesn't produce a technical error or penalize the article, which remains normally indexable through the general sitemap. It simply stops providing the specific recency signal Google News uses to prioritize recent content, so the article loses that particular advantage without losing its general indexing.
How often should I review the sitemaps report in Search Console?
As a reasonable reference, a monthly review of the gap between submitted and indexed URLs per child sitemap is enough for most sites; on sites that publish very frequently or depend on recency (news, offers), it's worth reviewing weekly.