WordPress to Custom: Planning Your Migration

A step-by-step guide to migrating from WordPress to a custom site without losing your search rankings, traffic, or sanity.

Published 7 min read
Fredy RodriguezFredy Rodriguez
Neatly stacked plain moving boxes on a hand-truck dolly in a minimal space — representing careful planning for a website migration
Table of Contents

The decision to move off WordPress is the easy part. The migration itself is where rankings get lost.

Poorly planned migrations routinely cause ranking drops that persist for months. Pages that ranked on page one for years can disappear from search results entirely, not because the new site is worse, but because the handoff between old URLs and new ones was never mapped out. This guide covers the steps that prevent that outcome.

If you are still deciding whether to move, the decision criteria are in Part 1 of this series. This post assumes the decision is made and the work is beginning.

Why migration planning determines whether you keep your rankings

Search engines accumulate signals about your URLs over time: inbound links, click data, crawl history, structured data. All of that lives at specific addresses. When you move your site, those addresses change. If you do not tell Google where the new addresses are, it treats the old ones as broken pages and stops counting their signals toward your rankings.

The redirect map is the document that solves this. It is the single most important output of the planning phase, and it takes time to build correctly.

Audit before you migrate

Before you write a single redirect rule, you need to know what you are moving.

All current URLs and their traffic value

Export your full URL inventory from Google Search Console. Filter for pages with at least one click in the past 90 days. These are your highest-priority redirects. Pages with zero traffic still need redirects, but they are lower urgency.

The output of this step is a spreadsheet: every URL on your current site, its organic traffic, and the number of inbound links pointing to it (pull inbound link data from Google Search Console or a tool like Ahrefs). This is your migration inventory.

Content worth keeping vs. content worth leaving behind

A migration is a good opportunity to clean house. Thin pages with no traffic and no backlinks do not need to be migrated. Old posts that cover topics your new site will address better can be consolidated rather than transferred one-to-one.

The test: does this page serve a visitor or rank for a keyword? If the answer to both is no, a redirect to the closest relevant page on the new site is enough.

Pages with external backlinks deserve special attention. Even if a page has low direct traffic, a redirect from a link-bearing page protects the equity those external links carry. Do not skip this step.

Redirect mapping: the document that protects your rankings

A redirect map is a two-column spreadsheet: old URL on the left, new URL on the right. Every row represents a 301 redirect you will configure on your server before go-live.

A 301 redirect tells Google and browsers that a page has permanently moved. According to Google Search Central, 301 redirects preserve the ranking signals associated with old URLs, transferring them to the new destinations.

A few rules for a clean redirect map:

  • Map every old URL to the most relevant new URL. Sending everything to the homepage signals to Google that the old pages no longer exist as distinct content.
  • Avoid redirect chains. Map directly to the final destination; chains slow down signal transfer.
  • Keep redirects active for at least one year. Google recommends this to ensure full recrawl and equity transfer.

Content migration and file organization

For small sites (under 50 pages), manual migration is often faster and cleaner. You control the quality of each page’s content, metadata, and formatting.

For larger sites, migration plugins or export tools can handle bulk transfer of post content from WordPress. Review the output page by page before go-live. Automated tools frequently carry over formatting artifacts, broken shortcodes, and plugin-generated HTML that does not translate cleanly to a custom stack.

WordPress stores media in wp-content/uploads/ with date-based folder paths. Your new site will use a different structure. Update all image references during migration and confirm that file paths in body copy point to the new locations. Broken image paths are one of the most common post-launch QA failures.

DNS cutover and go-live

Build, populate, and fully test the new site on a staging environment before the DNS switch happens. Verify that every redirect rule fires correctly. Check Core Web Vitals on the staging build. Confirm that structured data is intact.

Finding a broken redirect in staging costs ten minutes. Finding it after cutover costs a week of ranking recovery.

Lower your DNS TTL (time to live) to 300 seconds 24 to 48 hours before the planned cutover. This shortens the propagation window from hours to minutes. Once the switch is live and verified, restore your TTL to a standard value.

If your migration involves a domain change, submit the Change of Address tool in Google Search Console. This signals the move to Google and prioritizes the new domain in search results for 180 days. It supplements your 301 redirects; it does not replace them.

Post-migration monitoring

The migration is not finished at go-live. The 30 days after cutover are when problems surface.

Check Google Search Console daily for the first two weeks: crawl errors, 404 pages, and changes in index coverage. Watch organic traffic in GA4. Ranking fluctuations in the first two to four weeks are normal as Google processes the new URLs. Significant drops that persist past 30 days signal a redirect mapping problem worth investigating.

Migration checklist

  • Export full URL inventory from Google Search Console
  • Identify pages with traffic and inbound links (priority redirects)
  • Decide: migrate, consolidate, or redirect each low-value page
  • Build redirect map (old URL to new URL, direct, no chains)
  • Build and test new site on staging
  • Verify all redirect rules on staging
  • Check Core Web Vitals on staging build
  • Lower DNS TTL 24-48 hours before cutover
  • Execute DNS cutover and verify
  • Submit Change of Address in Search Console (domain changes only)
  • Monitor crawl errors and index coverage for 30 days
  • Keep 301 redirects active for at least one year

What comes next

A well-executed migration gets you out of WordPress cleanly. Part 3 of this series covers what you gain from a custom-built site: the performance, flexibility, and SEO advantages that become available once the constraints of the platform are gone.

For context on how migration planning connects to building a new site from scratch, the planning and strategy guide in our First Business Website series covers the same foundational thinking from a different starting point.

Work like this is at the center of projects like Motion Giraffx, a video studio that moved from an unstable WordPress setup to a custom platform, and Detail Exchange, an auto detailing business whose migration was planned to execute without downtime.

If you are ready to plan your wordpress migration, our web design process covers the full scope. Let’s talk through yours.

Frequently asked questions

Will migrating my website hurt my SEO?

It depends entirely on how the migration is managed. A well-planned migration with a complete redirect map, a staging environment, and post-launch monitoring preserves the vast majority of your rankings. A rushed migration that skips redirect mapping can cause Google to treat every changed URL as a 404 error, which wipes out years of accumulated search equity. The migration itself is not the risk. The lack of planning is.

What is a 301 redirect and why do I need it?

A 301 redirect is a server-level instruction that tells Google and browsers that a page has permanently moved to a new address. According to Google Search Central, 301 redirects preserve link equity, meaning the ranking signals your old URLs earned transfer to the new ones. Without 301 redirects in place, every URL that changes during a migration becomes a dead end for both visitors and search engines.

How long does a website migration take?

The technical cutover (DNS switch) happens in minutes or hours. The full process, from content audit through post-migration monitoring, typically runs 6 to 12 weeks for a small-to-mid-size business site. Google’s recrawl of a migrated site usually takes a few weeks for most pages. Plan to keep 301 redirects active for at least one year.

What should I check in the first 30 days after migration?

Monitor Google Search Console for crawl errors, 404s, and indexing coverage drops. Check your redirect map for any chains or broken paths. Watch organic traffic in GA4 for any ranking movements. Confirm that inbound links from other sites are resolving correctly to the new URLs. Most ranking fluctuations after a well-managed migration stabilize within 30 to 60 days.

Share this postTwitter / XLinkedInBluesky
Fredy Rodriguez
Fredy Rodriguez

Technical Director & Co-Founder

Runs the data-and-code side of Desque: SEO, GEO, AEO, PPC, copywriting, and the engineering behind every site we ship. Builds in Go and TypeScript.