How to Rebuild a WordPress Website Without Losing SEO Rankings

A rebuild is worth doing when the current site is slow, unsafe or too hard to change. It is a search risk when the project is treated as a visual refresh and the URLs are left until the week of launch. This is the sequence we use, and the point at which we tell a client to stay on WordPress.

Why businesses leave WordPress

WordPress is a capable CMS. Teams outgrow a particular WordPress setup, which is not the same thing.

The usual reasons are practical:

• The page builder and plugin stack has become slower than the business can accept, especially on mobile.
• Updates feel dangerous because nobody knows which plugin the site depends on.
• Editors cannot change the pages that matter without breaking the layout.
• The site needs several languages and the current multilingual plugin fights the theme.
• A form, a jobs feed or a portal needs application logic that plugins only approximate.

Those are good reasons to re-platform. “WordPress is unfashionable” is not.

When a migration is worth it, and when it is not

A redesign that also rewrites every URL, deletes half the content and launches on a Friday is the version that loses traffic. Split “make it fast and editable” from “change what the company says” if you cannot do both carefully.

Choosing the stack

Pick the stack around who will edit the site in a year.

• Next.js, or a similar framework, with a small content layer. A good fit when performance, custom templates and integrations matter, and someone technical remains involved. Content can live in MDX, a git-based workflow or a headless CMS such as Sanity. This is what we used for the AAMC Abogados rebuild from WordPress, and for Aston Education, which needed a jobs feed from a recruitment API.
• A calmer WordPress build. A good fit when a non-technical team must publish often and the current pain is the theme, not WordPress itself. Fewer plugins, a modern theme, proper hosting.
• Another CMS the team already knows. Familiarity is a feature if it keeps pages updated.

Next.js is our default for new custom sites because the pages can be rendered as HTML, the deployment model is simple, and application features can live in the same codebase. It is not the correct choice for every organisation. Say so in the proposal.

Audit the current site before you design the new one

Export evidence, not opinions.

• Crawl the live site and the XML sitemap. Keep status code, indexability, canonical, title, meta description, H1 and word count.
• In Google Search Console, export pages and queries that already receive impressions. Those URLs are the ones a redirect plan must not guess at.
• Do the same in Bing Webmaster Tools if Bing matters to the market.
• List backlinks to specific URLs, even a rough list from Search Console’s links report. A URL with external links needs a specific destination.
• Note the content types: posts, landing pages, locations, authors, PDFs, campaign URLs, parameter variants.
• Record structured data types and whether they match the visible page.
• List integrations: forms, CRM, booking, jobs, analytics, consent, search.

Agree what will be kept, merged, rewritten or retired. Retired does not mean “redirect to home”. It means a considered destination or a genuine 404 for URLs that never should have been indexed.

Keep the search intent, not just the text

If a page ranks because it answers a particular question, the new page has to answer that question at least as clearly. A shorter, prettier page that no longer explains the service will not “inherit” the old performance just because the redirect is in place.

For each URL you intend to keep, write down:

• The query themes it already earns.
• The promise of the current title and H1.
• What must still be true on the new page.
• What you are deliberately changing, so a traffic drop is not a surprise.

Merging two overlapping articles is often right. Do it by choosing the stronger URL as the destination, combining the useful parts, and redirecting the other URL there. Say that you merged them. Do not leave both live with the same copy.

Map old URLs to new URLs

A mapping is a spreadsheet with one row per old URL.

Rules that prevent the usual mistakes:

• One hop. Old URL to final URL, not old to intermediate to new.
• HTTPS and the correct host, including the www decision, are part of the map.
• Lowercase and trailing-slash rules are consistent, and the other variants redirect once.
• Parameter URLs used in ads are either preserved or given their own row.
• Pagination, feeds and attachment pages are explicit decisions, not leftovers.

Google’s guide to site moves with URL changes is the reference for this stage. Read it before the redirect rules are written.

Permanent redirects

Use a server-side 301 or 308 when the move is permanent. Google’s redirect documentation treats those as a signal that the target should be canonical. A 302 is for a temporary move and tells Google to keep the old URL in mind.

Do not use a JavaScript redirect or a meta refresh as the plan. They are fallbacks for when the server cannot redirect.

Avoid:

• Redirect chains left over from a previous redesign.
• A catch-all that sends unknown URLs to the homepage.
• Redirecting a deleted service to an unrelated service because it “keeps the link juice”. The visitor, and often Google, would have been better served by a relevant page or an honest 404.

Test the map with a crawler against the staging site, then again on production the hour you launch. Check a sample of the URLs that have impressions, not only the homepage.

If the domain name itself changes, use Search Console’s Change of Address tool after the redirects work. A redesign on the same domain does not need that tool.

Titles, metadata and canonicals

Carry the meaning across, then improve it. Launch morning is a bad time to rename every title for the sake of a new tone of voice.

• Each new indexable URL has a unique title and meta description.
• The new page’s canonical points at itself, on the new URL, not at the old WordPress URL.
• noindex used to hide the staging site is removed from production. This is the most common way to launch an invisible site.
• Hreflang, if you have several languages, references the new URLs in every language. A hreflang entry that still points at WordPress creates a loop of confusion.
• Open Graph titles and images match the new pages so shares do not show the old brand.

Staging should be blocked by authentication or a host-level rule, not by a noindex that someone copies to production.

Structured data

Re-implement only the types that match the new templates. A WordPress SEO plugin often emits several types on every page, including ones the design no longer supports.

