SEO Before a Website Redesign: When to Get Involved

SEO is most useful before a redesign’s important decisions are fixed. Here’s how search input can fit into each project stage without taking over the redesign.

“Can SEO review the wireframes?” is often followed by a second request a few weeks later: “Can you check the staging site before launch?”

Both reviews are useful. The problem is that, by the time SEO sees the wireframes or staging site, the important decisions may already be settled. The new page structure has been approved, content has been cut, URLs have been assigned, navigation has been built and analytics requirements have been turned into tickets. SEO may still identify risks, but fixing them can mean reopening decisions across design, product, content and development.

SEO works best in a redesign as a series of decision gates, not a final inspection. It should provide evidence and requirements while the relevant decision is still open. Design, product, content and development still own their areas of work; SEO helps the team understand how those choices may affect discoverability, organic demand and measurement.

This guide explains what SEO should contribute at each stage, who needs to be involved and what should exist before the project moves on.

Why timing matters, without overstating the risk

A redesign can change much more than a website’s visual appearance. It can alter the pages that exist, the relationships between them, their URLs, the links that connect them, the content available to users and search engines, and the way visits and conversions are recorded.

Google’s documentation recommends making important pages reachable through crawlable links, rather than relying only on site search or interactions that crawlers may not perform. It also explains that internal links can help Google understand relationships between pages and their relative importance within a site. Google’s guidance on site structure and ecommerce navigation is written for ecommerce, but the underlying planning question applies more broadly: can people and search systems find the pages that matter?

That does not mean every late change is disastrous, or that early SEO involvement guarantees rankings or revenue. Research into delayed software issues has not established a consistent cost increase across every project. One study examined 171 projects and did not find a consistent general delayed-issue effect. The study’s findings are a reason to avoid universal claims about exponential late-stage costs.

The narrower, more defensible point is that a decision embedded in templates, content, redirects, analytics and release planning may leave the team with fewer practical options. The aim, then, is not to bring SEO into every meeting. It is to involve SEO in the meetings where search-related decisions are being made.

Gate one: discovery and search-demand review

The business risk

The project may start with a reasonable objective such as “make the site simpler” or “improve conversion”. Without an early search review, the team can simplify away useful demand, misread the purpose of existing pages or treat organic traffic as a single undifferentiated number.

Historical performance is not automatically a blueprint for the future. An old structure may be awkward, duplicated or poorly aligned with the business. It should be treated as evidence, not a museum exhibit. The team still needs to understand what it is changing before deciding what to remove or combine.

What SEO contributes

• A view of important organic landing pages and page groups.
• Search-demand themes mapped to customer needs, products, services or topics.
• Evidence of pages that attract organic visits, conversions, links or assisted journeys.
• Questions about pages that appear weak but may serve a distinct purpose, alongside pages that may overlap or compete with one another.
• Known market, brand, seasonal or technical factors that could affect interpretation of the baseline.

Google’s people-first content guidance recommends creating useful content for an intended audience and using the language people would use when looking for information. That includes prominent elements such as titles, headings, alternative text and link text. Google’s guidance on creating helpful content can inform the review, but it does not decide the business’s content strategy.

Who should be involved

SEO, the product or redesign lead, analytics, content and relevant commercial stakeholders should take part. UX research and customer-service teams can add useful evidence about how customers describe their needs and where the existing experience fails.

What should exist before moving on

The practical output is a short discovery brief, not a giant keyword spreadsheet. It should identify priority search themes, important page groups, known content dependencies, baseline measures and open questions. It should also state what the evidence cannot tell you. Search data cannot choose the best conversion journey, accessibility solution or brand proposition on its own.

Gate two: information architecture and page relationships

The business risk

A redesign can produce a tidy menu while making important content harder to find. Pages may be buried, merged into a generic hub or made available only through filters, search or a client-side interaction. The result may be cleaner for one journey and less discoverable for another.

This is an inference from how crawlable links and page relationships work, rather than a claim that one navigation pattern always ranks better. The best information architecture must also reflect user research, business priorities, accessibility and platform constraints.

What SEO contributes

• A proposed relationship between priority topics, categories, services, products and supporting content.
• Search-informed questions about labels. Would a customer looking for “self-employed pension advice” understand a navigation item called “Solutions”, for example?
• Requirements for important pages to be reachable through ordinary crawlable links where appropriate.
• A list of pages that need clear parent, sibling or supporting relationships.
• Risks created by relying exclusively on internal search, filters or interactions to expose important content.

The W3C guidance on making pages navigable also supports the broader need for clear headings, labels and ways to locate content. User findability and search-engine understanding are related, but they are not the same measurement.

Who should be involved

UX, product, SEO, content design and engineering should agree the structure together. SEO should not dictate the number of menu items or turn the navigation into a list of keywords. Its role is to bring evidence about demand, page purpose and discoverability to the design decision.

What should exist before moving on

