The Sitemap Sync Fix: Why Your New SaaS Pages Aren't Showing in Search

You published a new SaaS landing page, comparison page, pricing update, or integration page. The page is live, but search engines still do not seem to see it because the sitemap is stale, cached, or generated from the wrong source.

For growth teams, this is not a minor SEO annoyance. If your sitemap is not updating, your new sales pages can miss the discovery window where buyers, AI answer engines, and search crawlers are trying to understand what your company does.

Problem Summary

A sitemap is useful only when it reflects the current set of indexable pages that matter to buyers and search engines.

When a sitemap is not updating, the usual issue is not one single failure. It is usually a sync problem between the CMS, build process, cache layer, route generation, and search console submission flow.

Raze’s practical stance is simple: do not treat the sitemap as an isolated SEO file. Treat it as part of your go-to-market publishing system. A new page is not really shipped until it is live, crawlable, linked, included in the sitemap, visible in search diagnostics, and structured clearly enough for AI/search systems to understand.

This matters more for SaaS teams than for basic brochure sites because high-intent pages often ship fast:

New feature pages after a launch.
Competitor comparison pages for active sales cycles.
Integration pages tied to partner demand.
Pricing and packaging changes.
Migration pages for buyers leaving another platform.
Technical trust pages for enterprise evaluators.

If those pages are missing from the sitemap, search engines may still find them through internal links, but discovery becomes less predictable. AI answers also depend on clean, verifiable, easy-to-cite content. In an AI-answer world, brand is your citation engine. The easier your site is to crawl, understand, compare, and cite, the more durable your visibility becomes.

For SaaS websites built on a headless CMS and custom Next.js environment, the sitemap may be generated in several places: at build time, dynamically on request, through a CMS plugin, or via a custom API route. That flexibility is useful. It also creates more places for stale data to hide.

Symptoms

The symptom usually appears as one of five patterns.

New pages are live but missing from sitemap.xml

The page loads in the browser and may even be linked from the navigation or blog. But when the team opens /sitemap.xml, the new URL is not present.

This often happens after publishing:

A new product landing page.
A pricing page variant.
A programmatic SEO page.
A comparison page.
A CMS-managed article or resource.

For example, a marketing team publishes a new example.com/compare/vendor-alternative page from a headless CMS. The page is visible because the route is dynamic. The sitemap is still generated from a cached build artifact, so the page does not appear.

The sitemap shows old URLs or outdated metadata

Sometimes the URL exists, but the sitemap contains stale lastmod data, old canonical paths, or URLs that were removed weeks ago.

That is a warning sign that the sitemap generation logic is not using the same source of truth as the website. It may be reading from a cached JSON file, an outdated CMS query, a static export, or a CDN edge response.

Search Console shows submitted URLs not discovered

The sitemap may be submitted, but the new pages do not show meaningful crawl activity. The problem might be the sitemap itself, or the page may be blocked by canonical, robots, noindex, redirects, or weak internal linking.

A sitemap is a signal. It is not a guarantee of crawling or indexing.

The sitemap updates locally but not in production

This is common in Next.js builds.

A developer tests the sitemap locally and sees the new URL. Production still serves the old sitemap. That usually points to environment-specific caching, stale deployment artifacts, a CDN issue, or a production CMS token that cannot access the new content type.

The sitemap updates after a long delay

Some platforms do not regenerate sitemaps instantly after every publish event. The Shopify Community notes that sitemap updates can be delayed when generation happens on a schedule instead of immediately after publishing.

For SaaS teams, delayed generation is acceptable only when it is understood and managed. It becomes a problem when the team assumes publishing equals search discoverability.

Likely Causes

Separate the causes before changing code. Most teams waste time resubmitting the sitemap when the real issue sits in CMS permissions, edge caching, or route generation.

Cause 1: The sitemap is generated on a schedule

Many CMS and commerce platforms rebuild sitemaps on a schedule. That means the sitemap may lag behind the publish event.

This is not always a bug. It is a design decision. The question is whether the lag is known, acceptable, and documented in your publishing process.

