Migrating a large site to WordPress is not a technical problem; it is an inventory problem. The technical steps — export, import, configure a theme, point DNS — are well documented. What breaks rankings is the URL you forgot, the template that dropped a heading level, the redirect that points to the homepage instead of the equivalent page. This article is the checklist we use, built from two migrations: a large gaming operator’s move to WordPress that we handled, and our own 2026 rebuild of canyonthemes.com.
The first project was HappyLuke. HappyLuke is the largest online casino in Thailand, with live games, jackpots, slots, table games and tournaments, and a promotions programme that changes constantly. They moved both back end and front end to WordPress, and the full migration took about six months. The reasons were the usual ones — easier management, customisation, SEO control, scalability — but the length of the project is the honest number: a large content site does not move in a weekend.
Phase 1: Inventory (weeks, not days)
Before any WordPress install exists, you need a complete list of what the old site is. Three sources, merged into one spreadsheet:
- A full crawl (Screaming Frog or similar) of the live site: every URL, status code, title, H1, canonical, word count, inbound internal links.
- Search Console export of every URL with impressions in the last 16 months. This catches pages the crawl missed because nothing links to them any more.
- Backlink data (Ahrefs, Semrush or Search Console’s Links report): every URL with an external link. These are the URLs you cannot afford to 404.
Add columns: keep / merge / retire, new URL, content owner. On a site with several thousand pages, expect this phase to take a month and to change your mind about the scope. On the gaming project, the promotions archive alone contained hundreds of expired pages that still had backlinks; each needed a decision.
Phase 2: URL strategy and the 301 map
The safest migration keeps every URL identical. WordPress permalinks are flexible enough that this is usually possible: set the structure to match the old site (/%category%/%postname%/, /%postname%/, or a custom structure) and give each post the exact old slug. Where the old site used file extensions (.html, .php) you can either preserve them with a rewrite rule or map them once with a regex 301.
Where URLs must change, the 301 map is the single most important deliverable of the project:
- One old URL → one new URL, the closest equivalent in topic. Never bulk-redirect to the homepage; Google treats that as a soft 404 and the equity is lost.
- Pattern-based rules (regex) for structural changes — a folder rename, a language prefix — at server level; individual rules in a redirect plugin.
- Retired content with no equivalent returns 410, not a redirect.
- Test the map against the inventory before launch: every URL in the spreadsheet must resolve to a 200 or a single-hop 301 to a 200.
On our own rebuild the structural rule was removing WPML: every /nl/ URL 301s to its English equivalent with one RedirectMatch line, while every /downloads/* product slug stayed byte-for-byte identical because those pages carry the rankings the shop depends on. Our guide to WordPress redirects covers the implementation options.
Phase 3: Content parity
Rankings are attached to page content, not to the CMS. The new page must contain what the old page contained, in the same hierarchy:
| Element | Must match | Where it lives in WordPress |
|---|---|---|
| Title tag | Same or improved, same target term | Yoast SEO title |
| H1 | One per page, same topic | Post title (theme outputs it once — check) |
| H2/H3 structure | Same hierarchy | Heading blocks |
| Body text | Complete, including alt text and captions | Post content; media library with alt fields |
| Canonical | Self-referencing on the new URL | Yoast handles it; verify after import |
| Structured data | Same types (Article, Product, FAQ, Breadcrumb) | Yoast + theme blocks |
| Internal links | Updated to new URLs, not left to redirect | Search-and-replace after import |
| Images | Same files or better, same filenames where possible | Media library; keep upload paths |
Import tooling depends on the source. WordPress-to-WordPress moves are covered in our roundup of the best WordPress migration plugins. From a custom CMS, WP All Import with a CSV or XML export is usually the pragmatic route; for anything unusual, a one-off script against the REST API. Whatever the tool, spot-check fifty pages by hand against the old site before you trust the rest.
Phase 4: Theme and templates
The theme determines whether the parity you achieved in content survives into HTML. Requirements we set on both projects:
- Exactly one H1 per template; archive pages use the archive title as H1, not the site name.
- Breadcrumbs output with
BreadcrumbListschema. - No builder dependency, so the HTML is predictable and the pages are fast — Core Web Vitals should improve after a migration, not regress.
- Template-level support for the content types the site actually has (reviews, promotions, product pages), built as patterns or custom blocks rather than shortcodes.
- Pagination and archive URLs matching the old structure where they had rankings.
For the gaming project the theme was custom. For most publishers, a well-built theme such as Danfe or News One meets every item above and can be child-themed for the rest.
Phase 5: Staging and pre-launch QA
- Build on a staging domain blocked from indexing (Settings → Reading → Discourage search engines, plus HTTP auth).
- Crawl staging and diff against the inventory: every “keep” URL present, every title and H1 within tolerance.
- Run the 301 map against staging with a script or the crawler’s list mode.
- Lighthouse on the ten highest-traffic templates, mobile. Fix anything worse than the old site.
- Check analytics and Search Console verification are in the new theme.
- Confirm
robots.txtand the XML sitemap will be correct on the production domain, not the staging one.
Phase 6: Cut-over
Launch mid-week, in a low-traffic window, with the old site still available at a backup hostname. Lower DNS TTL a day before. After switching: remove the noindex, submit the new sitemap in Search Console, use the Change of Address tool only if the domain changed, and re-crawl the live site immediately. Keep the old server for at least a month.
Phase 7: The first 30 days
- Daily for the first week: Search Console Coverage report for new 404s and soft 404s; the redirect plugin’s 404 log; server error logs.
- Weekly: compare clicks and impressions per URL against the pre-migration baseline. Expect a dip of a few weeks while Google recrawls; a drop that persists past six weeks on specific URLs means a parity or redirect problem on those URLs.
- Fix chains as they appear — internal links pointing at old URLs are the usual cause.
- Do not redesign again during this window. One variable at a time.
Why the gaming project took six months
Not because WordPress is slow to set up. The time went on the inventory of a very large promotions archive, on rebuilding integrations that the old front end handled in proprietary code, and on QA against regulatory requirements for every market the site served. The lesson for any large migration: budget most of the schedule for phases 1 to 3 and 5, and almost none for the actual install.
Which Canyon theme fits a migrated media site
- Danfe — business or hybrid sites needing a branded homepage; clean heading hierarchy and breadcrumb support.
- News One / News One Pro — high-volume publishers with many categories and archive pages that carry rankings.
- Bloge Pro — long-form editorial sites where the single-post template does all the work.
More in the news theme category.