Rehab Website Migration: WordPress to Next.js Checklist

Every old URL needs a 1:1 permanent redirect, your CallRail scripts and schema have to fire on launch day, and Core Web Vitals should pass before you cut over if you want to keep your organic calls through a move from WordPress to Next.js. Most calls get lost at launch, when URLs change, tracking drops, or structured data breaks. If you sort out those three things in advance, you'll keep the rankings you've earned and gain a faster site.

Rehab Website Migration From WordPress to Next.js

Moving off WordPress usually comes up when page speed has slipped, plugins have piled up, and every update feels like a risk to admissions calls. Next.js fixes much of that by rendering pages as fast, lightweight code instead of assembling them from a plugin stack on every visit. A faster front end only helps if the rebuild respects what Google already knows about your site.

Google Search Central's site-move documentation describes the mechanics plainly. Each old URL needs a permanent 301 or 308 redirect to its single closest new equivalent, canonical tags need to stay intact, and your old XML sitemap should stay available for a while so you can watch pages drop out of the index. Those are the steps that carry your rankings across, and they're also the steps a rushed launch skips.

Treat the migration as a sequence with a hard gate before launch. The order we'd use looks like this:

1. 1Crawl the live WordPress site and export every indexable URL, including service pages, location pages, blog posts, and old landing pages.
2. 2Record your current Core Web Vitals (LCP, INP, and CLS) so you have a baseline to beat.
3. 3List every tracking script and schema type currently on the site, including call tracking and any Google Business Profile links.
4. 4Build the new site on a staging link and test it against all three lists before anyone changes DNS.

Your admissions director should see this plan before development starts. Rebuilds go wrong when marketing, development, and admissions each assume someone else is watching the phone line. If you want a view of how your current pages perform, our site speed test gives you a starting benchmark, and the web development team can walk through the rest.

Map Every URL and Redirect Before Cutover

Your redirect map is a spreadsheet with two columns, the old URL and the single new URL that replaces it, and it should be finished before the first page of the new site is built. Start with the crawl export, then add URLs Google already knows about that a crawl can miss. Old landing pages, retired blog posts, and paginated archives often sit in Search Console's indexed pages report long after nobody links to them internally.

Each row gets a permanent 301 or 308 redirect to the closest equivalent page. Sending a retired detox page to the homepage looks tidy, but Google can treat it as a soft 404 and the ranking value is lost. If a page has no true match, point it to the nearest parent service page and note why in the sheet.

Keep your URL structure identical wherever you can. A page that lives at /services/partial-hospitalization today should stay at that path unless there's a clear reason to change it, because every unchanged URL is one less redirect that can fail. Trailing slashes, uppercase letters, and query parameters count as different URLs, so decide on one format and apply it everywhere.

Before launch, test the map on staging with a bulk status-code checker and confirm three things:

1. 1Every old URL returns one redirect hop, not a chain of two or three.
2. 2Each destination returns a 200 status and carries a self-referencing canonical tag.
3. 3No redirect points to a page blocked by noindex or robots.txt.

After cutover, leave the old XML sitemap submitted for a few weeks so Search Console shows which legacy URLs are still indexed. Have someone check the redirect sheet against live calls from organic search during that window, so a broken page shows up in your admissions data as well as in a ranking report.

Keep CallRail Scripts and Schema Working at Launch

Call tracking breaks quietly, and most teams find out two weeks later when the admissions log shows fewer organic calls than the month before. On WordPress, the CallRail snippet usually lives in a plugin or a theme header, so it disappears the moment you rebuild unless someone moves it by hand. Add it to the Next.js site as a named task, and confirm the dynamic number insertion swaps numbers on every template, including service pages, location pages, and blog posts.

Test on staging with a real phone. Visit the page from a search-style session, call the number shown, and check that CallRail logs the call with the correct source. Keep the phone number in your Google Business Profile exactly as it is today, since the site's tracked numbers shouldn't change what's listed there. Also confirm that your Google Ads GCLID capture still works, because paid calls need that value if you plan to import offline conversions later.

Schema deserves the same discipline. List the structured data types your current pages carry, such as organization, local business, FAQ, and article markup, and rebuild each one in the new templates with the same business name, address, and phone details. Run the staging pages through Google's Rich Results Test before launch, then recheck the live pages the day you cut over.

