Website Redesign and Migration: CMS Change, SEO Preservation
A client came 6 weeks after self-directed redesign: "We moved from WordPress to Tilda, traffic dropped 70%". I open Google Search Console — 847 pages return 404, URL structure completely changed, not a single 301 redirect. Yandex hasn't reindexed the new site yet, rankings crashed. Recovery took 4 months.
Why Migrations Break SEO
Search engines indexed specific URLs. If /catalog/shoes/nike-air-max-270 became /products/nike-air-max-270 without a 301 redirect — all the link equity on that page, all traffic, all rankings disappear. Google says 301 transfers ~99% PageRank, but in practice rankings recover over 2–8 weeks, not instantly.
Usually SEO breaks not out of malice, but because the developer doesn't think of URL structure as a public API.
Typical migration failures:
Duplicate content. New site opens on both old domain and new during development. Googlebot indexes both — duplicates.
Lost metadata. Title and description were in custom WordPress fields, forgotten to migrate for 500+ pages in new CMS. Google substitutes whatever.
Changed canonical. Pagination pages, catalog filters — canonical links reset to new format.
Performance degradation. Tilda with heavy sections, without image optimization: LCP 6.8s instead of 2.1s on old site. Core Web Vitals in red zone affects ranking.
Pre-Migration Audit: What Can't Be Skipped
Before starting development on new site you need:
- Do full crawl of current site through Screaming Frog or Sitebulb. Get list of all indexable URLs with traffic from Google Search Console.
- Export all pages with organic traffic > 0 for last 6 months — priority for redirects.
- Fix all external links (backlinks) to specific pages — Ahrefs, Semrush.
- Screenshot current rankings for key queries — baseline for post-migration comparison.
- Save Core Web Vitals from Search Console for last 90 days.
URL Mapping and Redirects
For project with 200+ pages create mapping table: old URL → new URL → status (301, merged with different page, deleted). Each row passes verification: did content really move there?
In Laravel redirects via config file and middleware, not .htaccess — faster and manageable. For WordPress → Next.js: redirects configured in next.config.js (static) and at Nginx/CDN level for dynamic.
Old .htaccess on shared hosting with 500+ redirect lines — special kind of pain. Each redirect checked sequentially, performance drops. Move to Nginx map directive or Redis cache for dynamic lookup.
Content Migration from Different CMS
WordPress → Headless CMS (Contentful, Strapi, Sanity):
WordPress REST API or WP All Export for post, custom field, media export. Migration script on Node.js: parse export, transform structure, load via CMS API. Re-upload media to new storage, update links in content. Typical issue — WordPress shortcodes in content ([gallery id="123"]): needs parser and transform to new format.
1C-Bitrix → Modern Stack:
Bitrix stores content in non-standard tables with IBLOCK_ELEMENT_PROPERTY. Direct SQL export via phpMyAdmin or Bitrix API. Transform — longest part due to Bitrix data structure specifics.
Heavy WYSIWYG → Structured Content: Years of editing in FCKEditor/TinyMCE leave inline styles, non-standard tags, broken attributes. HTML sanitize + transform to Markdown or Portable Text (Sanity) with manual check of problematic pages.
SEO-Preserving Technical Elements
Structured data (Schema.org) — if old site had Product, Article, BreadcrumbList markup, they should be on new. Google Search Console → Enhancement reports show loss of rich snippets.
XML Sitemap: generated automatically, submitted to GSC daily after launch. Old sitemap stays until full reindex.
hreflang for multilingual sites: if tags lost during migration, conflicts between language versions appear in results within weeks.
Open Graph and Twitter Card meta tags — often forgotten during template change, pages stop displaying correctly when shared in social media.
Launch and First Week Monitoring
DNS propagation: DNS switch takes up to 48 hours, plan launch with buffer. Cloudflare as DNS provider — propagation takes minutes, not hours.
After launch monitor daily: Search Console → Coverage (indexing errors), Analytics → organic traffic, comparison with same period last year, site crawl for 404 errors.
First 2 weeks — critical period. If traffic drops 30%+ — immediate redirect audit and comparison with pre-migration crawl.
Process
Pre-migration audit → URL mapping → develop new site parallel with old → final audit before launch → launch with monitoring → post-migration monitoring 4–8 weeks.
Timeline
Small site redesign with migration (up to 100 pages): 4–8 weeks. E-commerce migration with 500+ product pages: 8–16 weeks. Just technical migration (redirects, metadata) without redesign: 1–3 weeks.