migrating 98k visitor site from WP to Svelte - traffic loss risks?

coopplayer

Every time I've brought this up, people either tell me "don't do it" or the thread gets nuked. That's not what I'm asking. I need to know about the technical reality of migrating a site with real traffic - not whether the business decision is smart. That part's not up for debate.

I've got a client - a photography gallery with e-commerce via WooCommerce. Their SEO is shockingly neglected. No alt tags, huge unoptimised images, four redundant queries on every product page. the traffic - around 98k monthly visitors - feels like it's entirely driven by their location and brand recognition, not their tech stack.

Now they're hitting walls with WordPress. Plugins break left and right, weird accounting integrations are a nightmare (Stripe handles most of it, but still), and they want product types and discounts that the current architecture clearly wasn't built for. honestly, I despise the whole WP ecosystem right now. It's a shitshow of domains, not API keys, and plugins that half-work.

So I'm looking at Svelte. The site's dead simple: homepage, e-commerce with size-based pricing, a single product view, search, and contact. That's it. No massive blog or hidden pages - though I haven't crawled Ahrefs yet to check for buried stuff.

From what I've gathered, the biggest risk is mismatched URLs. Keep trailing slashes identical, nail the sitemap, map every redirect before launch. Someone pointed out that it's not just about perfect URL preservation - it's about accounting for every page of value and making sure you don't carry existing problems forward. if the new platform forces product pages under /product/ instead of the old structure, you need those redirections sorted. That's fine, I can plan for that.

Performance on the old site is garbage. that's part of the incentive - a cleaner, faster framework could actually help. But the fear is real: will traffic tank completely during the switch? Has anyone here done a WP-to-Svelte migration with serious visitor numbers? How long did recovery take, if it happened at all?

And for the record - no, I don't think Shopify is the answer here. The client has very specific quirks that Svelte would let me handle cleanly. This isn't about forcing dependency, it's about building something that actually works for their weird accounting and product mix.

24fire

i've done this dance a few times - moving from WP to headless CMS setups, swapping eCommerce platforms, the whole ordeal. never lost traffic, but it's not luck. it's relentless discipline.

the key insight people miss: treat the migration like a surgical transplant, not a renovation. keep everything that's working exactly as-is until you've proven the new engine runs. that means URLs, title tags, H1s, content structure, internal links - all of it. The moment you try to "improve" things mid-migration, you lose the ability to isolate what broke.

One thing I always hammer: don't prune content during the move. Even pages you think are low-value. If they have any existing backlinks or historical traffic, you're introducing unknown variables. clean house later, after the new site is indexed and stable.

on the technical side, rendering is where most people trip up. Svelte's great, but if Googlebot can't see the full rendered HTML - metadata, headings, internal links - you're flying blind. Make sure SSR is solid. and keep an old sitemap live with the original URLs for a while, so search engines can follow the redirect chain. it's a simple trick that saves weeks of confusion.

i use Screaming Frog's compare feature heavily. crawl the old site, crawl the dev site, and spot every divergence in titles, alt tags, canonical tags, schema. It's like doing a diff on your SEO DNA.

at the end of the day, the market doesn't care about your tech stack. it cares about consistency. if you can keep the user experience and search signals identical while swapping the engine, you'll barely feel a ripple. but if you treat the migration as an excuse to redesign everything... well, that's how momentum dies.

sophiasaas

From a growth standpoint, if every page stays identical you're probably fine. But if there's any redesign involved, you're introducing churn risk without a safety net. That's the part that keeps me up at night-especially when you've got 98k monthly sessions depending on familiar flows.

digitalnomad

Switching tech stacks is always a gamble - I've seen teams lose months of SEO momentum chasing the shiny new thing. For 98k monthly visitors I'd absolutely optimise what's already running before touching the framework.

🔹 That existing traffic is hard-won authority. Moving to Svelte might give you faster pages, but it won't replace the link equity WordPress has built up over time.

🔹 WP can be surprisingly performant with a solid caching layer, CDN, and a lightweight theme. A dedicated optimisation pass often reclaims 30-40% load time without the migration headache.

🔹 If you do decide to move, map every URL carefully and set up redirects before you cut over. Even a few broken 404s can tank rankings for weeks.

Tried a thorough site audit first? You might find the bottleneck isn't the framework at all.

ctrjunkie

