How to migrate your nonprofit website off WordPress without losing SEO

If you've decided WordPress isn't working for you anymore, you already know why. Plugin sprawl, monthly maintenance bills, broken updates, no continuity. The question now is how to leave without torching the SEO equity you spent years building.

Short answer: it's doable in 3–4 weeks with no ranking loss if you plan the redirects. It's a disaster if you cutover cold. Below is the actual sequence.

The SEO equity you're trying to protect

Two things are worth protecting in a migration:

1. Existing search rankings. Pages that already rank for terms like "[your org name] donate" or "[your school name] tuition." If those URLs change and you don't redirect, you lose the ranking.
2. Inbound backlinks. Every nonprofit directory, news article, partner site, or blog that ever linked to one of your pages. If those URLs return 404s after migration, the backlink dies.

Both are recoverable with one technical step: 301 redirects from every old URL to its new equivalent. Skip that step and you're effectively launching a new website that Google has never heard of.

The 4-week migration timeline

This is what actually works for a 15–40 page nonprofit site. Faster than 3 weeks is risky. Slower than 5 weeks means scope creep.

Week 1: Inventory and pick the destination

Day 1–2: Export your URL list. Pull every URL on the current site. Two ways:

• Free: Screaming Frog (free up to 500 URLs, fine for most small orgs).
• Already in Google Search Console: export the Pages report. Every URL Google has ever indexed.

You're building a spreadsheet. One column for current URL. One column for "destination URL on new site." This spreadsheet is the entire migration. Without it, you'll miss pages.

Day 3–4: Pick the destination platform. Squarespace, Wix, Webflow, managed service, custom build. We have a whole post on this. The right pick depends on whether you'll maintain it yourself or hand it off. Don't migrate to another DIY platform you also won't maintain.

Day 5–7: Map the URLs. Go through the spreadsheet. For every current URL, write down what the new URL will be. Some maps are trivial (/about → /about). Some require thought (/blog/2019/03/our-spring-fundraiser-post-name → does this stay? Get archived? Get a new short URL?). Pages that won't migrate at all get redirected to the closest topical page, not to the homepage. Redirecting everything to "/" is treated by Google as a soft 404 and tanks rankings.

Week 2: Build the new site (in parallel, don't touch live)

The old site stays up and untouched. You build the new site on a staging URL or a temp subdomain (new.yourorg.org or a Squarespace preview URL).

• Recreate every page on the destination platform.
• Copy content over, refresh where it's stale (don't migrate 2022 events).
• Set up forms, donation hookups, integrations. Test each one with a real submission.
• Configure analytics. Install GA4 on the new site with the same property as the old site so traffic data stays continuous.
• Take screenshots of every page on the old site. You'll want these later when content shifts and someone says "where did X go?"

Week 3: Prepare the cutover

This is the week most migrations break. Three critical pieces:

1. Write the redirect map as a real file. If your new platform supports a redirect rules file (Squarespace, Webflow, Vercel, Netlify do — Wix's support is weaker), prepare it now. Format depends on the platform. Squarespace example:

/old-about-us -> /about 301
/get-involved -> /volunteer 301
/donate-now -> /donate 301
/events/2023-gala -> /events 301

Every URL in your spreadsheet from week 1 should have a redirect rule.

2. Confirm the domain transfer plan. Three options for how the new site takes over your domain:

• DNS-only swap (simplest). Point your domain's DNS at the new platform. WordPress hosting stays in place for a few weeks as a fallback. Recommended for most small orgs.
• Full domain transfer to new registrar. Only do this if you have to. Domain transfers take 5–7 days and lock you out of the domain during that window.
• Subdomain forever. Don't do this — moving your site to new.yourorg.org permanently kills your domain SEO.

3. Schedule the cutover for a low-traffic window. Tuesday morning is usually best for nonprofits. Avoid the week before a fundraising deadline. Avoid December.

Week 4: Cut over and monitor

Cutover day:

1. Point DNS at the new platform.
2. Activate the redirect rules. Test 5–10 important URLs by opening them in an incognito browser — confirm they redirect to the new equivalent.
3. Submit the new sitemap to Google Search Console.
4. Confirm GA4 is recording traffic on the new site.
5. Send a test donation, test a contact form submission, click every navigation link.

Days 2–7 after cutover:

• Check GSC's Coverage report daily. Watch for new 404s — those are URLs you missed in the redirect map. Add them.
• Check GA4 — traffic should be roughly equivalent to the week before. A 10–20% dip in the first week is normal and recovers. A 50%+ dip means a redirect is broken or the new site has an indexing issue.
• Click around as a normal visitor on a phone. Things you missed will surface.

Weeks 2–6 after cutover:

• Keep the old WordPress site online but unlinked (just remove it from the DNS). Acts as an emergency fallback.
• Watch GSC weekly. Rankings typically dip 5–15% the first 2–3 weeks, then recover by week 6. If they don't, redirects are wrong.
• After 60 days of clean traffic and recovered rankings, you can decommission the old WordPress install.

The 5 things that break migrations

1. No redirect map

The most common failure. The new site launches, all the old URLs return 404s, Google deindexes you over the following month, donor traffic from old email links dies. Avoidable with one spreadsheet.

2. Redirecting everything to the homepage

"Just redirect all old URLs to /" — tempting because it's one rule, fatal because Google flags it as a soft 404 and removes the rankings. Each old URL needs to redirect to the closest topical match on the new site.

3. Changing URL slugs unnecessarily

If the old URL was /donate and there's no reason to change it, keep /donate. Every URL change is a redirect rule and a chance for something to go wrong. Migrate URL structure as-is unless you have a real reason.

4. Forgetting non-page assets

PDFs, images, downloadable forms — if those are linked from outside your site (think "schools that link to your fundraising brochure PDF"), they need redirects too. Include all .pdf, .docx, and image asset URLs in your spreadsheet.

5. Cutting over before the new site is real

If the new site has 8 of your 22 pages built and you flip DNS to "rush the launch," visitors hit a stripped-down site. Trust craters. Wait until every page exists, every form works, every payment integration is tested.

What you can expect, by the numbers

Outcome	Done well	Done poorly
Ranking impact	-5% to -15% week 1, recovered by week 6	-40% to -80%, may never fully recover
Traffic impact	-10% to -20% week 1, recovered by week 4	-50% to -90%, takes 6–12 months to recover
Donation impact	Roughly flat, recovers by week 3	30–60% drop in online giving for 2–3 months
Total migration time	3–4 weeks	2 months and counting, with broken pieces

When you actually shouldn't migrate

If your WordPress site is genuinely working — content is current, security is patched, you have a developer or maintenance person, costs are reasonable — don't migrate just because you read an article about it. Migration is real risk. Only worth it if the current state is genuinely worse than the new state will be.

The signals that say "yes, migrate" are concrete. Site is consistently broken. Maintenance costs are climbing past $200 a month. Updates take weeks because nobody knows how to do them. The WordPress version is years out of date and you're nervous about a security incident. Any one of those is enough.

"WordPress is bad" by itself isn't a reason. Plenty of small orgs run fine on WordPress with the right setup.