How do you keep SEO through a CMS migration to Sanity?

Do you have to change URLs when you move to Sanity?

No: a move to Sanity can keep every URL exactly as it was, because Sanity stores the path in a slug field and your front end builds the URL from it. Sanity's redirect guide describes that split: in a headless setup the front end and the CMS (content management system) "become decoupled" (Sanity Docs, Managing redirects, October 2026).

Keeping URLs fixed is the lower-risk move. Google says to plan site changes "one after the other, not everything at the same time", and names a domain, a CMS and a layout as separate changes (Google Search Central, October 2026). The same page prefers setting up the new site on the same CMS as the old one. A move to Sanity can't meet that, so hold the other variable still: the CMS changes, the addresses don't, and any traffic movement traces to one cause.

Change URLs in the same release only when they carry artifacts you'd lose anyway, such as query strings, numeric IDs or .php endings. Each changed URL is then a redirect you keep for at least a year. The full CMS to Sanity migration plan starts with an inventory and a crawl of every live URL, which sizes the redirect work, and whether to redesign and replatform together covers the layout half.

How do you build the URL map for a move to Sanity?

Build the URL map from a crawl of the live site plus an export of the old CMS (content management system), then give every old URL exactly one destination. Sanity's re-platforming course says to extract content and also crawl "your existing website to record all pages that currently exist" (Sanity Learn, October 2026). An export misses pages that templates and plugins generate; a crawl misses orphan pages (Deploi's judgment). Google adds four sources of old URLs (Google Search Central, October 2026):

• Sitemaps already submitted in Search Console.
• Server logs or analytics, for the URLs with the most traffic.
• Search Console's Links report, for pages other sites link to.
• The old CMS's own list of every URL that hosts content.

Put images, PDFs and other embedded files in the map too, because Google says they move like any other URL. Retired content returns 404 or 410. Never send many old URLs to one irrelevant page such as the home page: Google says it might be treated as a soft 404, and Sanity's redirect guide says crawlers penalize redirects to unrelated content (Sanity Docs, October 2026). Keep one rule per old path, so no URL has two competing destinations.

Where do redirects live in a Sanity stack, and what limits apply?

Redirects run in your front end or at your host, not in Sanity: Sanity stores redirect documents, and the framework or host serves them. Redirect count and edit speed decide where.

Next.js sends 308 for a permanent redirect, which Google treats as permanent like 301 (Next.js Docs; Google Search Central, October 2026). Vercel bulk redirects default to 307 (Vercel, October 2026), and Response.redirect(), which Sanity's Remix example uses, defaults to 302 (Mozilla, October 2026). Google keeps a temporary redirect's source page in search (Google Search Central). Validate redirect documents, because an invalid one can stop a deploy (Sanity Learn, October 2026). See redirects at scale and the Next.js wiring.

Which SEO metadata has to move with each page?

Every page's search engine optimization (SEO) metadata moves as fields: title, meta description, canonical, hreflang, robots rules, structured data and Open Graph tags. A headless front end doesn't carry these over the way a plugin did, as the SEO risks of going headless explains, so plugin data is read out of each source. The WordPress playbook and the Contentful playbook map their own fields.

Four rules keep the transfer honest:

• Canonicals name the new URL. Google says each new URL carries a self-referencing canonical and hreflang moves to the new URLs (Google Search Central, October 2026).
• The sitemap agrees. Google says not to name one URL in a sitemap and another in rel="canonical" (Google Search Central, canonicals, October 2026).
• Overrides stay overrides. Sanity's SEO course treats SEO fields as optional overrides of existing content (Sanity Learn, October 2026). Import an old SEO title only where it differs from the page title, so later title edits still reach search (Deploi's judgment).
• Imported documents get validated. Application programming interface (API) writes skip Studio validation (Sanity Docs, Import data, October 2026), so run sanity documents validate on the import file (Sanity Docs, October 2026).

On three deploi.ca Sanity sections, Deploi builds JSON-LD (JavaScript Object Notation for Linked Data) from the same fields as the visible answer, so the two can't drift: JSON-LD from fields.

Why do sitemap dates go wrong after a Sanity import, and how do you fix them?

Sitemap dates go wrong because the Sanity CLI (command-line interface) import resets _updatedAt on every document that holds a reference, and sitemap code often reads _updatedAt as lastmod. The import loads references weak, then strengthens them in patches that "run in new transactions, which sets _updatedAt to the time the patch executes successfully"; documents without references keep their date (Sanity Docs, Import data, October 2026). Sanity's sitemap lesson builds lastmod from _updatedAt (Sanity Learn, October 2026). So every migrated page with an author or a category reads as changed on import day. Sanity's answer engine optimization (AEO) guide calls _updatedAt an honest dateModified (Sanity, October 2026); for a migrated document that holds a reference, it isn't.

Google uses lastmod only if it's "consistently and verifiably" accurate (Google Search Central, October 2026). Three fixes:

1. Add editorial created and modified datetime fields and fill them from the old CMS (content management system) during the import, as Sanity's refactoring course advises (Sanity Learn, October 2026).
2. Build lastmod and JSON-LD (JavaScript Object Notation for Linked Data) dateModified from modified, and move it only on significant updates, the standard Google sets.
3. Drop priority and changefreq, which Google ignores, and split sitemaps above 50,000 URLs.

What is the SEO plan for a move to Sanity, from crawl to monitoring?

The search engine optimization (SEO) plan for a move to Sanity runs in seven steps, and the last two are monitoring. Google says a medium-sized site can take "a few weeks or more" to show its new URLs and is crawled more heavily at first (Google Search Central, October 2026).