Keep tracking and markup free of patient information. Form fields, URL parameters, and event data shouldn't carry names, conditions, or insurance details into third-party tools. Send only non-identifying events, such as a call or form submission, and have your vendors confirm their data-handling terms before you launch.

Benchmark Core Web Vitals Before and After

Google's passing thresholds are 2.5 seconds or less for Largest Contentful Paint (LCP), 200 milliseconds or less for Interaction to Next Paint (INP), and 0.1 or less for Cumulative Layout Shift (CLS), measured at the 75th percentile of real visits. Capture those numbers for your top service, location, and admissions pages before development starts, using the field data in Search Console's Core Web Vitals report and PageSpeed Insights. Lab scores from a single test run are useful for debugging, but field data is what Google uses.

Test on mobile first. Many crisis-driven searches for detox and PHP happen on a phone, and a hero video or oversized image is the usual reason a rehab page misses the LCP target. Check the same pages on your staging link, then run them again on the live site once real traffic arrives.

Expect the field report to lag. Search Console builds its data from a rolling 28-day window, so a fast launch won't show as passing the day you cut over. Don't treat a slow-looking report in week one as a failed migration. Watch the lab results daily and the field data weekly.

Pay special attention to INP and CLS, since a clean Next.js build can still regress there. Chat widgets, consent banners, and call-tracking scripts that load late often cause layout shift or sluggish taps on the call button. Set fixed dimensions for images and embeds, and load third-party scripts after the main content.

California Prime Recovery's site rebuild reached passing Core Web Vitals and came with a 30% lower paid CPA, which is why speed belongs in your admissions plan as well as your SEO plan. You can also review how we handle rehab conversion rate optimization once the new pages are stable.

What the Cipher Billing Rebuild Showed

Cipher Billing, a behavioral health billing company, moved from WordPress to Next.js and grew its top-10 keywords from 2 to 87. Monthly organic clicks rose from 100 to 889, a 789% increase. Those are the results Sweet Media documented in its Cipher Billing case study, and they're the basis for the checklist above.

Two details matter if you're planning something similar. Cipher Billing is a billing company, not a treatment center, so your results will depend on your own content, competition, and starting position. The part that carries over is the method. A rebuild gives you a faster front end, but the ranking gains come from preserving what Google already indexed and then publishing pages that earn more keywords.

Starting with only 2 top-10 keywords also meant there was little existing ranking value to lose in the move. If your rehab site already ranks for dozens of terms, the redirect map and canonical checks carry more weight, because a sloppy cutover puts more on the line.

Plan your own review around the same kind of data. At 30, 60, and 90 days after launch, compare these against your pre-migration baseline:

Top-10 keyword count in your rank tracker.

Monthly organic clicks in Search Console.

Tracked organic calls in CallRail.

Expect a few weeks of movement before the numbers settle. Judge the migration on calls and admissions inquiries first, since clicks and rankings only matter to you when they turn into conversations with your admissions team.

What Drives the Scope and Cost of a Migration

Page count is the first thing that moves a migration quote, but the number of templates matters more. A site with 150 pages built on six templates is less work than 60 pages with 20 custom layouts, because each template needs its own design, schema, tracking, and speed testing. Ask any agency how many templates they're counting before you compare proposals.

Content decisions come next. A straight move keeps every page and rebuilds the design around it, while a rewrite adds copywriting, clinical review by your team, and new service pages. Decide early which one you're buying, since mixing them mid-project is how timelines slip and redirect maps go stale.

Integrations add hours quickly. Your verification of benefits form, chat widget, CallRail setup, and any CRM connection each need to be rebuilt and tested on staging. Forms that touch patient information need extra care about what data reaches third-party tools, so bring your compliance contact in before development starts.

Several smaller items also change the effort:

The size of your redirect map, including legacy landing pages and retired posts.

Whether your domain, URL structure, or hosting is changing at the same time.

How many schema types and tracking events need to be rebuilt.

Who writes and approves copy on your side, and how fast they respond.

Hosting is a smaller cost than most owners expect, but the ongoing work is real. Someone has to monitor Search Console, check the old sitemap, and compare calls at 30, 60, and 90 days. Ask who owns that work after launch and whether it's in the scope.

Bring your page crawl, your current Core Web Vitals numbers, and a list of your integrations to the first conversation, and you'll get a scope that matches your actual site. If you'd like a second opinion on a proposal you've already received, call Sweet Media at (714) 503-8548 or request a conversation through our contact page. Book a free strategy call and we'll walk through your redirect map and launch checklist with you.