If new SaaS pages are time-sensitive, scheduled generation can be too slow. Launch pages, partner pages, and comparison content should enter the crawl path quickly because they support active demand.

Cause 2: The sitemap route is cached

Caching is one of the most common reasons for a sitemap not updating.

The sitemap may be cached by:

The application framework.
The hosting platform.
A CDN.
A page caching plugin.
A reverse proxy.
A browser or local test environment.

The WP Rocket documentation specifically discusses how caching behavior can affect sitemap updates. The same principle applies in custom SaaS stacks: if /sitemap.xml is cached as a static response, the CMS may be correct while the public file is still stale.

Cause 3: The CMS query excludes the new content type

Headless CMS setups often use filters such as published status, locale, content type, slug presence, or SEO visibility flags.

A new page can be live but excluded from the sitemap because:

The content type was never added to the sitemap query.
The page has includeInSitemap set to false.
The CMS status is preview, draft, archived, or unpublished in one environment.
The locale or market field does not match production filters.
The slug is missing, malformed, or duplicated.

This is especially common when marketing teams add new page templates faster than engineering updates the sitemap logic.

Cause 4: The Next.js build does not regenerate the sitemap

In static or hybrid Next.js environments, the sitemap may be generated at build time. If the build does not run after publishing content, the sitemap will stay stale.

In dynamic environments, the route may still be cached through ISR, edge caching, or a custom response header.

A typical failure looks like this:

CMS publish event fires.
The website page renders dynamically.
The sitemap was generated during the previous deployment.
No webhook triggers a rebuild or cache invalidation.
Production continues serving the old sitemap.

This is why a modular Next.js marketing stack needs operational rules, not just clean components. If your team is rethinking that architecture, the same principle applies to modular SaaS web builds: marketing speed only works when publishing, routing, SEO, and deployment stay in sync.

Cause 5: Proxy, redirect, or domain routing issues

A sitemap can be correct at the origin and stale at the public domain.

The HubSpot Community highlights proxy services and domain redirects as possible blockers when sitemap and robots.txt updates do not propagate.

For SaaS companies, this often appears after:

Moving from www to apex domain or the reverse.
Adding a CDN or proxy layer.
Migrating a marketing site from one platform to another.
Splitting app and marketing domains.
Rewriting routes at the edge.

If the wrong domain version is submitted, crawlers may see redirects, stale files, or conflicting canonical signals.

Cause 6: Cached XML files still exist on the server

Some setups store XML files on disk. If those files remain after configuration changes, the public sitemap may keep serving stale data.

A WordPress.org support thread describes a case where cached XML files in a server folder needed to be removed. The stack may differ from a custom SaaS site, but the lesson is portable: old generated files can outlive the logic that created them.

Cause 7: The page is not actually indexable

A sitemap should include only canonical, indexable URLs. If a page is excluded correctly, the issue is not the sitemap. The issue is page configuration.

Check for:

noindex tags.
Robots.txt disallow rules.
Canonical tags pointing elsewhere.
Redirect chains.
Soft 404 behavior.
Auth-gated or region-gated content.
Missing internal links.

This matters for conversion as much as SEO. A comparison page that is crawlable but not internally linked is also hard for buyers to find. Search architecture and buyer architecture overlap.

How to Diagnose

Use the four-layer sitemap sync model. It is simple enough for marketing and engineering to run together.

Content layer: Is the page published, canonical, and eligible for indexing?
Generation layer: Does the sitemap logic include that content type and URL?
Delivery layer: Is production serving the fresh sitemap, or a cached response?
Search layer: Has the correct sitemap been submitted and inspected?

Do not skip layers. Most false fixes happen when teams jump straight to resubmission before proving the public sitemap is current.

Step 1: Confirm the page is indexable

Open the page and inspect the rendered HTML.

Confirm:

The HTTP response is 200, not 301, 302, 404, or 500.
The page does not include noindex.
The canonical tag points to itself or the correct canonical URL.
The URL is not blocked by robots rules.
The page is linked from at least one crawlable internal page.

