how to monitor WordPress redirects during a site migration

why WordPress migrations lose SEO traffic through broken redirects

Migrations rearrange URL space. A classic PHP theme becomes a block theme, a shop moves from a subdirectory to a domain root, product slugs change for marketing, or a headless front end takes over while WordPress stays the CMS. Redirect maps drafted in spreadsheets miss long-tail posts, old parameterised faceted navigation, PDF attachments, and locale prefixes. After go-live, Google Search Console and Bing Webmaster Tools slowly surface 404s, but the damage to rankings and paid landing pages accumulates before a human opens the report. WooCommerce migrations add product, category, and endpoint paths (/konto/, /koszyk/, /moje-konto/, checkout variants) that differ by locale plugin. Multilingual sites with Polylang or WPML multiply every legacy path by language. A redirect that works for /en/product/foo may not cover /de/produkt/foo or trailing-slash variants. CDNs and Cloudflare page rules can serve stale 200s or cached 404s that disagree with origin, so a single curl from a laptop is not evidence. Manual spot checks of the top twenty URLs are theatre. Real protection is an automated pipeline that knows the legacy URL inventory, expects a final 200 or 301 chain to a canonical destination, and pages humans when error budgets break during the cutover window. Paid acquisition makes broken redirects expensive on day one. Shopping and Performance Max landing URLs, email campaign links from Klaviyo or Brevo, and QR codes on packaging do not update themselves when you redesign permalinks. A migration that only protects organic top pages still burns ad budget on 404 landing experiences. Finance notices the CPA climb before SEO notices the chart dip. Another blind spot is file URLs: PDFs, invoices, and downloadable product files under wp-content/uploads with old year/month paths. Theme migrations rarely rewrite those, but marketing links do. Include attachment URLs from the media library export in the inventory when downloads matter to the business. Faceted navigation and leftover filter query strings from old layered-nav plugins also create soft 404 clusters that look like bot noise until a human sorts by referrer and finds paid campaigns attached. Write down owners for each URL pattern before go-live so alerts do not bounce between SEO, paid media, and development without resolution. A named owner shortens mean time to redirect fix more than another dashboard widget.

when to run redirect checks before during and after go-live

Start a full legacy URL verification in staging when the redirect plugin or server map is marked ready for QA. Re-run on production immediately after DNS or Cloudflare cutover, then on a rolling schedule every hour for the first forty-eight hours and daily for two weeks. Also trigger when Search Console or a log-based 404 feed shows a new spike above baseline, and when editors publish a slug change on a high-traffic post. Do not wait for the monthly SEO meeting. Trigger a differential crawl when Cloudflare or nginx redirect config is deployed, not only when WordPress plugin rules change. Hook deploy pipelines so a redirect map change in git kicks a targeted verification of touched rows before traffic shift.

how to validate redirect maps and catch 404 regressions automatically

1. Build the legacy inventory from XML sitemaps, Search Console top pages, server access logs, and the old redirect plugin export; normalise hosts, trailing slashes, and http vs https.
2. Store expected targets for each legacy path in a reviewable map (CSV or database) with owner and date, and reject go-live if high-priority rows lack a target.
3. Crawl with a worker that follows redirect chains, records status codes, final URL, hop count, and timing; fail rows that land on 404, 410 without approval, soft 404 HTML, or chains longer than your policy.
4. Compare production results against staging baselines and open tickets for regressions grouped by pattern (product slugs, blog year archives, account endpoints).
5. Push critical failures to Slack or email with sample URLs and ship a hotfix redirect; re-crawl only the failed cohort after deploy.
6. After two quiet weeks, reduce crawl frequency but keep sampling Search Console 404 examples into the same map so newly discovered legacy URLs get owners.
7. Include paid landing URLs, email deep links, and downloadable attachment paths in the priority inventory, not only organic sitemap URLs.

data flow from crawl lists Search Console and uptime into alerts

Inputs are static exports (sitemaps, CSV maps) plus APIs: Google Search Console searchAnalytics or URL inspection samples, Cloudflare or nginx logs, and optionally Ahrefs or similar crawl tools if already licensed. An n8n or custom Node worker on a schedule performs HEAD/GET checks from a location outside your office IP so you see CDN behaviour. Results land in a spreadsheet or Postgres table consumed by a simple dashboard. WordPress Redirection, Safe Redirect Manager, or server-level maps remain the place where fixes are written; the monitor never invents redirects without a human. For privacy, strip query parameters that may contain emails or order tokens before storing sample URLs. Store raw hop traces for failed rows so humans see whether the break is at apex-to-www, language prefix, or final slug. Feed summaries into the same reporting channel used for uptime, but keep SEO-specific grouping. If you already run sync-error-alerts style ops dashboards, add a redirect_error budget rather than inventing a separate pager rotation. Keep personally identifiable query parameters out of stored traces; hash or strip them at ingest.

handling false 404 alerts and CDN cache during redirect cutover

Treat CDN cache as a first-class failure mode: if origin returns 301 but the edge still serves 404, purge the path and recheck before paging SEO. Distinguish bot noise (wp-login probes, random phpmyadmin paths) from inventory URLs using an allowlist; do not wake humans for probes. When a marketing team changes a slug without updating the map, mark the row as drift and require an owner decision: update map or restore redirect. Cap alert storms by grouping failures sharing a prefix so one bad category basepath does not send two hundred Slack messages. When staging and production hostnames differ, rewrite expected targets during staging runs so you do not fail every row for host mismatch. After cutover, freeze the map version used for the go-live decision and treat later edits as a new version with its own diff crawl.

when redirect monitoring automation is unnecessary

If you are changing a colour in the theme and keeping every permalink identical, a full redirect monitor is overhead. A single-page brochure site with twenty URLs can be checked by hand. Build the automation when URL count, locales, or commerce endpoints make spreadsheet QA unreliable. Domain-only moves that keep every path identical still need a short apex/www/https check, but not a continuous inventory crawler. Use a one-off script instead of a standing service.

KPIs for migration redirect monitoring

• Share of priority legacy URLs returning an approved final 200 within hop limits
• New 404s per day on inventory URLs during the first two weeks after cutover
• Median time from detected inventory 404 to deployed redirect fix
• Count of redirect chains exceeding hop policy