Website relaunch and SEO: a checklist for a safe transition
Reading time: about 5 minutes for the main text. Use templates and details as needed.
Full version with templates, calculations and further checks
After a website relaunch, an old link should still take visitors to the right service. A prospective customer needs practical answers there and a working way to get in touch. For your trades business, this means agreeing before launch which content to keep, where old addresses will lead and who will check the result.
Here, ‘safe’ means checking the important steps. Search traffic and Google rankings can change even when a move has been carefully prepared. This does not allow anyone to promise a particular position in the search results. [1]
What to keep from your existing website
Start with the problem the changes should solve. Perhaps customers struggle to find a service or complete the form on their phone. This gives you a brief with an outcome you can check. The website’s age alone says little about what needs to change.
For bathroom renovation, the outcome is easy to describe: the service is accessible from the overview, its scope is correct and the way to make an enquiry is clear. Include this in the brief before design work begins. The guide to page planning for trades businesses helps you agree the content you need with your provider. [b]
Go through the existing pages with the team doing the work. Useful service descriptions and relevant project examples should keep their place in the new design. Your business checks the scope of services and the area you actually cover. Project photos also need approval for publication. Missing visitor data alone is not a good reason to remove a useful page. [b]
The inventory also includes important images, PDFs and earlier downloads. Your business records what is still needed and which projects may be shown. If search data or old addresses are still incomplete, keep that gap visible in the worksheet. The team can then fill it in. [b]
A redesign mainly changes the appearance; a relaunch may also change the content and technology. If you also plan to change the domain name and content management system, Google recommends making these changes one at a time where possible. [1]
Before making changes, save the available search data along with the date range and filters used. Using the same settings later will help you compare the results. [2]
Use the page list as a shared working document
A URL is the full address of a page. Record a decision beside every old URL: keep, revise, merge or remove. If the address changes, add the destination beside it. The visible menu is not a complete inventory; the team adds technical sources and known old links. [1]
The downloadable URL mapping worksheet (CSV) helps you collect this information. It contains four fictional cases on handwerk.example. Replace the examples with your full URLs and add the person responsible and the check date. When importing, use UTF-8 and a comma as the separator. The CSV does not set up redirects; its sample rows with an open status are not passed tests. [a]
In the fictional example, /barrierearmes-bad/ moves to /badsanierung/barrierearm/ on the new site. The new page must still explain what work is possible to make a bathroom more accessible. ‘We create your dream bathroom’ would lose those answers. Sign-off therefore involves checking both the route to the destination and the content found there. [a]
The short paths in the example stand for full addresses including the domain. In the CSV, you will therefore find https://handwerk.example/barrierearmes-bad/ and https://handwerk.example/badsanierung/barrierearm/ paired in one row. The check_evidence field describes the check of the direct route and the retained service information. The team adds the technical expectations. A blank owner field or a test that is only planned cannot yet be ticked off. [a]
What you need from the team doing the work
Your page list needs a traceable check result. Ask the team to record whether each old link works as agreed and reaches the right destination. Simply opening any page is not enough: someone looking for a particular service should find the explanation for it. Redirecting everything to the homepage does not replace this mapping. [1]
For your own sign-off, open the old link and read the page you reach. For the more accessible bathroom, compare the practical answers on the old page with the new text. If only a general advertising claim remains, this content item is still open, even if the link works. The log should then state what information is missing and who will add it. [a]
You assess the service information. The team checks the technical work and records errors. Areas that are deliberately protected stay protected. Only accidental blocks on pages intended to be public should be removed. The detailed redirect checks and the technical checks can serve as a working brief for your provider. [b]
You can copy this short brief to help agree the work: [b]
For each old page address, please add whether it will stay, which relevant page it will lead to in future, or why it will be removed. Show us on the important service pages that the previous service information has been retained and that the contact route works. Record your checks with the date and the person responsible. Check the published website again after launch. Protected areas must stay protected. List any unresolved errors and who will fix them.
You can also use this text to assess the quote. It should make the inventory review and the work to be done clear, including work on old links and the agreed follow-up checks. Also clarify what service information or approvals your business will provide. A general brief for a ‘new website’ leaves these tasks open. [b]
Does the enquiry reach your business?
Open an important service page on a smartphone. Is the text readable? Can you reach the contact option without a button being covered? The phone number must also remain easy to find.
Also follow the route through the menu and a relevant project example. Bathroom renovation should be accessible from the service overview; a bathroom refurbishment project should lead back to the right service. If content shifts while project images load or a contact button is covered, record that observation as a specific error in the log. [b]
Complete the form and send a clearly labelled test enquiry. Check the error messages too. Someone in your business should then confirm receipt in the correct inbox. A success message on the website alone is not enough. Record the page and result in the check log. [b]
And repeat this route on the published website. The preview may be configured differently. The enquiry form guide helps you check in more detail.
When the new website is ready to launch
Agree who will sign off the content, fix technical errors and approve the launch. Your business keeps the necessary access to the domain, hosting, where the website is stored, and reporting tools. Backup arrangements also need to cover what can be restored and who decides.
Ask your provider what returning to the previous version would involve in your particular project. Having a backup does not answer that question. It should also be clear how your business will access the necessary accounts after handover and who will be available for technical questions. [b]
If an important service page is missing, an accidental setting blocks large parts of the site from Google, or the form does not work, the launch should wait. Minor design requests can remain on the outstanding work list. The responsible team should be available after publication. [b]
Use the full 15-point checklist. Each point needs a status, person responsible, date, and evidence or an unresolved error. The launch checks take place on the real domain. A tick needs a checked result behind it.
If a checkpoint does not apply to your changes, add a short explanation beside it. General approval of the layout is not enough when an error remains open. The log separates tasks already checked from work still outstanding. [b]
The first checks after launch
Set the follow-up period in the brief. If something differs from what was expected, the team should name the affected page and the person handling it. If, for example, a wrong destination has been corrected, a repeat check shows whether the link now leads to the right place. Record that result in the log too. [b]
As a working plan, checks can begin on launch day. Open errors are reviewed on the next working day, followed by weekly reviews during the agreed period. These are arrangements for working together. A known error should not wait for a scheduled review, and these intervals say nothing about when Google rankings will change. [b]
Keep search clicks separate from enquiries actually received and jobs won. A drop may reflect technical errors, but also changes in measurement, seasonal demand or a changed service offering. Timing alone does not prove the cause. [b]
A click on the phone number does not show whether a conversation took place. An enquiry received may also fall outside the services you offer. Record what your business counts as an enquiry before and after the change, and how it is attributed to the website. Without this information, the comparison remains limited. [b]
Google recommends keeping redirects for as long as possible and generally for at least a year. If you change domains, this also means keeping the old domain running. [1] The detailed follow-up guidance helps you investigate unexpected results. With your completed page list, you can then discuss exactly which corrections and which ongoing website care tasks are still outstanding.
Editorial version dated 16 October 2026. Numbers link to sources; letters explain editorial examples or recommendations. Each note states what the source supports.
[b] Practical recommendations. The suggested processes and decision aids are editorial applications of the cited guidance. Their specific effect on enquiries or jobs has not been measured here.
[c] Editorial illustration. The illustration explains a relationship. It is neither a real client project nor evidence of a measured effect.
[a] Editorial examples. Content labelled as a sample or fictional illustrates possible situations. These are not real client cases or evidence of a measured effect.
Sources and context (16 sources)
- Site moves with URL changes — Google Search Central
Supports the recommendations to make changes in stages, compile a URL inventory, use relevant direct redirects, check the live site and keep redirects generally for at least a year. Describes possible fluctuations; no fixed recovery period or ranking guarantee is inferred. Our checklist is an editorial application of the guidance, not a Google sign-off procedure. Checked: 2026-10-16.
- Performance report (Search results): overview and basic setup — Google Search Console Help
Supports the descriptions of search performance metrics, dimensions, filters and export options. Does not provide evidence of business enquiries or jobs; saving filters for a consistent comparison is this guide’s working method. Checked: 2026-10-16.
- Redirects and Google Search — Google Search Central
Supports the recommendation to use permanent server-side redirects for permanent URL changes and the codes 301/308. Does not provide evidence that the fictional CSV rows have actually been configured or executed. Checked: 2026-10-16.
- Special-Use Domain Names — IANA
Confirms the special reservation of example. and that it also applies to subdomains. The four CSV rows, their fields and open statuses were read separately in the local download; IANA does not provide evidence of website tests. Checked: 2026-10-16.
- How HTTP status codes affect Google’s crawlers — Google Crawling Infrastructure
Supports the explanation of server responses, the limits of a successful 200 response, soft 404s for error content returned with 2xx, and 404/410 responses for content that does not exist. No live status measurement. Checked: 2026-10-16.
- Control what you share with Google — Google Search Central
Supports the distinction between password protection and exclusion from search with noindex; noindex does not prevent direct visits. Does not provide evidence of a full security sign-off for a test environment. Checked: 2026-10-16.
- Block search indexing with noindex — Google Search Central
Supports the need for crawling access so Google can detect noindex, its implementation as a meta tag or HTTP header, and the lack of support for noindex in robots.txt. The project team should remove only accidental blocks on public pages. Checked: 2026-10-16.
- Specify a canonical URL with rel="canonical" and other methods — Google Search Central
Supports the use of a canonical as a signal for the preferred URL of similar content and the need for consistent information, including self-referencing canonicals. The canonical element does not redirect visitors; Google makes its own canonical selection. Checked: 2026-10-16.
- Build and submit a sitemap — Google Search Central
Supports the use of absolute URLs and the inclusion of preferred canonical pages. Excluding staging addresses, removed pages and addresses that only redirect is the resulting check of the new destination list; a sitemap does not guarantee indexing. Checked: 2026-10-16.
- Search Engine Optimisation (SEO) Starter Guide — Google Search Central
Supports clear, descriptive page titles, headings and meta descriptions, and the possible use of other sources for the title link and snippet. The side-by-side check is an editorial working suggestion. Checked: 2026-10-16.
- Mobile site and mobile-first indexing best practices — Google Search Central
Confirms that Google uses the mobile version for indexing and ranking, and that important content should be accessible there. The smartphone test in this guide is an additional editorial sign-off practice, not evidence of better rankings. Checked: 2026-10-16.
- Core Web Vitals and Google Search results — Google Search Central
Supports the descriptions of loading performance, interactivity/responsiveness and visual stability. No new thresholds or measurement results have been introduced into the article. Checked: 2026-10-16.
- Understanding page experience in Google Search results — Google Search Central
Confirms that ranking systems use Core Web Vitals and that good scores do not guarantee a top ranking. Makes no claim about a measured conversion effect on the specific website. Checked: 2026-10-16.
- URL Inspection tool — Google Search Console Help
Supports the distinction between stored index information and the live test, the test’s limits, and its inability to predict canonical selection. A positive result does not guarantee inclusion in the search index. Checked: 2026-10-16.
- Change of Address tool — Google Search Console Help
Supports use after a domain/subdomain move and redirect setup, along with the exceptions for HTTP to HTTPS, path changes, www/non-www changes and hosting changes without URL changes. Additional property and ownership requirements apply; the guide does not claim that a change of address has been carried out. Checked: 2026-10-16.
- Page indexing report — Google Search Console Help
Supports the explanations for pages not being indexed and the distinction between important destinations and addresses legitimately excluded, removed or redirected. For the status of a particular page, the help page refers to URL Inspection. There is no requirement to index all old addresses. Checked: 2026-10-16.