For SaaS sites, prioritize pages with business value. Pricing, comparison, integration, and migration pages should not be hidden in orphaned URL structures. If pricing is part of the issue, Raze has covered how pricing pages should reduce buyer effort in SaaS pricing UX, and the same logic applies to crawl paths: make important decisions easier to reach.

Step 2: Compare local, preview, origin, and production sitemap output

Check the sitemap in four places:

Local development.
Preview deployment.
Origin server if accessible.
Public production URL.

If local and preview are correct but production is stale, the issue is probably deployment, environment variables, CDN cache, or proxy behavior.

If local is wrong, the issue is likely the sitemap generation logic or CMS query.

If production is correct but search diagnostics are stale, the issue may be search processing, submitted sitemap location, or page quality signals.

Step 3: Inspect the sitemap generation code

For a custom Next.js stack, find where the sitemap is generated.

Common patterns include:

A static public/sitemap.xml file.
A build-time script such as generate-sitemap.
A dynamic route such as /sitemap.xml/route.ts.
A server-side function that queries the CMS.
A plugin or package that reads route files.

Look for exclusions that no longer match the site:

Hardcoded route lists.
Missing content types.
Old slug fields.
Locale filters.
Preview-only tokens.
Draft status filters.
Incorrect base URL variables.

A strong SaaS web design agency should not stop at the page template. The sitemap, page model, and content architecture need to support conversion and discoverability together.

Step 4: Check cache headers and CDN behavior

Request the sitemap and inspect response headers.

Look for:

Long cache lifetime.
CDN cache hit status.
Stale deployment IDs.
Incorrect content type.
Redirects before the XML response.

If your sitemap route is dynamic but the CDN caches it for too long, content changes will not appear when expected. If the sitemap is build-time generated, cache purging alone will not help unless the underlying file is rebuilt.

Step 5: Confirm the submitted sitemap path

Manual sitemap updates usually require generating a new file and submitting it through Search Console. Slickplan describes the basic workflow as generating the sitemap from the CMS or sitemap generator, then resubmitting it in Google Search Console.

For SaaS teams, the important detail is path accuracy. Confirm the submitted sitemap matches the canonical production domain and protocol.

Common mistakes:

Submitting http when the canonical site uses https.
Submitting apex when the site uses www.
Submitting an old platform sitemap after migration.
Submitting a sitemap index that does not include the new child sitemap.
Submitting a staging sitemap by accident.

Fix Steps

Do not do random sitemap resubmissions. Fix the sync chain, then resubmit once the public file is correct.

Step 1: Rebuild or regenerate the sitemap from the correct source

If the sitemap is static, regenerate it from the current CMS and route source.

If the sitemap is dynamic, make sure the route queries the live production CMS data and includes every indexable content type.

A clean sitemap generation rule should include:

Published pages only.
Canonical URLs only.
No auth-gated pages.
No filtered, parameterized, or duplicate routes.
Important GTM pages such as features, pricing, comparisons, integrations, migrations, resources, and trust pages.

Do not include everything just to be safe. A bloated sitemap sends poor signals about what matters. For a SaaS site, the sitemap should reflect a clear sales argument, not a dumping ground for every route.

Step 2: Purge the sitemap cache at every layer

If caching is involved, purge in the right order:

Application cache.
Sitemap generation cache.
Hosting cache.
CDN or proxy cache.
Browser cache for testing only.

The Yoast documentation recommends disabling the sitemap feature, clearing the cache, and enabling the feature again to force a sitemap rebuild in that environment. In a custom Next.js environment, the equivalent is to invalidate the sitemap route or generated file, clear the cache, and regenerate from the current content source.

The tradeoff is speed versus control. Aggressive caching improves performance. But SEO-critical files such as sitemaps and robots.txt need a refresh policy that matches publishing velocity.

Step 3: Trigger a production rebuild when CMS content changes

If the sitemap is generated at build time, connect the CMS publish event to the deployment process.

A practical setup:

CMS publish event triggers a webhook.
Webhook starts a production rebuild or sitemap regeneration job.
Build pulls the latest published content.
Sitemap file is written or route cache is invalidated.
CDN cache for /sitemap.xml is purged.
Team verifies the public sitemap before submitting.

