--- title: "WordPress redesign SEO checklist: URLs, content, and launch | dirango" description: "Keep track of URLs, content, redirects, and indexing during a WordPress redesign. A checklist for planning the move and checking the site after launch." canonical: "https://dirango.com/insights/wordpress-redesign-seo-checklist/" datePublished: 2026-11-05 dateModified: 2026-11-05 --- WordPress · By [dirango](/about/) · 4 min read # WordPress redesign SEO checklist: URLs, content, and launch Keep track of URLs, content, redirects, and indexing during a WordPress redesign. A checklist for planning the move and checking the site after launch. Published November 5, 2026 Even if the design changes and the URLs do not, a WordPress redesign can affect how search engines and visitors reach content. Record the current paths, test every changed destination, and inspect the live site after release. Google says rankings may fluctuate temporarily while it recrawls a site move; [its guidance](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) explains the steps. ## Before design: make a source inventory Save a dated baseline before anyone edits content. Crawl the site, then collect URLs from the website, XML sitemap, Search Console, analytics, and internal inventory. Reconcile duplicates and stale paths because no single source has the full list. For each important page, capture its URL, status, title, heading, canonical, indexability, internal links, purpose, and any available visits or conversions. Mark unavailable metrics as unavailable, not zero. Include important PDFs, images, language versions, forms, and landing pages. For every page, record whether it will stay, change, combine, retire, or be created, and name who decides. Keep a useful URL when its purpose stays the same. If a page retires, send it only to a relevant replacement; when none exists, return an appropriate 404 or 410 instead of pointing everyone to the homepage. [Google distinguishes these cases](https://developers.google.com/search/docs/crawling-indexing/troubleshoot-crawling-errors). ## During planning: map every changed path Use one URL map that records the old path, destination, action, owner, and test result. Check that each destination is relevant and that the redirect reaches it directly. Google recommends mapping changed URLs and using permanent server-side redirects; redirecting does not make unrelated pages equivalent. Google's [Site-move instructions](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) explain the process. One useful row is: `/old-program/` → `/programs/current-program/`; **301**, because the same program information moved; destination returns **200**; old and new internal links checked; owner records the result. Treat that as a format example only: use a different destination or a not-found response when the content does not have a relevant replacement. Keep useful titles, headings, copy, internal links, language alternatives, structured data, and image descriptions with the pages they support. Google may use a page title for its search title link or choose other text; see the [SEO Starter Guide](https://developers.google.com/search/docs/fundamentals/seo-starter-guide). When possible, schedule editorial changes separately from migration fixes so a problem is easier to trace. Update menus, related-content modules, footers, and body links to point directly to final URLs. A page can return 200 and still become hard to find if key internal links disappear. ## On staging: find migration defects before launch Keep staging private and include its launch access change in the plan. `robots.txt` alone does not protect confidential content; use password protection, as described in [Google's guidance](https://developers.google.com/search/docs/crawling-indexing/control-what-you-share). Before release, look for staging hostnames, leftover `noindex` directives or password gates, blocked paths, and canonicals that point to the wrong environment. Test every mapped redirect on the release candidate: response, destination, chains, loops, trailing slashes, and required query strings. Crawl the new site against the source inventory and investigate missing pages, duplicate or parameter URLs, broken links, and errors. Review representative pages on desktop, mobile, and by keyboard. Test forms, headings, image alternatives, and editor tasks. Automated tools cannot establish accessibility conformance; include human checks. See [W3C's evaluation overview](https://www.w3.org/WAI/test-evaluate/) and [forms tutorial](https://www.w3.org/WAI/tutorials/forms/). Make release conditional on the mapped URLs reaching their intended pages, priority pages returning successfully, titles and canonicals matching the plan, forms working, internal links and sitemap using the intended URLs, and production being crawlable. Assign an owner to confirm each item. ## At launch: test the public site Once the site owner approves release, test critical pages on the public host. Check status codes, redirects, rendered content, canonicals, robots directives, navigation, images, forms, and sitemap. Confirm staging restrictions are gone and obsolete or redirected paths are not listed in the sitemap. Use Search Console URL Inspection on selected priority pages to review known index information and test live access. The test does not guarantee indexing, and a crawl request is only a request. [Google documents its limits](https://support.google.com/webmasters/answer/9012289?hl=en). For a domain move, follow the separate Search Console steps after redirects are in place. ## After launch: connect changes to observed problems Monitor Search Console, the sitemap, crawl issues, page performance, analytics, and server logs when available. Compare equivalent page groups and date ranges with the baseline, and label partial or missing measurements. Retest redirects and the forms the organization depends on. If performance falls, identify affected URLs before changing content broadly. Check blocking or `noindex`, redirects, canonicals, lost internal links, and substantial content changes. Fix verified migration defects first. Google processes URLs as it recrawls them; URL Inspection cannot force a ranking outcome. ## Make the checklist part of the project scope Put the URL map, redirect tests, metadata review, and release checks in the project plan before the estimate is final. Name an owner for each check and the person who approves release. The [website governance guide](/insights/website-governance-framework/) covers how to record those responsibilities. ## Need help with your site? We offer WordPress development. Send us the site and what you need help with, or read more about the service. [Explore WordPress development ](/services/wordpress-development/)[Tell us about your site ](/contact/#project-brief-form)