Keep organisation, breadcrumb, article and service markup when the page shows those things. Drop review markup unless the reviews are visible and real. Validate the templates, not every URL by hand, then spot-check a page of each type in the Rich Results test and in Search Console after launch.

Markup does not preserve rankings. Incorrect markup can make you ineligible for rich results. The AI search guide explains that limit in more detail.

Internal links

Redirects fix external and old internal links. The new templates should not rely on that.

• Navigation, footer, related links and in-content links point at the new URLs directly.
• Anchors describe the destination. “Click here” survives a migration and remains a poor link.
• HTML sitemaps or hub pages, if you have them, are regenerated.
• The XML sitemap lists only 200 canonical URLs. It does not list the old paths and it does not list redirected URLs.

Crawl the new site and look for links that still contain /wp-content, ?p= or the old permalink structure. Those are unfinished.

Languages

A multilingual WordPress site often encodes language in a subdirectory (/es/), a subdomain, or a plugin query. Pick one pattern for the new site and map every language URL.

• Translate properly. A Spanish URL with English body text should not be presented as a Spanish page.
• Give each language its own canonical.
• Confirm hreflang is reciprocal.
• Do not redirect all languages to English because the translation is “phase two”. If the Spanish page is not ready, do not advertise its URL.

On MRS Climatización the rebuild included Spanish, Catalan and English, because the audience uses all three. The consultancy site you are reading is English and Spanish only. The right set is a content decision, made before the URL map is frozen.

Performance

A migration is the cheapest moment to fix what WordPress had accumulated.

• Serve pages as HTML. Do not rebuild the site as a client-rendered application and call it faster.
• Resize and compress images. Do not upload the theme’s original 4000-pixel hero.
• Load fewer fonts, with a sensible fallback.
• Keep third-party scripts on a leash: one tag manager, a consent mode that matches the cookie banner, and no chat widget on every template unless someone has asked for it.
• Measure Largest Contentful Paint, Interaction to Next Paint and layout shift on the templates, on a phone, before launch.

Core Web Vitals are not the migration plan. They are one of the things the new platform ought to make easier. Google’s site-move documentation is still the document that protects the URLs.

Test before you switch DNS or press publish

On a staging host that search engines cannot index:

• Crawl every URL in the map and compare status codes with the spreadsheet.
• Check canonicals, titles, robots meta and hreflang on one URL per template.
• Submit a test form, a test payment if you have one, and a test of each integration.
• Check the 404 page returns a real 404.
• Check analytics and consent on staging with a filter, so production data stays clean.
• Read the site on a phone. Click the primary action.

Then launch in a window when someone who can roll back is actually present.

After launch

Expect movement. Look for damage you caused, and do not “optimise” randomly in the first fortnight.

• Watch the Page indexing report and the Crawl stats. A spike of 404s or a drop in crawled pages is a mapping bug until proved otherwise.
• Inspect the URLs that used to have impressions. Confirm Google sees the 301 and then the new canonical.
• Keep the old sitemap available only if it helps discovery of the redirects for a short period. The new sitemap should be the one you submit.
• Leave the redirects in place. A year is the usual minimum discussed around site moves. Many should stay indefinitely.
• Annotate the launch date in analytics so a later comparison has a marker.
• Re-check the manual prompt list and the AI-search basics only after the index has caught up. A migration week is a bad week to judge citations.

If rankings fall on URLs whose content and intent did not change, and the redirects are clean, wait for recrawl before you rewrite the pages again. If rankings fall because you deleted the answer, put the answer back.

Mistakes we see on failed rebuilds

• Designing the new information architecture with no export from Search Console.
• Changing permalinks for style (/our-services/ to /what-we-do/solutions/) without a reason a visitor would notice.
• Launching the new site with the staging noindex still on.
• Pointing canonicals at the old domain.
• Redirecting the blog archive to the homepage and assuming the posts will “sort themselves out”.
• Translating the navigation and not the metadata.
• Measuring success as “the homepage still ranks for the brand”. Branded queries are the last thing you lose. The non-brand queries are the ones that pay for the project.

Migration checklist

• Crawl and export URLs, indexability, titles, canonicals and H1s.
• Export Search Console pages and queries. Note URLs with external links.
• Decide keep, merge, rewrite or retire for each URL that has impressions or links.
• Choose the stack for the editors you really have, not the stack in a trend report.
• Write a one-hop 301 map, including host, protocol, slash and file URLs.
• Rebuild content so the surviving pages still satisfy the old intent.
• Implement unique titles, descriptions and self-referencing canonicals.
• Rebuild structured data from the new templates. Remove anything the page does not show.
• Point internal links at final URLs.
• Map every language. Add hreflang only for pages that exist.
• Test redirects, forms, integrations and indexing directives on a non-indexable staging site.
• Remove staging noindex on production. Submit the new sitemap.
• Monitor indexing and the old money URLs. Keep the redirects.

AAMC Abogados is the public example of a WordPress site rebuilt on a modern stack, with the information architecture and search foundations redesigned together. We do not publish a ranking delta for that project because we will not put a number on this page that the case study does not support.

The service behind this work is website rebuilds and platform migration. If the new site also needs to be understood by AI answer engines, that is SEO and AI search, done on the new templates rather than bolted on afterwards.

Sources

• Site moves with URL changes, Google Search Central.
• Redirects and Google Search, Google Search Central.
• Change of address, Google Search Console Help, for domain changes only.
• Bing webmaster guidelines, for indexation, canonicals and AI grounding controls.

These pages were the reference in November 2026. Use the live document if a detail has moved.