Agree a page and relationship model for the important parts of the site. This might include a sitemap, content model, navigation principles or annotated wireframes. The useful question is not simply “does this page have a link?” It is “can a customer and a search engine understand where this page belongs, why it exists and how to reach it?”

Gate three: URLs, content and templates

The business risk

At this stage, the project decides which pages will remain, merge, move, be rewritten or disappear. It also starts turning page designs into reusable templates. A late decision to change the URL model or restore removed content can then affect copy, components, redirects, development tickets and release timing.

URL changes are not automatically harmful. A new structure may be justified by consolidation, replatforming or a better content model. The risk comes from making changes without understanding which old pages map to which new purposes.

What SEO contributes

• A recommended treatment for important existing URLs: retain, update, consolidate, redirect or retire.
• Requirements for distinct page purposes where search demand and user needs are genuinely different.
• Content requirements for priority templates, including titles, headings, useful body content, link text and image alternative text where relevant.
• Questions about whether a template gives each page enough room to be useful, or creates hundreds of near-identical pages.
• A preliminary old-to-new URL mapping for pages expected to move.

When URLs do change, Google recommends permanent server-side redirects for moved pages. Its site-move documentation also supports planning URL changes rather than discovering them at launch. This does not mean every old URL needs to survive, but it does mean the intended destination of important content should be explicit.

Google’s guidance on people-first content also supports using language that reflects what users are looking for. That is a reason to involve SEO and content early in template and copy decisions, not a reason to create one thin page for every slight keyword variation.

Who should be involved

Content, SEO, UX, product, engineering and legal or compliance stakeholders where relevant. The product or content owner decides what the site should say and which journeys matter. SEO helps show what may be lost or confused if pages and purposes change.

What should exist before moving on

There should be an agreed content and URL decision log for priority page types, plus clear exceptions. A perfect mapping of every URL may not be possible this early, particularly on a large site. The important thing is to identify the model, the high-value pages and the owner responsible for resolving edge cases.

Gate four: technical design, navigation and rendering

The business risk

A page can look complete in a design file while the built experience depends on content or links appearing only after a user action. A new application-style navigation system might also change browser history and the way page views are recorded. These are technical design decisions, not just launch checks.

Google processes pages through crawling, rendering and indexing. Its JavaScript documentation explains that Google can render JavaScript, but also describes situations where blocked resources, application shells or implementation choices affect what can be processed. Its guidance on lazy-loading warns against making important content dependent on user actions that crawlers may not perform. Google’s JavaScript SEO guidance and lazy-loading guidance are useful references for this conversation.

What SEO contributes

• A list of content, links and metadata that must be available in the rendered page experience.
• Questions about whether important navigation and page content work without a crawler needing to imitate a particular user gesture.
• Requirements for canonical signals, indexability controls and consistent internal links across templates.
• Testable acceptance criteria for the chosen rendering approach, rather than a blanket demand for one technology.

JavaScript is not automatically an SEO problem, and SEO should not prescribe server-side rendering for every site. The useful agreement is practical: what must be available, how will it be rendered and how will the team prove that it works?

Who should be involved

Engineering, architecture, product, UX, analytics and SEO. Development owns the implementation approach. SEO contributes search requirements and helps identify where a technical choice could affect discovery, interpretation or measurement.

What should exist before moving on

Document the rendering and navigation assumptions for priority templates. Add them to technical acceptance criteria or tickets with named owners. If an important interaction is deliberately client-side, record how its content, links and tracking will be tested.

Gate five: measurement and baselines

The business risk

A redesign can perform perfectly while reporting becomes impossible to interpret. It can also appear to fail because page views, conversions or page groups no longer follow the old structure.

Google Analytics documentation identifies browser-history changes and single-page application behaviour as cases where page-view measurement may need controlled configuration to avoid missing or duplicate views. The GA4 documentation on page views provides the technical context, although the exact implementation depends on the analytics platform, framework and tagging setup.

What SEO contributes

• A list of organic landing-page groups and business outcomes that need to remain measurable.
• Baseline measures for the agreed period, with notes on seasonality, campaigns and known tracking limitations.
• Requirements for distinguishing new templates, markets, categories or content groups in reporting.
• A plan for documenting intentional changes to conversion definitions, event names or page classifications.

The aim is not to preserve every historical metric unchanged. A redesigned site may have better page groups or a better conversion model. The aim is to make the change visible enough that performance can still be understood.

Who should be involved

Analytics, marketing, product, engineering and SEO. The analytics owner should lead the measurement design. SEO makes sure organic landing pages and search-related outcomes are represented in the plan.

What should exist before moving on

Agree a measurement plan and baseline pack. Include the definitions that will change, the ones that will remain comparable and the first review window after release. This prevents the team from arguing about numbers after launch when it should be investigating the experience.

A compact example: a cleaner site with less visible search coverage

