WordPress to SvelteKit migration risks crawlability regression

What happened

A practitioner posted in r/TechSEO asking how to migrate a photography e-commerce site with 98,000 monthly visitors from WordPress (with WooCommerce) to SvelteKit without losing traffic. The post describes a site with poor existing SEO: no alt tags, unoptimized images, redundant database queries, and bad performance scores.

The poster noted that the site’s traffic likely comes from brand strength and location rather than technical SEO merit. Their research identified URL parity as the primary concern, including trailing slashes and sitemap consistency. Community responses, as is common with migration threads, leaned heavily toward “don’t do it.”

Why it matters

Framework migrations from server-rendered CMS platforms like WordPress to JavaScript-based frameworks carry specific crawlability risks that go beyond URL mapping. SvelteKit can render pages server-side, but the default behavior and configuration matter. A misconfigured SvelteKit deployment can serve client-side rendered pages that Googlebot handles differently than static HTML.

WordPress generates server-rendered HTML by default. Every page is crawlable without JavaScript execution. SvelteKit supports server-side rendering (SSR) and static site generation (SSG), but practitioners need to explicitly configure these. SvelteKit’s performance documentation describes code-splitting and preloading as built-in features, but SEO-critical rendering choices still require manual setup.

The e-commerce angle adds another layer. WooCommerce sites typically output Product structured data through plugins. Moving to SvelteKit means rebuilding that structured data from scratch. Schema.org’s Product vocabulary defines the expected properties, but SvelteKit has no built-in schema markup generation. Every Product type, AggregateRating, and Offer must be manually implemented in the new codebase.

Photography gallery sites also depend heavily on image search traffic. Google’s SEO starter documentation emphasizes that content needs to be interpretable by search engines. Missing alt text on the current WordPress site is a problem, but at least the images are discoverable in server-rendered HTML. A SvelteKit migration that lazy-loads images via JavaScript without proper SSR fallbacks could make image discovery worse, not better.

What to do

Confirm SSR is enabled for every indexable route. SvelteKit’s +page.server.js files handle server-side data loading. Every page that needs to appear in search results should use SSR, not client-side rendering. Test with curl or Googlebot’s rendered HTML in Search Console’s URL Inspection tool.

Map every URL before writing code. Crawl the existing WordPress site with Screaming Frog or Sitebulb. Export the full URL list including trailing slashes, query parameters, and pagination patterns. WooCommerce product URLs, category pages, and image attachment pages all need explicit handling.

Set up redirect rules for any URL changes. If WordPress uses /product/photo-name/ and SvelteKit uses /product/photo-name (no trailing slash), that difference will cause soft 404s. SvelteKit’s hooks.server.js file can handle redirects, or configure them at the edge (Vercel, Cloudflare, etc.).

Rebuild structured data manually. Audit the current site’s structured data output using Rich Results Test. Recreate Product, Offer, and any LocalBusiness markup in SvelteKit’s +page.svelte components using JSON-LD script blocks.

Preserve the XML sitemap. WordPress plugins like Yoast auto-generate sitemaps. In SvelteKit, you need a custom /sitemap.xml endpoint. Build one that dynamically pulls all product and page URLs.

Run a staging crawl comparison. Before switching DNS, crawl both the WordPress site and the SvelteKit staging site. Compare page count, status codes, canonical tags, and rendered HTML output. Any discrepancy is a potential traffic loss.

Watch out for

Image attachment pages. WordPress creates individual URLs for every uploaded image (e.g., /photo-name-attachment/). These pages often rank in image search. If the SvelteKit build doesn’t account for them, those URLs will 404 after migration.

WooCommerce query parameter URLs. Filtering and sorting in WooCommerce generates ?orderby= and ?filter= URLs that Googlebot may have indexed. Dropping these without redirects or proper canonical handling can fragment link equity.

Hydration delays affecting Googlebot. SvelteKit hydrates server-rendered HTML on the client. If hydration replaces critical content (prices, product descriptions) with loading states before re-rendering, Googlebot’s snapshot may capture the intermediate state.