A platform move survives or fails on one thing: whether the new platform can reproduce your existing web addresses, and whether it can hold a permanent redirect for every address it can’t. That’s it. The design doesn’t decide it and the content doesn’t decide it. If the destination can’t do those two things at your page count, no migration plan rescues the rankings, because every step in the plan depends on capabilities the platform doesn’t have.
Get that wrong and the bill arrives late. The content gets rebuilt, the design gets approved, the invoice gets paid, and then the search traffic you spent years earning falls off in the week of the switch. By then the cheap fix is gone. You’re choosing between rebuilding the URL structure a second time and absorbing the loss, and neither one was in the quote.
What Actually Decides Whether a Platform Move Costs You Rankings?
The destination decides, not the plan. Search engines track pages by address. Change the address without leaving a permanent forwarding instruction and the old page stops existing as far as Google is concerned. So the only question that matters is what the new platform lets you do with addresses and forwarding.
This is where a platform change stops behaving like a redesign. On a redesign you choose the new URLs, so you can decide to keep them. Change platforms and a chunk of that choice moves to the vendor. Most hosted platforms impose a URL grammar you can’t fully override: a fixed prefix on every product, a fixed path for the blog, a folder name you don’t get to rename. Your old addresses may simply not be constructible there.
That’s a different risk class from the one most owners have been warned about. If you’re staying put and only rebuilding the look of the site, the checklist is different — we covered what a redesign on your current platform puts at risk separately. A move between hosts running the same software is milder again, because your addresses don’t change at all.
What Should You Check on the New Platform Before You Commit?
Four things, and you can check all of them in an afternoon without buying a tool. Can it reproduce your URLs? Can it hold a redirect for every one it can’t? Can you still control the tags search engines read? And can you export everything back out if the move goes badly? Any no is a negotiation, not a detail.
Put them to the vendor and get the answers in writing before you sign. Salespeople answer “does it do SEO” with a yes every time. These four don’t have a comfortable yes available unless it’s true.
| What to verify | The question to ask | Why a no is expensive |
|---|---|---|
| URL grammar | Can I create this exact address, folder path included, on your platform? | Every address you can’t rebuild becomes a redirect you maintain forever. |
| Redirect capacity | How many redirects can I load, can I upload them in bulk, and are they permanent? | A cap below your page count means some equity never transfers. |
| Tag control | Can I set the title tag, the canonical tag and a no-index rule per page? | Losing per-page control turns a migration into a rewrite of working pages. |
| Exit path | Can I export my content and my redirect list in a usable format later? | Without it, the next move costs more and you’ll be quoted accordingly. |
The redirect question is the one people underestimate, because they assume a redirect is a redirect. It isn’t. Google’s own redirect guidance is blunt about the mechanism: setting up server-side redirects requires access to the server configuration files. On a self-hosted site you’ve got that access. On a hosted platform you’ve got whatever redirect screen the vendor chose to build, and its limits are the real limits of your migration. Some cap the rule count. Some don’t do pattern matching, so a thousand posts means a thousand hand-entered lines.
Treat the URL List as a Feasibility Test, Not a Migration Task
Every migration guide tells you to list your URLs, and files it under launch work. Move it to the front and it becomes the cheapest way to find out whether this move should happen at all.
Before we quote a platform move, we pull the full URL list off the current site and try to rebuild each address on the new platform first, because the ones that can’t be reproduced are the whole risk. It’s an unglamorous half day, and it settles more than any conversation about features does.
You don’t need a crawler licence to get a workable list. Three sources cover most small business sites:
- Your sitemap file, usually at your domain followed by /sitemap.xml, which lists every page your site declares.
- Search Console, which shows which of those pages actually earned clicks in the last year. Anything with clicks is a page you can’t afford to break.
- Your own navigation and footer, clicked through like a customer, to catch older pages nothing links to any more.
Sort by clicks and stop where the traffic tails off. For most local businesses that’s thirty to sixty pages, not hundreds. Those are the addresses that have to survive. If the new platform can reproduce them, the move is a project. If forty can’t and the platform caps redirects at twenty-five, it isn’t a project. It’s a decision to give up traffic, and it deserves to be discussed that way before anyone signs.
What Breaks in a Platform Move That a Redesign Leaves Alone?
Things that were never in your content in the first place. A redesign moves pages between templates you control. A platform change hands your pages to different software, and anything that lived in the old software rather than the page itself doesn’t come along. Most of it fails silently, which is why nobody catches it on launch day.
- Image addresses. Platforms move images onto their own storage and rename them. Every link pointing at your old image addresses now points at nothing, and image search traffic goes with it.
- Structured data. The markup behind review stars and business details usually lives in a plugin, not in your text. After a move you get whatever the new platform generates by default, which may be nothing.
- Measurement continuity. Analytics and Search Console verification are installed per platform. If the tag isn’t reinstalled on day one, you lose the data you need to judge the move.
- Duplicate address variants. Platforms differ on trailing slashes, capital letters and filter parameters. One page served at four addresses splits its own ranking signals unless the canonical tag is set.
- Crawl rules. Staging sites are blocked from search engines. That block belongs to the old setup, and the new one needs rules written deliberately, not copied by accident.
None of these costs much to prevent. They get missed because whoever reviews the new site is checking whether it looks right, and all five are invisible on the page. Someone has to own that layer by name, before launch day.
How Long Should the Drop Last Before It Counts as Damage?
Watch the shape, not the calendar. Google’s guidance on hosting changes says a temporary drop in crawl rate right after a switch is normal, followed by a steady recovery. A gentle dip that’s already climbing back is the system working. A vertical drop on day one isn’t settling, it’s something broken.
The fastest way to tell them apart is to look at traffic that has nothing to do with search. If direct visits and advertising traffic dropped on the same day organic did, the problem is the site itself — usually a crawl block left on, or redirects that never got loaded. If only search moved, you’re in the recrawl period, and the right response is to leave it alone.
Two checks are worth doing by hand in the first week. Open five of your best old addresses and confirm each lands on the right new page, not an error or the homepage. Then confirm the site answers on one address only: if the www version, the non-www version and the insecure version all load, the platform isn’t consolidating them.
Give it six weeks before you draw a conclusion, and freeze the site while you wait. No new pages, no rewritten titles, no structural changes. Change things mid-recovery and you won’t be able to tell what caused what. If your move is host-to-host with addresses untouched, the exposure is much smaller and the sequence differs — we’ve written up moving a WordPress site between hosts step by step for that case.
Frequently Asked Questions
Do I have to change my domain name when I change platforms?
No, and you shouldn’t. Your domain carries your reputation with search engines, so keeping it means you’re only changing the part of the address after the slash. Changing platform and domain in the same week stacks two risks and makes it much harder to tell which one caused a problem.
What if the new platform can’t hold all the redirects I need?
Then you’ve found a real constraint, and you’ve got three options. Negotiate a higher limit, which some vendors allow on a business plan. Cut the list to addresses that still earn clicks or have links pointing at them. Or put a small server in front of the platform to handle redirects first. Doing nothing is a decision to lose those pages.
Can I move part of my site first and the rest later?
Sometimes, and it’s often safer for a bigger site. Moving one separated section, like a blog or a store, lets you test how the new platform handles addresses and redirects on real traffic before committing everything. It only works when the split is clean. If the halves share navigation, templates or a checkout, a phased move creates more problems than it avoids.
Do I need to tell Google that I moved to a new platform?
Not directly. There’s a tool for telling Google you’ve changed domains, but it doesn’t apply when the domain stays the same, which is the usual case here. Submit the new sitemap and watch the indexing reports. Google finds the change by crawling your redirects, so the redirects are the announcement.
Who sets up the redirects, my new platform’s team or me?
Assume nobody unless it’s written down. Free onboarding help usually covers moving your content and making the design look right. It rarely includes mapping old addresses to new ones, because that needs knowledge of your traffic the vendor doesn’t have. Ask who owns the redirect list before the project starts.
Get the URL List Checked Before You Sign
The honest version of this decision takes a couple of hours: the list of addresses that actually earn you traffic, a straight answer about which of them the destination can reproduce, and a written owner for the redirects. Run that first and the move is either clearly safe or clearly worth renegotiating. It’s the same check we run across the platforms we build and support, before any content gets rebuilt.
If someone’s quoting you a move right now and you’d rather not find out the hard way, book a migration review and we’ll go through your list against what the new platform can actually do.