Website Redesign SEO Checks Before and After Launch

A website redesign needs an SEO review before launch and a follow-up afterwards. The core task is to make sure valuable information remains available at the intended addresses, the new pages describe themselves accurately and visitors can reach them through working links.

This is not a promise that rankings will stay unchanged. It is a way to reduce avoidable problems and make any later investigation more informed.

Start the review while the structure is still being planned. Waiting until the new design is approved can leave important decisions about old URLs, removed content and article archives unresolved.

Establish what the existing website contains

Build an inventory of public pages, articles, categories and important downloads. Use the sitemap as one input, but compare it with the actual content and navigation rather than assuming it is complete.

Identify pages that support enquiries or answer important customer questions. Ask the business team which documents and URLs they share with customers. These may matter even if they are not prominent in the main menu.

Record the existing title, main heading and purpose for important pages. This creates a reference for reviewing the redesigned version.

Do not treat the inventory as a requirement to preserve everything. It is a basis for making deliberate decisions instead of accidentally losing useful material.

Decide which URLs should remain

Where an existing address still suits the content, retaining it can avoid unnecessary migration work. If the structure needs to change, record the destination for each affected page.

Use a simple decision register: retain, move, merge or remove. Include the reason and the person who approved the decision.

Google's site-move guidance recommends mapping changed URLs, updating internal references and monitoring the move. When content has genuinely moved, a relevant permanent redirect can guide visitors to its replacement. Content removed without a replacement should return an appropriate not-found response rather than being sent indiscriminately to the homepage.

The business decision comes first. A redirect should represent a meaningful replacement, not conceal an unfinished content review.

Review the templates as well as individual pages

Shared templates can repeat a problem across many URLs. Inspect examples of service pages, articles, categories, search results and other public page types.

Check how the page title is assembled. A sensible article title can become unnecessarily long when the template adds a lengthy site name or repeats the category.

Check descriptions in the same way. A missing excerpt may trigger a fallback, and that fallback should be relevant rather than a fragment of navigation or code.

Review the main heading in the rendered page. A page title in the browser tab is not the same as a visible H1. Also look for duplicated main headings introduced by imported article content.

Make the page's identity clear

Each public page should communicate what it is about through its title, visible heading and introduction. These elements can differ in wording while remaining consistent in meaning.

Treat title and description length warnings as prompts to review clarity, not automatic instructions to cut every sentence at a fixed character count. Keep the important topic visible and remove unnecessary repetition.

Check the canonical URL against the intended public address. A copied template should not identify a different page as the preferred version by accident. Ask the developer to explain any deliberate exceptions.

Also check social sharing information and image paths. A proposed graph-image filename does not help if the corresponding file is missing or inaccessible when the page is shared.

Test journeys through the redesigned website

Start with the navigation, footer and calls to action. Then examine links inside article bodies, related-post lists and image cards.

Click through realistic journeys: homepage to service to contact, article to related resource, category to article, and mobile menu to an important destination.

Pay attention to links that look valid but point to obsolete route patterns. A new site may use a root-level article slug while older content still links through a retired news prefix.

Check anchor links too. A button pointing to a section should actually reach that section after the layout changes.

Record the source page as well as the broken destination. That makes the correction actionable.

Check search access without exposing private areas

Review the launch settings with the developer. Staging restrictions should not accidentally remain on pages intended for public discovery.

At the same time, a launch is not a reason to expose admin screens, previews or private material. Public visibility and access control are separate concerns and should be tested deliberately.

Check representative pages in their rendered form rather than relying only on source files. Confirm that meaningful page content and the intended metadata are present.

If a tool reports a successful response for a page that visibly says "not found", investigate the mismatch. A status code alone does not establish that the visitor reached useful content.

Give the sitemap a content review

The sitemap should reflect the current public site. Compare its entries with the approved page inventory and the actual route structure.

Look for obsolete sections, duplicate URL patterns and entries created from old content tables that the website no longer uses. A feature being disabled in navigation does not necessarily mean its URLs have disappeared from the sitemap.

Check that scheduled and draft posts are handled as intended by the publishing system. A future article should not be assumed public merely because a record exists for it.

For category pages, confirm that they serve a useful purpose and lead to appropriate content. Do not create or retain empty directories solely to increase the number of URLs.

Test the release before changing everything at once

Use a staging or preview environment to review representative pages and business tasks. Keep a record of the build being approved, so everyone knows which version passed testing.

Prepare a rollback plan and clarify who can make the launch decision. A redesign should not depend on one person remembering every environment setting during a rushed deployment.

Where possible, avoid combining unrelated changes in the same release. Changing the content structure, domain, hosting and design together makes problems harder to isolate.

The right process depends on the project, but the principle is consistent: know what is changing and how you will verify it.

Review the live site immediately after launch

Repeat the critical journeys on the actual domain. Check mobile navigation, enquiries, article pages, downloads and the pages used in current campaigns.

Compare the live output with the approved version. Cached pages, missing assets or deployment differences can produce behaviour that was not visible in staging.

Test old URLs included in the migration plan, as well as new destinations. Record unexpected responses and fix the underlying route or link rather than repeatedly clearing caches without evidence.

Confirm that the people responsible for enquiries and content editing can complete their normal tasks. Search presentation is only one part of a successful launch.

Monitor patterns rather than a single warning

During the following weeks, review available search and analytics information alongside technical checks. Look for patterns such as a group of pages losing access, a recurring route error or a template producing duplicated metadata.

Do not interpret every short-term change as proof that the redesign failed. Equally, do not dismiss a clear technical error because the homepage looks correct.

Keep a dated issue list with the affected URLs, evidence and owner. This turns follow-up work into a manageable process rather than an endless series of disconnected screenshots.

For a redesign that needs coordinated content and technical planning, explore 360 Design's web development offering. Contact the team with your current site, proposed changes and important page journeys so the review can be scoped around the website you actually operate.