Websites & SEO / 04
Website redesign and SEO: keep the customer journey intact
The new website looks excellent. An old service link no longer works, the language switcher returns to the homepage, and enquiries are harder to track. Here is what to preserve and verify so the redesign helps the business.
A better-looking website can still lose enquiries
The new homepage is faster, the cards look sharper and everyone likes the mobile menu. A few weeks later, enquiries from search have fallen. The cause may have little to do with the colour of a button. An important service has moved to a new URL, a partner link now opens a missing page, and the language switcher sends readers back to the homepage.
A website redesign is also a change to a working system of pages, links and customer journeys. Before commissioning layouts, establish what that system already does well. Which pages introduce the business? Which answer a detailed buying question? Which help someone take the final step? Those roles matter more than whether the old navigation looks tidy.
This guide follows a service website through that decision. The examples are hypothetical, not client results. No migration checklist can promise unchanged rankings, but a careful inventory and a repeatable launch test can expose avoidable mistakes before customers encounter them. The aim is a website that looks considered and still does its everyday work.
Record the starting point before changing the structure
Collect the existing URLs from your sitemap, internal links, analytics and available Search Console reports. Record the language, subject, main action and useful performance data for each important page. Do not limit the inventory to the current menu. An older article may receive qualified visitors even if nobody inside the company remembers linking to it.
Look beyond raw page views. A detailed page about one integration might attract few people but help precisely the customers you want. A broad introductory article might attract many visitors who are not looking for your services. Record enquiries and relevant assisted journeys where your measurement allows it, while keeping gaps in the data visible.
Save titles, descriptions, headings, substantive copy and important internal links. This is a baseline, not a demand to preserve every old sentence. After launch, it lets you distinguish a change in presentation from a change in the answer you give. Without it, a missing paragraph or service page can become an expensive guessing exercise.
Record
URLs, search queries, enquiries and working forms.
Map
Give every old address a deliberate outcome.
Verify
Languages, redirects, indexing and the complete enquiry journey.
Observe
Compare equivalent pages and periods after launch.
If a form breaks or a key page goes offline at launch, a named owner should handle the fix or rollback.
Give every old URL a deliberate destination
For each existing address, decide whether to retain it, move it to an equivalent page, consolidate it with closely related material or remove it. Base that decision on the visitor’s original need. Sending every retired service page to the new homepage is convenient for the implementation but rarely provides an equivalent answer.
Google recommends permanent server redirects for moved pages and a direct route to the final destination. In practical terms, a link to an old audit page should open the relevant new audit page. Avoid chains through several intermediate URLs. A redirect is a route for a person as well as a signal for a crawler.
Ask for the mapping as a reviewable table and test its rows against the actual server. Check the response status, final destination and absence of loops. Include a few links with campaign parameters and older language paths. A correct spreadsheet does not prove that the deployed routing rules behave the same way.
Scroll sideways to see all columns.
| Page situation | Action | Verification |
|---|---|---|
| Address and content stay | Keep a 200 response | Self-referencing canonical and internal links |
| An equivalent replacement exists | Use a permanent 301 or 308 redirect | One hop to the final URL returning 200 |
| Content is merged | Redirect to the relevant consolidated page | The destination answers the original search intent |
| Content is removed without a replacement | Return 404 or 410; remove from the sitemap | Do not redirect everything to the homepage |
Preserve the answer behind the search query
An old automation page may explain document formats, review queues and delivery criteria. Its replacement might say only “Build the future” above a contact button. The new composition is cleaner, but a buyer can no longer tell what the service includes. Removing useful detail changes the page’s purpose, even if its title stays similar.
Identify the intent of each important page. Is the visitor selecting a supplier, comparing approaches, investigating cost or solving a specific problem? Write to that task. Relevant terms belong naturally in service names, examples and explanations. A page about business automation should explain the work, not merely repeat the phrase in different combinations.
Separate distinct subjects when they need different answers. AI agents, custom web development and MVP delivery can have their own pages, with contextual links between them. The blog can explore a decision in greater depth. That structure gives a reader a useful next step without forcing every service and keyword into one generic block.
Let the homepage introduce rather than explain everything
The homepage helps a visitor recognise the company and choose a direction. A service page explains a particular engagement. An article helps someone think through a question before they are ready to buy. Keeping these jobs clear usually makes both the navigation and the writing easier to assess.
For a service, describe who it suits, what is delivered, what inputs are needed and how the result will be checked. Evidence should be real and attributable. If you use an illustrative scenario, label it accordingly. Invented client numbers do not become credible because they sit inside a polished case-study card.
Link where the reader needs more context. An article about automation costs can lead to the automation service; that service can point back to the calculation for someone still comparing options. Review the wording of the link itself. It should say what the destination helps with, rather than repeatedly asking people to “learn more”.
Treat language switching as part of the customer journey
Open a detailed service page and change the language. If an equivalent translation exists, the visitor should reach that same subject. Returning them to the homepage discards the work they have already done. For long articles, the difference is particularly noticeable: the reader wants the same material in another language, not a fresh search.
Hreflang annotations identify related language or regional versions. Their relationships should be consistent and point to available equivalents. The annotation does not translate the content or establish local relevance on its own. The visible text, service terminology, contact route and applicable commercial information still need to make sense for the intended audience.
A language is not a country. One English edition can serve readers in several markets. A regional edition makes sense when there is a meaningful difference to explain. Replacing a country name across dozens of otherwise identical pages adds little for a buyer. Start with genuine content differences rather than a target number of regional URLs.
Check canonical URLs against the final production site
A canonical URL indicates the preferred representative of duplicate or very similar pages. After a redesign, it should align with the intended live address. A common template mistake points every service at the homepage or leaves the preview domain in the metadata. Because the mistake is shared, it can affect many pages at once.
Inspect the server HTML for a homepage, service, article and translated equivalent. Then test the full set automatically. Compare canonical URLs with internal links and the sitemap. Conflicting signals make the configuration harder to understand and maintain. Adding another tag does not resolve a disagreement between the existing ones.
Do not use canonical tags to collapse complete translations indiscriminately into English. A language edition generally needs a suitable canonical in that language, while hreflang expresses the relationship between editions. Review these decisions together so that the template, language switcher and sitemap all describe the same site structure.
Make the content available before the visual effects finish
Load an article over a slow connection and inspect when its heading, body and links appear. Also inspect the HTML returned by the server. Editorial content is well suited to being available immediately. Reading a guide should not depend on a large animation or an unrelated third-party script completing successfully.
JavaScript can still support forms, calculators and useful interactions. The question is which dependencies are necessary for the main task. Keep a clear distinction between the article itself and enhancements around it. That makes failures easier to contain and helps the page remain usable under ordinary network and device constraints.
Check that page-to-page navigation uses real links with meaningful addresses. Readers may open a service in a new tab, copy a reference or follow it with a keyboard. Buttons are appropriate for actions; links are appropriate for destinations. This small implementation choice affects the reliability of the whole journey.
Start performance work with the first useful action
A large video or three-dimensional scene may look excellent on the designer’s computer. Test the same page on an ordinary phone and a mobile connection. Can the visitor understand the offer? Can they use the main action? Does text move when an image or font arrives? Those observations give the performance work a concrete purpose.
Core Web Vitals cover loading, responsiveness and visual stability. Consider laboratory checks alongside available field data from real visits. One fast test run is not a complete description of the audience’s experience. Investigate the actual elements and interactions behind a poor result rather than treating a single score as the product.
Set dimensions for media, review font loading and postpone resources that are not needed initially. Examine the client-side code required by a reading page. The visual concept can often remain intact when its loading order improves. A premium experience includes the time before everything has finished loading, not only the final screenshot.
Test mobile layouts with real translated copy
A short English heading can become much longer in German, Polish or Ukrainian. Use the actual translations when checking cards, navigation and calls to action. Important words should not disappear behind fixed heights, narrow controls or decorative overlays. A layout that works only with placeholder text is not ready for a multilingual release.
Walk through the main action on a narrow screen. Check whether the chat launcher covers the submit button, whether the keyboard hides validation feedback and whether a language menu can be dismissed. Test tap targets and visible keyboard focus. These details influence completion far more directly than a subtle background transition.
Long articles need a comfortable line length, readable contrast and links to useful sections. On a phone, a collapsible contents panel can keep the opening concise while preserving navigation. Readers should be able to return to a particular calculation or checklist without scrolling through the entire guide again.
Follow an enquiry all the way to its owner
Search traffic is not a business result if the form silently fails. Test the journey from entering a message to the final record, acknowledgement and notification to the responsible person. Use an agreed test environment or clearly labelled test data. A success message in the browser alone does not prove that the enquiry arrived.
Try a missing field, a second click and a temporary server failure. The visitor should understand whether the submission succeeded and what to do next. Preserve their message until success is confirmed. Losing a carefully written brief because of a transient error undermines an otherwise polished experience.
Distinguish a button click from a received enquiry in analytics. Confirm that a new route does not count the same submission twice or lose the event after navigation. If the measurement changes at the same time as the design, document it. Otherwise the before-and-after conversion comparison may describe instrumentation rather than customer behaviour.
Align metadata with what readers actually see
Give each page a specific title and description appropriate to its subject and language. The title helps someone recognise an answer before opening the page. A list of every service you offer is usually less informative than a clear description of this particular resource. Keep the visible heading and search presentation meaningfully connected.
Article structured data can describe the headline, author or organisation, dates and image. Those fields should reflect the published material. Do not refresh modification dates without a substantive change or invent an expert biography to create authority. Consistency between the visible page and its metadata is easier to maintain when both use the same content source.
Inspect the link preview as well. The URL, title, description and image should represent the page being shared. A guide that appears to be the homepage is harder to recognise. These checks fit naturally alongside canonical and language validation, rather than becoming a separate last-minute task.
Separate preview protection from production indexing
The sitemap should list the live URLs intended for discovery. Exclude accidental parameter variants, preview pages and addresses that simply redirect elsewhere. Request the URLs and verify their responses. Reading the XML proves that the file is well formed; it does not prove the destinations work.
A preview environment may appropriately block indexing. Before launch, confirm that those settings have not reached the public pages. Inspect robots.txt, page metadata and HTTP response headers. They have different functions, and a single checkbox in an administration panel may not describe the entire deployed configuration.
Private areas need access control independently of search directives. Noindex is not authentication. Keep a clear inventory of public marketing pages so the release test can distinguish them from administration screens and customer accounts. This prevents a broad indexing change from being applied to routes with very different purposes.
Use a small, complete test on launch day
Choose examples of every important template: homepage, service, article, contact path, translated page and an old redirected URL. Open them on the actual production domain after release. Check the content, status, language, canonical URL and primary action. A successful build does not prove that domain and environment configuration are correct.
Check forms and notifications in the agreed testing mode. Production service credentials and allowed domains may differ from the preview setup. Name the person who can correct a failed integration. A launch plan should include that operational handover, not just the command that publishes the files.
Retain a practical rollback option and agree when to use it. A broken enquiry flow needs a different response from a minor spacing issue. Having that distinction in advance keeps the release discussion focused on customer impact. The decision becomes clearer when it is based on a complete journey rather than isolated screenshots.
Compare like with like after the redesign
Start with technical evidence: unavailable pages, redirect errors, indexing changes and form failures. Then examine entry pages, search queries and completed enquiries. Aggregate traffic can hide a problem in one service or language while another grows. A useful review follows the structure of the website and the decisions people make on it.
Allow for seasonality, campaigns and changes to the offer. If pricing, acquisition channels and design all changed together, attribution will be limited. Your saved baseline helps separate obvious technical regressions from broader changes. Keep those limits visible instead of assigning every movement to the redesign.
Do not rebuild pages in response to every daily fluctuation. Gather enough evidence for the particular decision. Equally, there is no reason to wait for a trend when a known service URL returns an error or the contact form fails. Repair an observable defect, then measure the wider outcome.
Ask for a website the team can keep maintaining
Alongside the finished design, request the public route inventory, URL mapping, language rules, verification results and release instructions. These are working materials for the next person who updates the site. They need to explain the decisions clearly, not fill a large handover document nobody can use.
Try adding an unpublished article and changing its title. Confirm that the page, card and metadata update consistently. If each edit requires copying the same information into several files by hand, drift becomes more likely. A sound publishing structure makes the correct result repeatable for ordinary editorial work.
Finally, assign responsibility for content reviews and broken-link reports. A redesign is one release in the life of a website. Its quality becomes visible again when a new service is added, a language expands or an old guide needs correction. The best handover leaves the company able to make those changes deliberately.
Before you start
- Save important URLs, content and baseline performance data.
- Agree URL mappings, language journeys and acceptance criteria.
- Test search configuration and the complete enquiry flow on the live domain.
Editorial note. Examples illustrate a decision or a test; they are not client results.