Add to Preferred Sources
A website content migration checklist is a phase-ordered list of tasks that ensures every URL, page title, meta description, image, redirect, and tracking tag moves correctly from your current site to the new one — without losing the search rankings and organic traffic your business depends on. If you are rebuilding your site, switching platforms, or moving to a new domain, you are about to execute the single riskiest technical event in your site's life.
A structured approach to web design in Johannesburg and across South Africa means the migration plan is built before the first page is designed, not bolted on afterwards. South African businesses running WordPress, WooCommerce, or custom-built sites are especially exposed during migrations: a missed redirect on a high-traffic product category, a forgotten robots.txt noindex tag left on from staging, or a broken analytics configuration can cost weeks of recovery time. The checklist below is organised into five phases because the order is not arbitrary — tasks done out of sequence compound errors instead of preventing them.
Quick Answer
A website content migration checklist covers five phases: pre-migration audit (crawl all current URLs, export metadata, build a redirect map), staging setup (transfer content to a blocked test environment), content and metadata validation (confirm titles, descriptions, alt tags, canonicals, and structured data), launch day execution (activate redirects, remove noindex, verify analytics), and post-launch monitoring (track indexation, 404s, and rankings intensively for the first six weeks).
Google recommends server-side permanent redirects (301 or 308) and notes that small-to-medium sites can take a few weeks or more for most pages to re-index. Missing any phase in sequence — especially the pre-launch staging validation — is the most common reason South African business sites lose rankings during a redesign.
Jump to Section
Is Your Migration Plan Already Written?
Send us your current site URL and platform, and we will tell you exactly which migration tasks carry the highest SEO risk for your setup — before any development starts.
Get a Free Migration Risk ReviewWhat a Complete Website Content Migration Checklist Must Cover
A robust website content migration checklist is not a single list of tasks — it is a sequence of phase-gated decisions, where each phase must be validated before the next begins. Unlike a generic web migration checklist focused only on server configuration, a content-complete checklist also covers metadata, internal links, structured data, and analytics continuity.
The consequence of reversing that order is concrete: redirects activated without a complete URL map produce 404 errors that erode rankings; staging validation skipped means noindex tags or broken canonicals go live; analytics not verified before cutover means the business has no data to diagnose what went wrong. The five phases below reflect the sequence that prevents each failure mode.
Phase 1: Pre-Migration Audit — the Foundation Everything Else Depends On
The pre-migration audit is the stage where you capture a precise snapshot of your current site so every decision in the migration has a reference point. Any website migration checklist that skips this phase leaves the team migrating blind: you will not know which URLs generate organic traffic, which pages carry backlink equity, or which metadata combinations currently produce rankings. Fixing missing data after launch costs significantly more time than capturing it before.
Work through each of the following in order:
| Audit Task | What You Are Capturing | Tool to Use |
|---|---|---|
| Full site crawl | All URLs, status codes, redirect chains, internal link structure | Screaming Frog, Sitebulb, or similar crawl tool |
| Metadata export | Title tag, meta description, canonical, H1, image alt per URL | Crawl tool CSV export |
| Organic traffic baseline | Top 50–100 URLs by organic sessions (12-month window) | Google Analytics 4 or Search Console |
| Keyword ranking snapshot | Current positions for your target keywords | Search Console performance report or rank tracker |
| Backlink profile export | External domains linking to your current URLs | Ahrefs, Semrush, or Google Search Console links report |
| Structured data inventory | Schema types currently implemented per page | Rich Results Test or crawl tool |
Once the crawl is done, build your redirect map: a spreadsheet matching every current URL to its destination on the new site. High-traffic URLs and pages with backlinks are your priorities. If a current URL has no equivalent on the new site, decide now whether to create one or let it 404 — redirecting many old URLs to a single irrelevant destination such as the homepage may be treated by Google as a soft 404; prefer redirecting each URL to its closest relevant equivalent on the new site.
SA Hosting Note: If your current site is on shared South African hosting and you are moving to a new host or platform, request your current host to keep the old environment live and intact during the entire migration window. DNS propagation typically takes 24–48 hours, and you need the old server responding correctly throughout that period.
Phase 2: Staging Environment — Test Everything Before It Goes Live
A staging environment is a private, search-engine-blocked copy of the new site where you validate every migration decision before a single real user — or Googlebot — sees the result. Without a staging environment, any error you introduce during content transfer appears in production immediately, potentially triggering crawl errors, duplicate content flags, or missing redirects that start affecting rankings within hours.
These tasks must be complete before any content is transferred to staging:
- Block the staging URL from search engines using robots.txt Disallow or an X-Robots-Tag HTTP header. Password protection via HTTP basic auth is strongly recommended in addition to robots.txt — bots that ignore robots.txt cannot bypass basic auth.
- Set up SSL on the staging environment so the final site's HTTPS behaviour can be tested correctly. Google's page experience documentation identifies HTTPS as a required quality standard within the page experience evaluation — your new site must serve all pages over secure connections from day one.
- Install and configure your analytics and tag management stack on staging before content goes in. Testing tracking on an empty staging site is faster than debugging it on a populated one.
- Confirm that your form submissions, payment integrations, and third-party tools (booking systems, live chat, CRM connections) work on the staging domain.
Phase 3: Content Transfer and Metadata Validation
The content transfer phase is where the page text, images, metadata, and internal link structure moves from the old site into the new one — and where most migrations lose ground by treating it as a bulk copy-paste exercise instead of a page-by-page verification process. Every high-traffic page must be checked individually for title tag accuracy, meta description presence, canonical tag correctness, image alt text, and internal link integrity.
Work through this validation checklist for every page you migrate:
| Element | What to Check | Priority |
|---|---|---|
| Title tag | Matches pre-migration export; contains primary keyword; under 62 characters | High |
| Meta description | Unique per page; benefit-led; under 155 characters | High |
| Canonical tag | Self-referencing on all canonical pages; not pointing to old domain | High |
| H1 tag | One per page; matches intended title; no empty H1s | High |
| Image alt text | Descriptive alt on all product/service images; no empty alt on informational images | Medium |
| Internal links | All internal hrefs point to new URLs, not old domain | High |
| Structured data / schema | Validated via the Rich Results Test on the staging URL (staging protected by a meta robots noindex or password, not a query string — there is no ?noindex parameter) | Medium |
| Images | Compressed and optimised before upload; no images with readable text replacing real text | Medium |
For WordPress-to-WordPress migrations, an internal link path update is essential after transfer. Any plugin or script that rewrites absolute URLs from the old domain to the new one must run before your staging review — broken image paths and internal links that point to the old domain are the most common post-launch fix requests.
The Redirect Map Is Not Optional
Every old URL that changes must map to its closest equivalent on the new site with a 301 permanent redirect. Google's site migration guidance recommends server-side permanent redirects (301 or 308) and explicitly warns against redirect chains — where URL A redirects to B, which redirects to C. A redirect chain adds latency and increases the chance that Googlebot stops following before reaching the destination. Map A directly to C, and update all internal links to point to C directly once the migration is live.
Not Sure Your Redirect Map Is Complete?
Share your current site URL and your new site's sitemap, and we will audit your redirect coverage and flag any high-risk gaps before you go live.
Book a Redirect AuditPhase 4: Launch Day — the Tasks That Cannot Be Delayed
Launch day is a controlled sequence, not a single action. The most damaging migration errors happen when teams treat go-live as flipping one switch instead of working through a fixed order of operations with verification between each step. The window between DNS cutover and full propagation is when errors compound fastest, so the checklist below should be followed in the order given.
Complete each item before moving to the next:
- Remove the staging-only restrictions — the meta robots noindex tags or X-Robots-Tag headers and the robots.txt Disallow rules that were added to keep staging out of the index — before DNS points to the new server, while keeping any production exclusions you intend to retain. A staging noindex left in place can suppress the entire new site within hours. Google does not support a noindex directive inside robots.txt, so check the meta tag and headers, not only robots.txt.
- Activate your full redirect map on the server (not inside WordPress or another CMS — server-level .htaccess or Nginx rules execute faster and avoid CMS-layer redirect chains).
- Confirm SSL is active and all pages serve over HTTPS — including images, scripts, and third-party embeds. A single HTTP resource on an HTTPS page triggers mixed-content warnings that break the browser padlock.
- Verify analytics and conversion tracking — fire a test conversion event and confirm it appears in GA4 and any connected ad platforms (Google Ads, Meta) before announcing the launch internally.
- Submit your new XML sitemap to Google Search Console. This signals the full list of new URLs to Googlebot and accelerates the recrawl of your most important pages.
- Pause all content updates for at least 24 hours post-launch. New content introduced during DNS propagation creates version conflicts and makes diagnosing errors significantly harder.
- Run an immediate post-launch crawl using your crawl tool to confirm redirects return 301 (not 302), all priority pages return 200, and no noindex tags remain on live pages.
Load-Shedding Risk for SA Operators: If your team or your hosting provider is on unprotected power during the launch window, a Stage 4 or Stage 6 outage mid-DNS propagation can leave your site inaccessible for several hours while both old and new configurations are in transition. Schedule cutover for a window when load-shedding is unlikely, or confirm your hosting has UPS cover.
Phase 5: Post-Launch Monitoring — the 30-Day Accountability Window
The post-launch monitoring phase of your website content migration checklist is not a passive observation period — it is an active daily task that determines whether ranking losses are caught and reversed within days or become permanent. Traffic typically stabilises within 4–8 weeks as search engines recrawl old URLs and process 301 redirects, but that window only works in your favour if you are watching the signals and acting on them immediately.
Structure your monitoring around three tiers:
| Timeframe | Frequency | What to Monitor |
|---|---|---|
| Days 1–3 | Daily (2× per day) | Search Console coverage errors, 404 spike, redirect map accuracy, analytics firing correctly |
| Week 1–2 | Daily | Indexed page count (old URLs dropping, new URLs rising), ranking changes on top 20 keywords, Core Web Vitals in field data |
| Week 3–6 | Weekly | Organic traffic vs pre-migration baseline, backlink health (any links now pointing to 404s), site speed vs baseline |
The most actionable Search Console reports during this window are the Index Coverage report (flags new crawl errors and dropped pages) and the URL Inspection tool (lets you force a recrawl of any URL that has not yet updated in the index). If you see a sudden drop in indexed pages without a corresponding rise in new URLs, check whether your sitemap was submitted correctly and whether any redirect chains are blocking Googlebot from reaching final destinations.
What "Normal" Looks Like After a Migration
Some temporary fluctuation in rankings is expected in the first 2–3 weeks as search engines process the full redirect map. As a working rule of thumb, a gradual recovery curve — organic traffic trending back toward the pre-migration baseline within 4–6 weeks — signals a healthy migration. A sharp drop that does not recover after week 3 signals a specific technical error (most commonly: redirects not resolving correctly, a key page returning a non-200 status, or analytics capturing a session on the old domain instead of the new one).
SA Platform Considerations: WordPress, WooCommerce, and Custom Builds
Platform choice determines which migration risks are highest for South African operators, and the checklist tasks above apply differently depending on your stack. The majority of SA business sites run on WordPress — either a standard installation or WooCommerce for ecommerce — and each carries specific migration hazards.
WordPress to WordPress migrations (host change or domain change) are the most common and typically the lowest-risk, but they require careful database search-and-replace to update all hardcoded URLs. Any plugin that stores absolute URLs in the database (page builders, image sliders, SEO plugins with stored metadata) needs a URL update pass after the database is imported to the new environment.
WooCommerce migrations carry additional data complexity: product images, attribute tables, order history, customer accounts, and payment gateway configurations all need verification post-transfer. If you process payments through PayFast, Peach Payments, or Yoco, each payment gateway integration requires a test transaction on the new URL before going live — these gateways often whitelist specific domains and will reject payment requests from an unregistered new domain.
Platform switches (for example, WordPress to Shopify, or Wix to WordPress) are the highest-risk category. URL structures change entirely, meaning every existing URL needs a redirect, and content that was managed in one CMS's proprietary format must be re-entered or converted for the new platform. If you are managing a platform switch, the pre-migration audit becomes even more critical — URL structures change entirely and the redirect map can grow significantly beyond what a same-platform migration requires.
POPIA note: If your migration moves a database containing contact form submissions, customer accounts, or lead records, your data processor obligations under POPIA apply. Ensure that data in transit is encrypted, that your new hosting environment's data location is documented, and that your data processing agreement with any new host or platform is in place before the transfer.
For more on choosing the right platform before you migrate, see How to Choose a CMS for a Business Website and Website Redesign Cost South Africa: 2026 Pricing for a full picture of what a site rebuild typically involves.
Migrating a WooCommerce or WordPress Site?
Tell us your current platform and where you are moving to, and we will give you a specific pre-migration risk assessment — including payment gateway and POPIA data handling checks — at no cost.
Request a Platform Migration AssessmentWhy South African Businesses Choose Growth Pulse Media for Website Migrations
Most web design agencies treat a migration as a development handover — they build the new site, hand you the keys, and consider the job done. The post-migration monitoring, the redirect map verification, the Search Console recrawl — these become your problem. Growth Pulse Media approaches migrations differently because Dirk built and scaled a South African ecommerce business before founding the agency: he has experienced what happens when a platform switch goes wrong without a structured recovery plan, and that experience shapes how every project is managed.
We manage a limited client load so every migration gets senior-level attention throughout — not just on build day. That means the redirect map is reviewed before the design is finalised, the staging validation is done in-house rather than delegated to a developer, and the post-launch monitoring is scheduled into the project scope, not treated as an optional extra. Our work covers the full stack: technical migration planning, content transfer, on-page SEO preservation, and analytics reconfiguration — executed through our web design service with no outsourced components.
We work with WordPress, WooCommerce, and Shopify migrations specifically, and we hold Shopify Partner and Omnisend Certified Partner credentials. If your business runs on one of these platforms and you are planning a migration in the next six months, the time to start the pre-migration audit is now — not when the new design is already being built.
Who This Checklist Is NOT For
Frequently Asked Questions
How long does a website content migration take?
A full website content migration — audit, staging, content transfer, validation, and launch — typically takes between 3 and 8 weeks depending on site size and complexity. As a working rule of thumb, a small site of under 50 pages can be managed in 3–4 weeks; a larger site with an established backlink profile will need longer. Google notes that a small-to-medium site can take a few weeks for most pages to re-index after a migration. Rushing the pre-launch phase to hit a deadline is the most common cause of post-launch ranking drops — the pre-launch work is the only part of the timeline you fully control.
What is the difference between a website content migration and an SEO migration?
A website content migration covers the complete transfer of all page content, images, metadata, and configuration from one site or platform to another. An SEO migration is a specific sub-set focused on preserving and improving search rankings through that transfer — it includes redirect mapping, Search Console configuration, and post-launch ranking monitoring. In practice, every content migration should include SEO migration tasks, because the two cannot be cleanly separated: a content error (like a missing canonical tag) becomes an SEO problem within the same crawl cycle.
Do 301 redirects fully pass SEO value to new URLs?
Google has confirmed that 301 permanent redirects pass link equity to the destination URL, though the transfer is not instant — Google must crawl the old URL, follow the redirect, and update its index, which can take days to a few weeks for high-traffic pages. Avoid redirect chains (URL A → B → C instead of A → C directly), as they add latency and reduce the likelihood that Googlebot follows through to the final destination. Update your internal links to point directly to the new URL once the migration is live.
What should I monitor in Google Search Console after a migration?
Monitor the Index Coverage report daily for the first two weeks to catch any new crawl errors or drops in indexed pages. Use the URL Inspection tool to force-request indexation of your most important pages. Track Search Console's Performance report for keyword ranking changes — a drop across all terms simultaneously usually points to a technical issue, while a drop in specific terms suggests a metadata or content mapping problem. Submit your new XML sitemap on launch day and check that the sitemap processing report shows the expected number of URLs being submitted.
What happens if I skip the staging environment and migrate directly to production?
Migrating directly to production without a staging validation phase means that every error — a missing redirect, a wrong canonical tag, a noindex left on from development, a broken form — appears on the live site immediately and starts affecting search performance within hours. Errors that would take minutes to fix in staging can take days to diagnose and correct in production because the live environment has real users, active caching, and DNS propagation complexity layered on top. For any site with existing organic traffic, skipping staging is not a shortcut — it is a risk multiplier.
Ready to Migrate Without Losing Your Rankings?
Growth Pulse Media manages website content migrations for South African businesses on WordPress, WooCommerce, and Shopify — from pre-migration audit and redirect mapping through to post-launch monitoring. All work is executed in-house, with senior attention throughout the project. No obligation — we will get back to you within 24 hours.
Start Your Migration Plan