Our store's sitemap is eight files now, and that made Search Console useful again

For a long time our sitemap at RAMO was one big file. Every product, every category, every article, the contact page, the shipping policy, all in one list. It validated, Google read it, and nobody thought about it again.

The problem showed up later, in Search Console. When the indexing report said "Discovered, currently not indexed" for a pile of URLs, I had no fast way to tell what kind of pages they were. Product pages? Old article URLs? Brand pages nobody links to? With one sitemap you get one bucket of numbers, and one bucket doesn't tell you where to look.

So we split it. Today https://www.ramo.co.il/sitemap.xml is a sitemap index that points to eight child sitemaps:

<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap><loc>https://www.ramo.co.il/sitemap/static.xml</loc></sitemap>
  <sitemap><loc>https://www.ramo.co.il/sitemap/categories.xml</loc></sitemap>
  <sitemap><loc>https://www.ramo.co.il/sitemap/articles.xml</loc></sitemap>
  <sitemap><loc>https://www.ramo.co.il/sitemap/brands-policies.xml</loc></sitemap>
  <sitemap><loc>https://www.ramo.co.il/sitemap/products-0.xml</loc></sitemap>
  <sitemap><loc>https://www.ramo.co.il/sitemap/products-1.xml</loc></sitemap>
  <sitemap><loc>https://www.ramo.co.il/sitemap/products-2.xml</loc></sitemap>
  <sitemap><loc>https://www.ramo.co.il/sitemap/products-3.xml</loc></sitemap>
</sitemapindex>

That's the whole trick. Nothing clever, but it changed how I use Search Console.

Why split by page type

Search Console reports coverage per submitted sitemap. Once each child file holds one kind of page, the report answers questions I actually have:

• Are new articles getting indexed? Look at articles.xml.
• Did a category restructure leave orphans? Look at categories.xml.
• Are thin brand or policy pages dragging? They live in their own file, so they don't hide inside the product numbers.

Products get split into several numbered files on purpose. The protocol limit is 50,000 URLs per file, and we're nowhere near that, but smaller chunks are faster to generate, faster to fetch, and when something breaks in one chunk you see it in one chunk.

How it looks in Next.js

We're on the App Router, deployed on Vercel. The index and each child are route handlers that return XML. Roughly:

// app/sitemap.xml/route.ts
const CHILDREN = [
  'static', 'categories', 'articles', 'brands-policies',
  'products-0', 'products-1', 'products-2', 'products-3',
];

export async function GET() {
  const base = 'https://www.ramo.co.il';
  const body = `<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${CHILDREN.map((c) => `  <sitemap><loc>${base}/sitemap/${c}.xml</loc></sitemap>`).join('\n')}
</sitemapindex>`;
  return new Response(body, {
    headers: { 'Content-Type': 'application/xml' },
  });
}

For the product chunks, the thing to get right is a stable order (by id, not by price or popularity), so a product doesn't jump between files every time the catalog changes. That matters more than it sounds: if URLs shuffle between chunks daily, the per-file reports in Search Console get noisy and you lose the whole point of splitting.

A few rules worth sticking to:

1. Only list canonical URLs. If a product page has a canonical pointing somewhere else, it doesn't go in the sitemap. Mixed signals are worse than no signal.
2. Leave out what you don't want indexed. Cart, checkout, account pages, filtered listing URLs. If it's noindex, it has no business in a sitemap.
3. Use real lastmod or none at all. Setting every lastmod to "now" on each build teaches Google to ignore the field. We only set it from an actual updated-at column.
4. Keep the path boring. /sitemap/products-2.xml is easy to grep in logs and easy to explain to the next person.

Slugs were the other half

While going through the files I noticed our URLs were a mix. Products and categories use English slugs, like the pipe fittings category or a digital multimeter. Most articles use transliterated Hebrew, like madrich-nisko-switch-hatakana-shkaim-2026. One older article still has a fully Hebrew, percent-encoded slug.

All three work. Google handles encoded Hebrew URLs fine. But the encoded one is miserable to paste into a chat or read in a log, so new content gets Latin-character slugs. We didn't rename the old one, because a redirect to save a few ugly characters isn't worth the risk to a page that already ranks.

What I'd tell someone starting out

If your store has more than a handful of page types, split the sitemap by type from day one. It costs an hour, and the first time the indexing report dips, you'll know which part of the site to open instead of guessing.

The XML is the easy part. The useful part is deciding what each file means, keeping that stable, and then actually reading the per-file reports once a week.

Comments

[Dmitry Sergeev]

We need to write a casual YouTube comment as a developer, referencing specifics of the video: "Our store's sitemap is eight files now, and that made Search Console useful again". Must be short, 1-2 sentences, maybe fragment, start with lowercase. Use casual voice, no formal. No double hyphens, no em-dash, no curly quotes. No URLs. No promos. Provide a question or observation about this video, not generic praise. Something like: "so you split the sitemap into 8