Imagine a financial education publisher redesigning its site. The new design replaces several topic hubs with one visually minimal “Learn” page. Articles remain accessible through a filter component, and the old article URLs are removed because the team wants a shorter structure. The new analytics setup reports the entire learning journey as one application-style page view.

The design may be attractive and the user journey may work well for some visitors. But if SEO is involved only during the staging review, the team may discover several dependencies at once: distinct topic relationships are harder to expose through ordinary links, old URLs need clear destinations, useful content may depend on an interaction and reporting can no longer separate topic groups.

SEO did not need to reject the visual direction. Earlier involvement could have prompted better questions: which topic pages need to exist independently, how should the new structure connect them, which URLs are being intentionally retired and how will organic journeys be measured after the change? The example is synthetic. It demonstrates possible search and measurement risks, not a prediction that the redesign would lose traffic.

Gate six: pre-launch readiness and release QA

The business risk

The project may have sound decisions on paper but incomplete implementation. Redirects may not match the agreed mapping, rendered content may differ from the design or analytics events may behave differently in production.

What SEO contributes

At this point, SEO validates agreed requirements. Typical checks may include priority URLs, redirects, rendered content, canonical signals, robots directives, sitemap output, important internal links and analytics events. These are implementation checks, not a substitute for deciding the information architecture or content model earlier.

Google’s launch guidance supports checking key technical and site-move considerations around release. Some checks also need to be repeated after launch because live hosting, deployment and indexing conditions can differ from staging.

Who should be involved

Development, QA, product, analytics, SEO and the release owner. Each team should know which failures block release, which can be fixed immediately afterwards and who can make that call.

What should exist before moving on

A readiness decision, with open risks, owners, severity and an agreed response. A long list of observations is less useful than a clear answer to three questions: is the site ready, what is deliberately different and what will be watched after release?

For a detailed implementation-level process, see our guide to SEO release QA before and after launch. It covers the checks themselves; this article is concerned with when those checks should enter the redesign conversation.

Gate seven: post-launch observation

Launch is not the end of SEO involvement. It is the point at which the team can compare the live implementation with the agreed model and observe how search systems and users respond.

Review the agreed baselines, crawl and indexation signals, priority landing pages, redirects, organic conversions and analytics integrity. Allow for normal indexing delay, seasonality, competitors, demand shifts, algorithm changes and hosting or tracking problems before attributing every movement to the redesign.

If the redesign changed navigation, it can also be useful to compare the intended and live page relationships. Our deeper guide to diagnosing internal-link changes after a redesign covers that narrower problem without turning every post-launch fluctuation into a redesign verdict.

What belongs in a redesign SEO readiness pack?

A useful pack should help a project team make decisions, not create another document nobody opens. Its contents will vary, but it might include:

• Search and business context: priority demand themes, landing-page groups, commercial outcomes and baseline notes.
• Architecture decisions: proposed page relationships, navigation principles, labels and known exceptions.
• Content and URL decisions: priority page treatments, template requirements and an old-to-new mapping for important moved pages.
• Technical requirements: rendering assumptions, crawlable links, indexability controls, canonical requirements and sitemap expectations.
• Measurement plan: events, conversions, page groups, baselines and intentional reporting changes.
• Readiness criteria: staging checks, production checks, owners, release blockers and post-launch review dates.

This is a practical synthesis, not an industry-standard document or a replacement for a detailed migration plan. Its value is that it makes dependencies visible and gives each team something specific to accept, challenge or implement.

How much SEO involvement is proportionate?

A small redesign with a handful of URLs, stable architecture, simple rendering and limited template variation may be manageable through a focused in-house review. SEO may need to attend only the discovery, architecture and readiness discussions, with the rest captured in a concise brief.

A larger redesign is likely to create more dependencies when it involves multiple markets, thousands of URLs, several templates, a replatforming project, application-style navigation, complex analytics or many delivery teams. In those circumstances, specialist support can be useful for diagnosing risk, prioritising commercial importance, translating requirements into implementation work and validating the result. This is a proportionality judgement, not a universal threshold.

That does not make SEO the owner of the redesign. The strongest projects keep ownership clear: product owns product decisions, design owns design decisions, development owns implementation and release, content owns editorial decisions, and SEO contributes evidence about search demand, discoverability and organic measurement.

Liquid Silver helps businesses bring those inputs together when a redesign is large enough, ambiguous enough or risky enough to need structured diagnosis and implementation support. You can find more about our SEO implementation support here.

Make SEO part of the decision, not the post-mortem

The most important distinction is between decisions and checks. URL changes, page relationships, content scope, navigation behaviour, rendering assumptions and measurement models need SEO input while they are still being shaped. Redirect validation, rendered-page checks and analytics testing can then happen in staging and at launch.

Early SEO involvement is not a promise of better rankings. It is a way to preserve options, surface dependencies and give the redesign team a clearer view of what it is choosing. That makes SEO more useful, not more controlling.