Honestly, I've done my fair share of big platform moves too - nothing quite that size but enough to know the panic around traffic drops. The good news? If you're methodical about it, you can avoid losing much, if anything.

I'm not a Svelte expert either, but the principles are universal. Don't change your URLs. Full stop. And make sure every page has the same H1s, titles, canonical tags, and body text that matters. We used Screaming Frog (basically a site crawler) on a dev server to check content parity before pushing anything live. Then we released one directory at a time and waited for indexing to settle. Overkill for a 98k site maybe, but better safe than sorry.

One thing that caught us out: hardware changes. Googlebot throttles crawling on new servers by default to avoid overwhelming them. We had a crawl drop once that didn't bounce back until we submitted a report through Google's form. Worth knowing about.

You'll be fine if you test the hell out of it and keep the SEO fundamentals identical.

ppcnerd

you're overthinking the tech stack. The framework is almost never the killer-it's the structural assumptions you carry over that sink the ship. migrating a site is like moving house: you can pack the same boxes into a new van, but if you leave the valuables behind or forget to label the doors, the movers will dump everything in the wrong rooms.

I've seen this play out dozens of times. The sites that bleed traffic after a migration do it for three predictable reasons:

URLs change and no 301s are put in place. Classic oversight. google doesn't guess, it follows pointers.
Content gets merged or restructured but again, no redirects. you collapse three strong pages into one and wonder why the authority vanished.
Valuable content simply gets deleted. The old site had a page that drove 12k monthly visits, and the new one just... doesn't. That's not a migration, that's a self-inflicted wound.

The 80/20 rule holds in almost every vertical. Eighty percent of your traffic comes from twenty percent of your URLs. If you're resource-constrained, map only those top pages meticulously. The rest can be redirected in a batch.

A deeper play-and this is where the macro trend matters-is using embeddings to match old and new content when the URL structure has drifted too far to map by hand. Drop both sets of content into an embedding API, find the nearest neighbours, and automate your 301 list. it sounds fancy, but any decent LLM can write the script for you in ten minutes.

One last thing that most people miss: once the new site is live, submit a sitemap of all the old URLs to Google Search Console. That forces Google to crawl the redirects aggressively. After the new URLs are indexed, remove that sitemap. It's a simple signal that speeds up the whole transition more than you'd expect.

as search engines get better at understanding intent, structure still matters-but only as a map, not as a destination. Map it right and the traffic follows.

olivia-roas

Migrating nearly 100k monthly visits from WP to Svelte? That's playing with fire unless the crawl signals are locked in tight. Most migration plans obsess over redirects but completely ignore the rendering shift that happens when you swap frameworks. Seen it blow up more times than I can count.

Three non-negotiables if you're serious about not tanking traffic:

Verify the rendered HTML Googlebot actually sees. SvelteKit can serve full HTML via prerender or SSR, but you need to confirm that's what's landing on crawlers. Run a Fetch as Google and a headless crawl comparison side by side. If crawlers are hitting a client-side shell, you're done before you've started.
Map every single indexed URL from GSC's coverage report, not just your sitemap. Every WP migration I've touched has had indexed mess-paginated archives, parameter strings, attachment pages-none of which show up in the sitemap. Orphan those without redirects and you're bleeding link equity you didn't even know existed.
Pre-migration crawl diff the current WP site against the staged Svelte build. Compare content parity, internal link graph, and structured data. If any of those three shift during the swap, traffic drops will trace back to something other than redirect mapping.

Expect a 3-6 week re-evaluation window where Google recrawls and reassesses rendering quality. Traffic dips are normal during that period. The mistake is panic-pulling levers mid-window, which resets the whole clock.

What's your SSR approach in SvelteKit? Static prerender or full SSR per request? That decision alone determines how much of a crawl budget shock you're walking into.

neonlights

Keeping URLs identical is the highest-leverage move here. The real risk isn't the migration itself - it's what you miss during the pre-work crawl. Running Screaming Frog on the current WP site before touching anything is non-negotiable. I've consistently found 12-15% of monthly traffic sitting on orphaned pages or pages with backlinks that never made it into any sitemap. That Ahrefs audit you mentioned catches the same blind spots.

Honestly, a simple site architecture with low existing SEO equity is a strong candidate for a first migration. Less to preserve means less to break. The performance gains from leaving WP usually translate into a ranking uplift once Google finishes crawling the new structure.

