← Useful
28 October 20267 min read
News

Make SEO a launch requirement when redesigning the corporate website

A redesign can look finished while simultaneously weakening search visibility. With a clear SEO gate before launch, you can uncover critical issues while they are still easy to fix.

Category: SEO

A new corporate website is often assessed based on its design, functionality and whether the forms work. SEO is typically checked late, after the structure, page types and content have already been decided. By then, errors can be costly to fix, even if each individual error seems minor.

The solution is to make SEO a specific launch requirement. Before the website goes live, the project team must be able to document that important pages are accessible to search engines, address the right search intent, form part of an understandable structure and provide a good user experience. This is not a single SEO test, but a quality gate with clear criteria for what must be in place.

SEO-krav bør gjennomgås før lanseringsbeslutningen tas.
SEO requirements should be reviewed before the launch decision is made.

Start with the pages that matter most to the business

It is rarely necessary to check every page equally thoroughly. Start with the pages that matter most for visibility, demand and sales. These may include service pages, product pages, category pages, location pages and expert content that already attracts relevant visitors.

Create a prioritised list before development begins. For each page, you should record:

  • which customer need the page should address
  • which search intent it fulfils
  • which business goal it supports
  • whether existing visibility and content should be preserved
  • which page type and position it will have in the new structure
  • which pages should naturally link to and from it

This list becomes the project’s SEO foundation. It prevents important pages from disappearing because they look outdated, or from being merged without anyone assessing the need they actually fulfil.

Check that the information architecture follows the user’s task

An organisation is often structured around departments, areas of expertise and internal lines of responsibility. Customers’ searches do not necessarily follow the same logic. Visitors are looking for a solution, a deliverable, an answer or a way to compare alternatives.

The new information architecture should therefore be tested against real tasks. Can a potential customer understand the difference between the services? Are related topics grouped together? Are the most important pages accessible through the navigation, or do they exist only because someone knows the URL?

Viktige sidetyper må testes på både mobil og større skjermer.
Important page types must be tested on both mobile devices and larger screens.

A useful check is to give people outside the project team specific tasks. Ask them to find the right service, understand who the offering is for and find the next step. If they need to know the organisation’s internal terminology to succeed, the structure is probably not clear enough.

This matters for SEO because structure creates coherence. It helps search engines understand which pages are central, how the topics relate to one another and which page should be shown for a particular need.

Assess search intent before approving the copy

A page can be well written without being useful in search. The most common reason is that the copy describes the organisation while the user is looking for help choosing or solving something.

Assess each priority page based on what a person expects to find. A service page should usually explain what is delivered, who it is for, which problems it solves, how the process works and what the next step is. A comparison page must make the differences clear. A guide must provide an actual answer, not merely direct users to a contact form.

Ask three questions before approving the page:

En tydelig sidestruktur kobler kundebehov til riktig innhold.
A clear page structure connects customer needs to the right content.
  1. What specific question or need brought the user here?
  2. Does the user get a clear answer without having to visit several random pages?
  3. Is the next step natural based on the intent, or does the page push for an action too soon?

If the project team cannot answer precisely, the page should not be considered content-complete.

Test internal linking as part of the content

Internal linking is often treated as tidying up after publication. That is a weak approach. Links affect both how people move through the website and how search engines perceive the relationship between pages.

Every important page should receive relevant links from other thematically related pages. A service page might, for example, receive links from a higher-level category page, relevant expert articles and customer stories. At the same time, the service page should link onward to content that helps users make their assessment.

Also check the link text. Text such as “read more” and “click here” says little about the destination. Descriptive link text makes the choice clearer and provides better context.

Before launch, you should specifically identify orphaned pages—that is, pages with no incoming internal links. A page that exists only in the sitemap is technically accessible but poorly integrated into the website.

Create a technical SEO gate with measurable requirements

Technical SEO should not be approved with a general statement that the website “looks right”. Use specific criteria that can be tested in the staging environment and checked again after launch.

Indexing and crawling

  • Important pages must be able to be indexed.
  • Staging environment restrictions must not carry over to production.
  • Pages that should not appear in search must be handled deliberately.
  • The sitemap must contain canonical, indexable pages.
  • Canonical signals must point to the correct version of the page.

URLs and redirects

  • Old URLs with value must point directly to the closest relevant new page.
  • Redirects must not end in chains or loops.
  • Deleted pages should not automatically be redirected to the homepage.
  • Internal links should use the new URLs instead of passing through redirects.

Page titles and main content

  • Priority pages should have unique and descriptive page titles.
  • Each page should have a clear main topic and a logical heading structure.
  • Templates should not create empty pages, duplicates or identical metadata at scale.
  • Important text should be accessible without requiring the user to take unnecessary actions.

It should be clear who is authorised to approve each area. If everyone is merely “keeping an eye on things”, it is easy for no one to make the decision to halt the launch.

Test Core Web Vitals on representative page types

A fast homepage is not proof that the entire website works well. Different page types may have different images, components, forms, filters and third-party services. Therefore, test representative examples from each important page type.

Core Web Vitals focuses attention on three aspects of the user experience: how quickly the main content becomes visible, how responsive the page is when the user interacts with it, and how stable the content remains while the page loads.

Pay particular attention to large hero images, fonts that delay rendering, buttons that respond slowly, consent solutions that block the page, and elements that shift after loading. Such issues should be linked to specific components and templates. Otherwise, you risk optimising one page while the underlying problem remains.

Measurements from a controlled testing tool are useful before launch, but they do not replace data from actual users. After launch, you must monitor development over time and examine differences between mobile devices and larger screens.

Define what actually stops the launch

An SEO gate only works if the project has decided in advance which deviations are critical. Otherwise, every finding will be discussed under time pressure, and the launch date will often prevail.

Issues that would normally warrant stopping a launch include central pages being blocked from indexing, important old URLs lacking redirects, navigation failing to lead to priority pages, or the main content not being readable as expected. Minor improvements to wording can generally be planned for later.

Divide the deviations into three levels:

  • Stop: The error may lead to loss of visibility, inaccessible content or broken user journeys.
  • Fix before launch: The error significantly reduces quality, but can be weighed against risk and time required.
  • Improve after launch: The measure is useful, but the website can be published without it being complete.

Each deviation must have an owner and a deadline. A long report without ownership provides little protection.

Repeat the checks after the website has been published

Some errors only occur in production. Settings may be different, redirects may behave unexpectedly, and external services may affect performance. Therefore, repeat the most important tests immediately after launch.

Check that priority pages respond as expected, can be indexed, have the correct canonical signals and receive internal links. Test forms and key user journeys. Also monitor whether the search engine encounters an unexpected increase in broken URLs or other technical errors.

A further check should be carried out after search engines and users have had time to encounter the website. This allows you to assess actual performance data, changes in visibility and whether users can find their way around as the structure was intended.

The SEO gate turns the launch into a decision

Good SEO during a redesign is not about adding a few keywords just before publication. It is about preserving value, making the website’s structure understandable and ensuring that important pages meet real needs.

When the criteria are defined early, SEO becomes part of project management. Designers know which templates must work. Developers know which technical requirements need to be tested. Content owners know what a finished page must contain. Management gets a clearer basis for deciding whether the website is actually ready for launch.