Do this first: map old WordPress URLs to new URLs before launch
The most important part of a WordPress migration is not the design—it is the redirect map. Create a spreadsheet with every indexable URL on the old site and its matching destination on the new site. If a page is being replaced, point the old URL to the closest relevant page, not the homepage.
Start with these URL types:
- Homepage
- Core service pages
- Location pages
- Blog posts with traffic or backlinks
- Contact, about, FAQ, and pricing pages
- Any pages that rank for branded or local terms
If you use a platform like Solo for a simpler marketing site, keep the structure clean and predictable so redirects are easier to manage later. A short, stable URL structure is usually easier to maintain than a large WordPress archive with many thin pages.
Inventory what you already have in WordPress
Before moving anything, export a full content inventory. You need to know what exists, what matters, and what can be retired. Do not rely on memory.
Checklist for your inventory
- List all pages, posts, categories, and tags
- Export your XML sitemap and compare it with your crawl
- Pull pages from Google Search Console that get impressions or clicks
- Check analytics for landing pages with conversions or traffic
- Note pages with backlinks from other sites
- Identify pages that should be merged, redirected, or deleted
If a page has links or rankings, give it special attention. Even a low-traffic page can be important if it supports a keyword cluster or earns backlinks.
Preserve the URL structure whenever possible
The easiest migration is the one with the fewest URL changes. If the new site can match the old path, do it. If not, keep the slugs as close as possible. For example, /services/house-cleaning should not become /page-2 or /offerings/basic without a reason.
Use these rules:
- Keep slug names short and descriptive
- Avoid changing multiple URL segments at once
- Do not add unnecessary dates or categories to blog URLs
- Remove pagination only if the content no longer needs it
- Keep trailing slash behavior consistent across the site
If you must change the structure, document every old-to-new match in your redirect map before the new site goes live.
Set up 301 redirects page by page
Use permanent 301 redirects for every old URL that changes. This is what protects search equity, backlinks, and user bookmarks. Do not use 302s for permanent moves, and do not send everything to the homepage.
Redirect priorities
- Exact page-to-page redirects for all important URLs
- Section-level redirects only when no close match exists
- Homepage redirect only for the old homepage
- 404 handling for pages with no useful replacement
Examples:
- /services/seo-audit → /seo-services
- /blog/wordpress-checklist → /resources/wordpress-checklist
- /contact-us → /contact
Test each redirect in a browser and with a crawl tool before you announce the migration. Every important old URL should return a 301 to the intended destination, not a chain of multiple redirects.
Audit canonicals before and after the move
Canonicals tell search engines which version of a page should be indexed. During a migration, canonicals often break because templates change. Check them manually on key pages.
Make sure each live page points to its preferred URL with a self-referential canonical unless there is a clear reason to do otherwise. If a page has duplicates, parameter variations, or print versions, the canonical should point to the main page you want indexed.
Watch for these common mistakes:
- Canonicals still pointing to the old WordPress domain
- Canonicals pointing to redirected URLs
- Template errors that place the homepage canonical on every page
- Blog archives canonicalizing to the wrong section
If you are moving content into a simpler builder such as Solo, check the page source or settings after publishing so the canonical matches the final URL structure.
Rebuild internal links instead of relying on redirects
Redirects are not a substitute for updating internal links. After launch, every navigation item, contextual link, footer link, and button should point directly to the final destination.
Internal link update checklist
- Main navigation
- Footer links
- Sidebar links
- In-content links within pages and posts
- Image links and call-to-action buttons
- Author bio and related-post modules
This matters because redirect chains waste crawl budget and slow users down. A page that internally links to /old-service and then redirects twice is harder for search engines to crawl and harder for visitors to use.
A practical approach is to crawl the new site after launch and export all internal links that still point to old URLs. Fix them in batches, starting with the pages that have the most traffic or the strongest rankings.
Carry over titles, meta descriptions, and headings with care
Do not blindly copy every old title tag or heading, but do preserve the pages that already earn search traffic. If a page ranks, keep its topic focus, search intent, and major keywords intact.
For each important page, compare the old and new version:
- Title tag includes the core query
- Meta description reflects the new page accurately
- H1 matches the page’s main topic
- Subheadings cover the same intent as the old page
- Body content still answers the original query
If you rewrite a page too aggressively during migration, you can lose relevance. Keep the content structure familiar unless you have a strong reason to change it.
Update XML sitemaps and submit them again
After launch, your sitemap should include only the new URLs you want indexed. Remove old WordPress URLs from the live sitemap as soon as the new pages are ready and the redirects are in place.
Then:
- Generate the new XML sitemap
- Confirm it contains only canonical live URLs
- Exclude redirected, blocked, and deleted pages
- Submit the sitemap in Google Search Console
- Check for indexing errors over the next few days
If the old WordPress sitemap remains accessible, search engines may continue to crawl deprecated URLs. That is not fatal if redirects are correct, but it creates unnecessary noise. Remove or replace the old sitemap references as soon as possible.
Check robots.txt, noindex tags, and indexability
A migration can accidentally block an entire site from search results. Before launch, verify that important pages are indexable and that you are not carrying over staging rules from development.
Indexability checks
- Important pages return 200 status codes
- Noindex tags are removed from live pages
- Robots.txt does not block critical paths
- Canonical tags do not conflict with indexability rules
- Staging subdomains are protected from indexing
One of the most common mistakes is leaving a staging noindex rule active after go-live. Another is blocking CSS or JavaScript resources that search engines need to render the page properly.
Keep content, images, and file paths consistent
If the content itself is changing platforms, keep high-value assets in place whenever possible. That includes image filenames, alt text, PDF links, and downloadable resources that have been linked from other pages or external sites.
Use this approach for assets:
- Retain image filenames when practical
- Preserve descriptive alt text on important images
- Redirect old file URLs if PDFs or documents move
- Check embedded videos and forms after launch
- Replace broken media links inside migrated content
Broken asset paths can hurt user experience and make old pages look abandoned even when the redirect is working correctly.
Plan the launch window and freeze content changes
Do not keep editing both sites at the same time. Set a freeze window so the old WordPress site stops changing while the final export and redirect map are finalized. This prevents missed posts, duplicate edits, and mismatched versions.
A simple launch sequence looks like this:
- Freeze content updates on WordPress
- Export the final content and media
- Publish the new site
- Deploy redirects
- Verify canonicals, sitemaps, and analytics
- Test high-value pages on desktop and mobile
If the move involves a small service-business site, keep the launch window during a low-traffic period so you have time to fix problems before peak hours.
Run post-launch tests on the pages that matter most
The first 48 hours after launch are for verification. Test the pages that drive leads, calls, and organic traffic before you worry about low-value pages.
Post-launch test list
- Homepage loads correctly and redirects from the old URL
- Top service pages resolve with one 301 maximum
- Key blog posts preserve rankings and metadata
- Forms, phone links, and email links work
- Navigation links point to live URLs
- Search Console shows the new sitemap
- No important pages are blocked or noindexed
Also check server logs or crawl reports for repeated hits to redirected URLs. That can reveal internal links you missed.
Watch rankings, crawl errors, and traffic for two to four weeks
Some fluctuation after a migration is normal. What you want to avoid is a long decline caused by broken redirects, indexation problems, or content mismatch. Track a narrow set of metrics so you can spot real issues quickly.
Monitor:
- Organic clicks and impressions for top pages
- Ranking changes for core keywords
- 404 errors and redirected URLs in Search Console
- Newly indexed pages versus deindexed old pages
- Conversions from organic traffic
If a page drops sharply, compare the old and new versions for title changes, missing content blocks, lost internal links, or redirect mistakes. Fix the page before making broader changes.
Use this final migration checklist
Before you consider the migration complete, confirm the basics:
- Every important old URL has a correct 301 redirect
- Canonicals point to the live preferred URLs
- Internal links use new URLs directly
- Old XML sitemaps are replaced with the new sitemap
- Noindex and robots rules are correct
- Metadata and headings still match search intent
- Forms, buttons, and media work on all key pages
- Search Console and analytics are connected
If you want a faster rebuild with a simpler structure, a tool like Solo can work well for small marketing sites and local service businesses. The key is still the same: keep the URL map tight, verify the technical details, and make every old path resolve cleanly to its new home.
What to do if something goes wrong
If rankings or traffic drop more than expected, start with the highest-impact checks first:
- Find redirect chains or broken redirects
- Confirm the homepage and top landing pages are indexable
- Inspect canonical tags on dropped pages
- Look for accidental noindex tags
- Compare old and new content for relevance loss
Most migration issues come from a small number of preventable mistakes. Fix the technical blockers first, then restore content and internal links before making design changes.
When the redirect map is accurate and the site remains crawlable, a WordPress migration can be clean, measurable, and low risk.
How many redirects should I set up when leaving WordPress?
Set up a 301 redirect for every important URL that changes, including pages, posts, and any old links with traffic or backlinks. Do not rely on one blanket redirect to the homepage unless the old page truly has no replacement.
Should I keep the same page slugs when migrating to a new builder?
Yes, whenever possible. Keeping the same slugs reduces the number of redirects you need and makes it easier to preserve search relevance and backlinks.
What should I update first after the new site goes live?
Start with redirects, canonicals, internal links, and sitemap submission. Those four items have the biggest impact on crawlability and ranking preservation.
How do I know if a page should be redirected or deleted?
Redirect it if the old page has traffic, backlinks, or a clear topical replacement. Delete it only if it has no meaningful value and no relevant destination.
Will my rankings drop during a WordPress migration?
Some fluctuation is normal, especially in the first few weeks. The goal is to minimize it by preserving URLs, using 301 redirects, keeping content relevant, and fixing technical issues quickly.