Your website redesign needs an SEO launch plan

Freeze the information architecture before the final migration

A redesign becomes difficult to control when page names and destinations keep changing during the final upload. Approve the main navigation, service hierarchy and article categories before producing the definitive redirect map. Each important old URL should have an explicit outcome: retained, replaced by a relevant page or removed because the information is no longer available.

Keep editorial decisions separate from file naming. A more attractive heading does not necessarily require a new URL. Retaining a sensible existing path can simplify the move. Where a change is useful, document why the new destination serves the same customer need and ensure all internal links point directly to it.

For a complementary practical guide, read Website Redesign Content Inventory: Decide What to Keep.

Test the actual upload package rather than a designer's preview

A design preview can hide missing files or environment assumptions. Extract the final delivery package into a clean folder and check that images, fonts, stylesheets and scripts are included. Then test the hosting version on a staging environment with the same capabilities as production. A static file preview cannot establish that a PHP form sends email.

Check nested articles and category pages as well as the homepage. Relative asset paths can work at the root and fail several folders deeper. Review a representative service page, contact page, category and article from the packaged files. The final deliverable should preserve the complete directory structure required by those pages.

Check metadata as a page inventory

Create a simple launch sheet containing URL, title, description, main heading, canonical destination and intended indexing state. Review it for empty fields, accidental duplicates and references to a staging domain. A visually correct page may still carry metadata from another service or an earlier design, especially when layouts have been duplicated.

Read each entry as a promise to the visitor. The title should describe the actual page, and the description should preview information that is present. Check that social-sharing images belong to the intended article. Treat structured data as another representation of visible facts, with authors, dates and organisation details matching the public content.

For a complementary practical guide, read Mobile Service Website Usability: Make Enquiries Easier.

Prepare a practical recovery plan

Take a backup of the existing website and record how to restore it before replacing production files. Keep the approved upload package separate from working drafts. If the launch exposes a serious delivery problem, a known recovery path allows the team to act decisively instead of trying to reconstruct the old site from scattered local copies.

Define who can change hosting settings, update redirects and inspect email delivery. A launch plan needs responsible people as well as technical tasks. Record what requires immediate rollback, what can be repaired in place and how the business will be informed. This keeps a small deployment problem from becoming an extended period of uncertainty.

Review search and customer routes after the domain is live

Run the public checks again after deployment. Confirm the intended domain, secure connection, redirects, navigation, downloadable files and contact routes. Test from a fresh browser session so cached assets do not disguise a missing stylesheet or old script. Check that the private-preview indexing policy has not accidentally carried over to the public pages.

Keep a short post-launch issue list with severity, owner and resolution. Watch important landing pages and inbound destinations rather than treating the homepage as the whole website. A successful upload is the start of the public verification process; real hosting, search access and email delivery must be assessed in the environment customers will use.

Protect the pages that people enter directly

Visitors do not always begin at the homepage. They may follow an old email, saved bookmark, social link or article shared by a colleague. Include those destinations in the launch inventory where they are known. A redesign that looks complete from its main navigation may still abandon customers arriving through useful older routes or downloadable resources.

Select a small set of important entry paths and test them from start to finish after upload. Confirm the response, the relevance of the destination and the next action. Where a page is intentionally removed, explain the available alternative honestly rather than sending every request to an unrelated page. This customer-oriented check complements technical redirect testing and helps the launch team recognise problems that a homepage screenshot cannot reveal.