This keeps marketing from depending on engineering for every content update while still protecting technical quality.

Step 4: Fix Next.js route behavior

For dynamic sitemap routes, confirm the route is not accidentally static.

Check whether the route:

Uses cached fetch behavior.
Runs only at build time.
Uses stale revalidation settings.
Reads from environment variables that differ between preview and production.
Returns the correct XML content type.
Handles pagination or sitemap indexes when URL volume grows.

A sitemap route should be boring, predictable, and observable. If nobody can explain when it updates, it is not production-ready.

Step 5: Remove stale generated XML files

If old XML files exist in the public directory, uploads folder, static export, or server storage, remove them after confirming the current generator is correct.

This is common after migrations from WordPress, Webflow, Squarespace, HubSpot, or a static-site generator into a Next.js frontend. The new site may serve one sitemap path while the old file still exists on another path.

After removal, request each known sitemap URL and confirm the behavior:

Current sitemap returns 200.
Old sitemap redirects to the current sitemap or returns an intentional status.
Sitemap index includes the correct child sitemaps.
No staging, preview, or deprecated URLs remain.

Step 6: Resubmit only after the public sitemap is correct

Once the production sitemap is accurate, resubmit it.

Resubmission is not the fix. It is the final notification step.

For SaaS launches, create a release checklist that includes sitemap verification. This is especially important when launching pages that affect pipeline, such as demo pages, ROI tools, comparison pages, and product sandboxes. If buyers self-evaluate before sales, your page architecture needs to support that behavior. Raze has written about this in the context of product sandbox UX, where discoverability and evaluation quality both affect conversion.

A realistic mini case: CMS page live, sitemap stale

Baseline: A B2B SaaS team publishes three new integration pages from a headless CMS. The pages load in production, but none appear in /sitemap.xml. Search diagnostics show the sitemap was fetched, but the new URLs are absent.

Intervention: The team finds the sitemap route only queries resource and page content types. The new integration content type is missing. Engineering adds the content type to the sitemap query, purges the route cache, and adds a CMS publish webhook that revalidates the sitemap route.

Expected outcome: The public sitemap reflects the new integration URLs after the next publish workflow, and the marketing team can verify the URL presence before submitting the sitemap. The timeframe is one sprint if the CMS model and deployment permissions are already clear.

Measurement plan: Track sitemap URL presence, production response status, submitted sitemap status, crawl discovery, impressions for the new URL set, and assisted demo or signup paths from those pages. Do not claim a ranking lift from the sitemap change alone. The goal is to remove a discovery blocker and make the page eligible for search and AI-answer workflows.

How to Verify the Fix

Verification needs to happen in the public production environment, not only in local development.

Confirm the URL appears in the live sitemap

Open the public sitemap in a clean browser session or via command line. Search for the exact canonical URL.

Verify:

The URL appears once.
The URL uses the canonical domain.
The URL uses the correct protocol.
The URL is not duplicated across multiple sitemap files.
The URL does not redirect.

If the sitemap is split into multiple files, check the sitemap index and the child sitemap that should contain the new page.

Confirm the page and sitemap agree

The sitemap, canonical tag, internal links, and robots rules should tell the same story.

For each new SaaS page, verify:

Sitemap includes the canonical URL.
Page canonical matches the sitemap URL.
Page is not noindex.
Robots rules allow crawling.
Internal links point to the canonical URL.
The page content is not a thin duplicate of another page.

Trust is not just visual design. It is consistency across signals. If your brand looks enterprise-ready but your technical signals conflict, you create buyer and crawler friction. That is why brand trust, content architecture, and technical SEO need to move together, especially after a Series A or major GTM shift. The same pattern applies to enterprise trust cues on the visible side of the site.

Confirm the sitemap refresh process works after another publish

Do one more controlled test.

Publish a low-risk test page or update a legitimate page that should appear in the sitemap. Then run the full workflow:

