Sitemaps for Large Healthcare Sites: Splitting by Template and Using lastmod Honestly

This post is for the marketing or SEO owner of a large hospital or health-network website with thousands of URLs: doctor profiles, condition pages, treatment pages, location pages, blog posts and perhaps news or PDFs. The question is how to build XML sitemaps that help you manage indexation, rather than a single flat file that only tells Google your URLs exist.

A sitemap does not make Google index anything. What it does is give you a list of the URLs you consider important and a lever for measurement. When you split sitemaps by page type, Search Console shows how many URLs of each type were submitted and how many ended up indexed, so you can tell which template has a problem. That measurement is the reason to bother.

The second half of the post is about lastmod, the field most often filled in dishonestly, by a CMS that stamps every URL with today's date on every build.

What Google says about sitemaps

Google's guidance on building a sitemap gives the technical limits and the rules that matter:

• A sitemap file is limited to 50MB uncompressed or 50,000 URLs. Larger sites must split into multiple files, and a sitemap index file lets you submit one file that lists them.
• Google uses lastmod only if it is consistently and verifiably accurate, for example when it matches the page's actual last modification. It should reflect the last significant update.
• Google ignores priority and changefreq.
• List the canonical URLs you want indexed. Google still decides which pages are duplicates.

Google's separate page on consolidating duplicate URLs treats sitemap inclusion as a weak canonical signal, weaker than redirects and the canonical tag. So the sitemap supports your other signals. It does not replace them.

Why split by template

A large healthcare site contains page types with very different behaviour. Doctor profiles change with staffing. Condition pages change with clinical review. Location pages change with opening hours and service lists. Blog posts accumulate and rarely change. If all of these sit in one sitemap, Search Console reports a single submitted-versus-indexed figure, and a problem in one template hides behind the others.

If each template has its own sitemap file, listed in a sitemap index, you can open the sitemap report or the page indexing report, filter by sitemap, and read the number of URLs submitted and indexed for that file. A drop in one file points directly at the template.

A sensible structure for a hospital group:

If any one list exceeds 50,000 URLs or 50MB, split it further, for example by year or by numerical range, and keep a naming convention so the file still identifies the template.

Name files after the template, not the date, so reports stay comparable across months.

What belongs in the sitemap, and what does not

Include URLs that return 200, are indexable, and are the canonical version. Exclude:

• URLs that redirect, return 404 or 410, or are blocked by robots.txt.
• Pages with noindex.
• Non-canonical variants (parameters, print versions, sorted lists).
• Paginated archive pages, unless you have a specific reason.
• Staging, preview or internal URLs.
• Thank-you and confirmation pages.

A sitemap that mixes in these URLs undermines the measurement. A rising "submitted" count full of redirects produces an indexed ratio that tells you nothing. A clean sitemap lets the ratio mean something: ideally the URLs you submit are the URLs you want indexed, so a gap is a diagnostic.

Reading the indexed-versus-submitted ratio

This is a method for your own site; we are not reporting figures from any client. For each sitemap file:

1. Note the submitted count from your own generation script (do not rely on the Search Console figure alone).
2. In Search Console, open the page indexing report and choose the sitemap as the filter. Note the number of indexed pages and the breakdown of non-indexed reasons.
3. Compute the ratio of indexed to submitted for each template.
4. Read the reasons: "Crawled, currently not indexed", "Discovered, currently not indexed", "Duplicate, Google chose different canonical", "Soft 404", "Page with redirect", "Blocked by robots.txt".
5. Compare templates. A template whose ratio is clearly lower than the others, or whose non-indexed reasons cluster in one category, is where to investigate first.
6. Repeat monthly and record the trend.

How to interpret the common patterns:

• "Discovered, currently not indexed" high on a template. Google knows the URL but has not crawled it. Check internal links, server speed and overall crawl demand.
• "Crawled, currently not indexed" high. Google fetched the page and chose not to index it. Look at content quality, duplication and whether the page adds anything beyond similar pages.
• "Duplicate, Google chose different canonical." Your canonical logic and Google's disagree. Inspect samples.
• "Page with redirect" in a sitemap. The generator is listing old URLs. Fix it.
• Low ratio on doctor profiles only. Look at rendering and thin content. Our post on server-side and client-side rendering tests covers how to check what Google receives.

The ratio is a diagnostic, not a target. A low ratio on a template of deliberately thin pages may be the correct outcome.

Using lastmod honestly

lastmod tells crawlers when a page last changed in a way that matters. It can help Google prioritise recrawls, but only if it is believed. Google's guidance says it uses the value only if it is consistently and verifiably accurate. A site that sets lastmod to the build date for all URLs teaches Google that the field is noise.

What counts as significant. Google's documentation says changes to the main content, structured data or links usually count, while a copyright-date change usually does not. For a healthcare site, that gives a practical rule set:

Do update lastmod when:

• A clinician reviews and changes the clinical text of a condition or treatment page.
• A doctor's profile changes: new qualifications, new location, new consultation days.
• A location's address, hours, phone number or service list changes.
• A blog post is materially revised, with the revision noted on the page.
• Structured data or key internal links change.

Do not update lastmod when:

• The site is rebuilt or redeployed.
• The footer, header, cookie banner or a sitewide script changes.
• A related-posts widget changes order.
• A page is re-saved without content change.
• A copyright year or an unrelated date changes.

How to implement it

Store a dedicated "content last modified" field in the CMS, set by editorial action, not by the system's updated-at timestamp. Where that is not possible, compute a hash of the main content, structured data and meaningful links, and update the stored date only when the hash changes. Then generate the sitemap from that stored date.

Align the visible date. If a page shows "Last reviewed on" for medical content, tie it to the same field so the page, the sitemap and the structured data agree. The review date should reflect an actual clinical review, not an automated refresh, and the reviewer should be named internally.

Test it

Pick ten URLs. Make a trivial change, such as a footer edit, and confirm lastmod does not change. Make a real content edit and confirm it does. Do the same after a full deployment. If every date moves, the generator is using the wrong source.

Operational details

• Reference the index in robots.txt with a Sitemap: line, and submit it in Search Console.
• Use absolute, canonical URLs with the same protocol and host as your canonical tags.
• Encode properly. Special characters, including Arabic or other non-ASCII paths, should be correctly encoded.
• Generate dynamically or on publish. A static file edited by hand will go stale. Regenerate on publish and unpublish events, and remove deleted doctors immediately.
• Compress large files with gzip if your server supports it; the 50MB limit applies to the uncompressed size.
• Keep hreflang in sitemaps consistent if you use that method; see our post on hreflang for India, UAE and Arabic versions for the rules.
• Monitor the sitemap report for fetch errors and parsing errors.

Where to start

1. Inventory page types on the site and the URL counts for each.
2. Define the rule for what is in or out of a sitemap for each type.
3. Generate one file per type, plus an index, from the publishing system.
4. Replace build-date lastmod with a content-modified field.
5. Submit the index, then record baseline submitted and indexed counts for each file.
6. Review monthly and investigate the lowest-performing template first.

For ongoing indexation reporting, our SEO reporting and analytics service covers how we track it, and the technical SEO audit includes a sitemap review. Condition and treatment templates are covered in condition and treatment SEO. The healthcare SEO checklist is a useful companion.