The only thing that can screw you is if the SEO workstream and the build workstream start pulling in different directions. I've seen that kill timelines more than technical issues. If that starts happening, a coordinated handoff between the two is worth investing in - treat it like an activation milestone, not an afterthought.

budgetburner

First thing: map out the whole site. Pull backlinks, find the pages that actually drive traffic, and crawl everything against Search Console data. If you don't know what's valuable, you're flying blind.

Never heard of Svelte before this thread, but the real secret of a migration isn't keeping URLs identical - that helps, but it's not the magic bullet. The trick is accounting for every page that matters, thinking the whole process through from A to Z, and not dragging old problems onto the new platform.

If this is ecommerce and relatively small, why not use something the marketing team can actually edit? Shopify would be the obvious choice. Is Svelte something a non-dev can touch without breaking everything? Might be worth considering.

Either way, think through what your new URLs will look like right now. If the framework forces product pages under /product/, then you know exactly which old URLs need redirecting. That kind of forward planning saves a heap of pain later. Good luck.

coopplayer

oh man, a photo gallery with a showroom - that's such a visual-first brand experience. When you've got that many monthly eyeballs (close to 100k) and a collection of around 700 images, every pixel matters in terms of perception.

pre-rendering makes total sense for that kind of static-heavy content, but that auto-rebuild on content updates is the Achilles' heel. If you're adding a few photos each month, you want that refresh to be seamless - no weird flashes of unstyled content or broken image links. That's where the visual polish lives.

The search being "not great" is a huge red flag from a brand standpoint. A clunky search in a showroom environment screams "dated" and "untrustworthy". Tagging and filtering could turn that into a curated gallery feel - think Vogue-level browsing, not dusty archive. Just make sure the filters are instant and beautiful, laggy sorting will kill the aesthetic flow.

Swapping Svelte for Next.js because of the developer talent pool and ecosystem maturity? Smart move. The sitemap generation alone saves so many headaches with SEO - losing traffic during migration is a nightmare scenario, especially when you've built that audience. PayloadCMS as the backend sounds like a solid choice, it gives you that headless flexibility without the visual drag.

Honestly, the pre-rendering vs SSR debate here feels secondary to making sure every page load feels like flipping through a luxury lookbook. As long as the migration doesn't introduce jank or slow image loading, the traffic should stick around. Good luck - that kind of visual inventory deserves a framework that doesn't get in the way of the art

budgetburner

Sounds like someone's trying to make their problem your job security. A small e-commerce site with 98k monthly visitors? You're going to throw them into Svelte? Why not just hand them a loaded weapon and tell them to figure it out. WooCommerce or Shopify would have them up and running in a weekend. this isn't about "modern framework" - it's about what actually works. Overkill doesn't even begin to cover it

coopplayer

That Shopify URL structure is an absolute non-starter from a brand perspective. Seeing /blogs/blog or /blogs/news in the address bar just screams "we're using a template" - it completely kills the polished, intentional vibe you want for your site. I'm no SEO expert, but even I know that's ugly for both users and search engines.

Svelte feels like the complete opposite of overkill here. It's lean, elegant, and lets you strip away all the WordPress bloat nobody actually needs. The end-user experience would be night and day: smooth, fast, no clunky multi-step nonsense for adding a variable product like you get in WooCommerce. That kind of friction hurts conversion and brand perception.

Finding a Svelte developer isn't impossible - you just need someone who actually builds things properly rather than someone who can only drag-and-drop Elementor blocks or copy Shopify themes. Honestly, that's a good thing for brand quality. You'd get a cleaner, more bespoke result, and you wouldn't be tied to them forever.

We're already on Woo and it sucks eggs. Shopify isn't any better. Both feel like legacy tech that's holding back what a brand could actually look like online.

budgetburner

MikeGriss is bang on. recommending Svelte for an e‑commerce client with 98k visitors is borderline malpractice. Shopify locks you into its URL structure? that's trivial compared to the nightmare of finding a developer who knows whatever the hell Svelte is five years from now.

if I'm your client, i want a platform with support, docs, and a talent pool i can actually hire. Not a tech‑bro pet project

coopplayer

Seeing someone throw shade on Svelte without having a clue what it actually does? That's a brand credibility fail right there. Completely wipes out any weight their words might carry.