Technical SEO Before a WordPress Redesign

Treat the redesign as a controlled change

A new design can improve navigation and content presentation while accidentally changing the paths people and search engines use to reach the website. Technical SEO planning belongs before implementation, when URL structure and template decisions are still easy to adjust.

The aim is to preserve useful information and make the new site understandable. A checklist reduces avoidable errors, but it cannot guarantee rankings or prevent every change in search performance. Use it alongside a defined development and recovery plan.

Inventory the current website

List the important pages, posts, media and functional routes. Note existing URLs, titles, canonical preferences and the pages receiving meaningful search traffic or enquiries. Include legal pages, contact forms and account journeys even when they are not intended to appear in search.

Save an appropriate backup and document how recovery will be verified. Identify who approves content changes and who owns technical decisions. Preserve the original inventory so that the launch review has a reliable baseline.

Make a URL decision for each important page

Keep an established URL when its purpose remains the same and there is no strong reason to change it. When a URL must move, map it to the most relevant replacement. Avoid sending unrelated old pages to the homepage simply to eliminate a missing-page report.

Review duplicated routes and agree on the preferred version. Redirects, canonicals and internal links should support a consistent decision. Do not delete a useful page solely because its text is short; first assess its purpose and whether it needs improvement.

Keep staging separate from the public site

Protect a staging copy from public discovery and avoid using it as a place for real customer submissions. Check how forms, email and scheduled jobs behave in that environment. A copied integration can still contact a live service unless its behaviour is deliberately reviewed.

Before launch, confirm that the public site does not inherit staging restrictions or staging URLs. Review the reading and SEO settings, preferred site address and important templates. A successful preview is not sufficient evidence that the live site is crawlable.

Check the templates and content

Review primary headings, page titles, descriptions and canonical URLs across representative page types. Confirm that useful article content and internal links remain present in the rendered page. Check structured data against what the page actually describes; do not add unsupported ratings or service claims.

Test navigation, search, enquiry forms and protected workspaces separately. A page can have valid metadata while its primary action is broken. Likewise, an account page may work correctly while still needing a noindex rule and appropriate privacy controls.

Verify the launch in layers

First check that important URLs resolve correctly and the intended content appears. Next verify redirects, robots rules, canonical preferences and sitemap configuration. Clear relevant caches after approved changes, then review the public output again.

Use Search Console to inspect selected important URLs and review sitemap processing. A live test showing that a page can be indexed is a technical eligibility result. An accepted indexing request is a queue acknowledgement. Neither should be reported as proof that Google has indexed the new content.

Measure after the change

Record the release date and compare consistent reporting periods. Monitor errors, important landing pages and successful enquiries. Allow for search-engine processing and other external changes before attributing a traffic movement to the redesign.

For a scoped implementation, explore SEO and technical SEO, WordPress development and website care. Start with your current website and planned changes so preservation requirements can be included in the brief.