Publish in CMS.
Trigger rebuild or revalidation.
Purge relevant cache.
Check production sitemap.
Confirm search submission path.
Document the expected timing.

The goal is not just to fix one page. The goal is to make future GTM publishing reliable.

Confirm search systems can discover the page

After the sitemap is correct, inspect the page in search tooling and monitor whether search systems discover it.

Do not over-read short-term indexing behavior. Search engines make their own crawl and indexing decisions. Your job is to remove avoidable blockers: stale sitemap, blocked page, weak internal links, incorrect canonical, poor content depth, and conflicting domain signals.

For AI answer visibility, also check whether the page clearly states what the product does, who it is for, how it compares, and what evidence supports the claim. AI answers pull from sources that feel trustworthy and uniquely useful. A page that is technically discoverable but vague is still hard to cite.

When to Escalate

Escalate when the issue repeats after basic fixes or when the affected pages are tied to pipeline.

Escalate to engineering when the sync chain is unclear

Bring engineering in when:

The sitemap generation source is unknown.
Production and preview behave differently.
CDN or proxy cache is involved.
CMS webhooks are failing.
Next.js route behavior is inconsistent.
The sitemap is generated during deployment and marketing publishes daily.

This is not a marketing-only problem. It sits between SEO, CMS architecture, deployment, and application delivery.

Escalate to SEO or growth when the sitemap is correct but pages still underperform

If the sitemap is current and pages still do not gain impressions, the issue may be content quality, internal linking, search intent mismatch, technical duplication, or weak authority.

At that point, do not keep poking the sitemap. Review the page as a sales asset:

Does the page answer a real buyer question?
Is the positioning clear in the first screen?
Does the page create enough comparison value to be cited?
Are proof, use cases, and trust signals specific?
Is there a clear next step toward demo, signup, or evaluation?

Traffic does not fix unclear positioning. It exposes it.

Escalate to a specialist when the website blocks GTM speed

If every new page requires engineering intervention, your marketing site is slowing the company down.

That is when a SaaS web design agency, AI SEO agency, AEO agency, or embedded design/growth team can help. The work is not just redesigning pages. It is building a publishing system where positioning, conversion, SEO, AEO, CMS modeling, and front-end delivery reinforce each other.

Raze typically looks at the whole chain: page architecture, CMS structure, sitemap generation, internal linking, conversion paths, technical trust, and AI/search readability. The aim is faster shipping without creating technical debt that hides your best pages from buyers.

FAQ

Why is my sitemap not updating after I publish a new page?

Your sitemap may be generated on a schedule, cached at the application or CDN layer, or built from a CMS query that excludes the new page. In custom Next.js and headless CMS setups, the live page and sitemap often use different generation paths, so one can update while the other stays stale.

Does resubmitting the sitemap fix the problem?

Resubmitting helps only after the public sitemap is correct. If the sitemap still serves stale URLs, resubmission just asks search systems to recheck the wrong file.

How do I force a sitemap rebuild in a custom SaaS stack?

Regenerate the sitemap from the current production CMS data, purge the sitemap route or file cache, and confirm the public /sitemap.xml output has changed. If the sitemap is generated at build time, trigger a production rebuild or add a CMS webhook that handles regeneration.

Why does the sitemap update locally but not in production?

Local development may use fresh CMS data while production serves cached output, static build artifacts, or a different environment configuration. Compare local, preview, origin, and public production outputs to isolate the layer that is stale.

Should every SaaS page be included in the sitemap?

No. Include canonical, indexable pages that matter for discovery and buyer evaluation. Exclude duplicate, gated, filtered, parameterized, thin, or intentionally private routes.

Can a stale sitemap hurt AI search visibility?

A stale sitemap can delay discovery of pages that AI and search systems may use to understand, compare, and cite your company. It is not the only factor, but it is a preventable blocker in the path from impression to AI answer inclusion, citation, click, and conversion.

If your SaaS site keeps shipping pages that buyers and search systems cannot reliably find, Raze can help audit the publishing chain, sitemap logic, conversion paths, and AI/search visibility. Book a working session with Raze to find the leak and fix it properly.