Relaunch checklist for online stores, booking & corporate websites

Are you planning a relaunch? Congratulations on finding this article. The following explanations may be a decisive contribution for you to ensure that your relaunch is a success and that you achieve a fabulous result. Because that's not always the case. I'm an agency owner and I'll tell you exactly what will enable you to force guys like me to do exceptionally good work and avoid typical relaunch mistakes. But let's start from the beginning.

A website relaunch is the redesign and overhaul of an existing website. The design, content and technology can all be changed. The aim of a website relaunch is to improve the website and adapt it to current requirements.

Certain external triggers in companies ensure that the goal of a "relaunch" is proclaimed: The newly hired employee brings great ideas, a new boss arrives and wants to have a good digital sweep, the competition has a new website or sales are falling. Perhaps the boss's wife doesn't like the old site either or the website isn't "lit" enough for Generation Z. You may be familiar with this. Just like personal opinions, the fact that it's time for a new website is no reason for a relaunch.

But there are some better reasons why companies or organizations want to relaunch their website. The main ones are:

• Outdated design and/or rebranding: an outdated website can give the impression that the company is not keeping up with the times or is no longer active. A fresh, modern design should therefore improve the image. Even if the brand image or corporate identity changes, a website relaunch is often desired to reflect the new brand message.
• Better user experience: If the user-friendliness of a website is poor, this can lead to a high bounce rate. A relaunch can serve to improve the user experience and make the website easier to navigate.
• Mobile optimization: With more and more people accessing websites via mobile devices, it is important to ensure that the website works well on different screen sizes and devices.
• Search Engine Optimization (SEO): An outdated website can have SEO performance issues. A relaunch provides an opportunity to make SEO-friendly changes to improve search engine visibility.
• Content update: If a company's information, services or products change, the website needs to be updated to reflect these changes.
• Security improvements: Older websites are often more susceptible to security risks. A relaunch can serve to improve the security of the website and protect against cyber attacks.
• Technology update: The use of outdated technologies can affect the performance of a website. A relaunch can provide an opportunity to switch to current web technologies and platforms.
• Accessibility: Improving accessibility is a major concern for many websites to ensure they are accessible to people with disabilities.
• Competitiveness: To keep up with the competition, it is important to have a modern and powerful website. A relaunch can help to maintain or increase competitiveness.
• Analytical improvements: By implementing better analytics tools and collecting data, companies can better understand and optimize their website performance.
• Compliance with legal requirements: Privacy, accessibility and security laws and regulations change regularly. A relaunch may be necessary to ensure that the website complies with these requirements.

These reasons can occur individually or in combination and vary depending on the goals and needs of the company. A website relaunch is often a strategic decision to improve the online presence and achieve the company's goals . If you look at the points above individually, it becomes clear that most reasons can be implemented in smaller sprints and do not require a major relaunch.

Let's therefore differentiate between what a relaunch is and what it is not: a new design with an existing technical basis is more of a facelift . A relaunch is only a relaunch if the aim of the relaunch is to make a real change to the user experience, functionality and technical basis.

A relaunch should always be justified on the basis of facts (e.g. the technology is at an impasse and can no longer be updated), key figures and measurement and comparison data.

This is my first recommendation at this point: evolution before revolution! Avoid a relaunch for as long as possible and try to implement all the points that have been put forward so far for a relaunch individually or incrementally. Improve one thing, bring it live, evaluate what happens, adapt again or move on to the next point. The best example is Amazon, which really only makes minimal changes and improvements and has avoided major relaunches for many years.

A relaunch is always a big threat to your visibility on Google. Everyone is looking at the improvements, but few are looking at the risk. Sure, the user interface improves, the positive user experience increases and you are technically up to date again. Nevertheless, if your business success depends on strong organic visibility , a relaunch is the last resort and should only be decided on if your pain is great enough due to a combination of the reasons mentioned above that can no longer be resolved in individual sprints. Why? See what happened to online visibility after the relaunches of these four websites:

Plan your relaunch carefully and ensure successful implementation with a checklist. Above all, set yourself the two goals of maintaining your online visibility on the one hand and finding ways to create the basis for an increase in online visibility as part of the relaunch on the other. That's exactly what this article is for, to give you a relaunch guide to limit your relaunch risks and ensure you get an exceptionally good result with the potential for sustainable, organic SEO success.

Roadmap for a relaunch

Planning a website relaunch should be done carefully. It is important to consider the following steps:

• Analyzing the existing website and logging current state: first, the existing website should be analyzed to identify its strengths and weaknesses.
• Defining the goals: The goals of the website relaunch should be clearly defined. These include, for example, improving the conversion rate, increasing visitor numbers or switching to a new CMS with improved content maintenance and maintainability.
• Development of a concept: A concept for the website relaunch should be developed based on the analysis and objectives as well as a competitor analysis. The concept should include the following aspects: Design, content, technology and SEO/marketing.
• Implementation: The concept is then implemented. This includes developing the design, creating/adapting the content and implementing the technical changes.
• Testing: The new website should be thoroughly tested before publication to ensure that it works without errors. This also includes a defined checklist.
• Publication: The new website is then published. And it continues to be tested live, evaluated and adjusted.

Determine the goals and strategy of the relaunch

Determine exactly what goals the relaunch is pursuing. Goals can be (in addition to the reasons mentioned above)

• Improving the user experience
• Increasing the clarity
• Expanding the range of content
• Modernization of the design
• Increase in turnover and shopping cart size
• Switch to a different CMS with easier content maintenance and technical maintainability
• Easier expandability and maintainability in the future.

Suggestion: After the first kick-off meetings in the team as a company - even before the discussions with implementing agencies begin - everyone involved in the project should type the goals of your relaunch on a piece of paper or in their input mask in your communication tool (e.g. Slack). When everyone points out their stated goals at the same time, you will be amazed at how widely opinions differ, even though the goal has already been discussed verbally in the meetings. It is therefore important to set out your goals in writing . If you know exactly what your goals are, you can check the UI prototype at an early stage to see whether they have been taken into account conceptually.

A specification sheet provides clarity about the relaunch order

The agency requires a comprehensive project briefing from the client in order to prepare an offer. Companies usually have a Word document or a PDF ready where the project is outlined in more or less detail. There are then questionnaires or workshops are held with which agencies can better highlight the customer's pain points in order to be able to submit an offer. For larger projects, a specification sheet is drawn up. The more detailed, the better.

A specification sheet is a document that plays a crucial role in a website relaunch. It serves to record the requirements, goals and expectations of the relaunch in written form. A well-developed specification helps to ensure that everyone involved - be it the development team, the design team or the client - has a clear understanding of what is to be achieved during the relaunch. It is also the starting point for a well-calculated and binding offer from the implementing agency. Here is information and elements that can normally be included in a specification for a website relaunch:

• Goals and purpose: A description of the main goals of the relaunch, e.g., improving the user experience, increasing visibility in search engines or changing the CMS with updating the design.
• Project scope: A clear definition of what is and is not included in the relaunch. This may include the number of pages, integration of third-party tools or content revisions.
• Design requirements: Information on the desired visual design of the website, including layouts and adherence to corporate design guidelines on colors, fonts and images.
• Functionality requirements: A breakdown of the desired functions and interactions on the website, such as contact forms, search functions, e-commerce functions, etc.
• Technical requirements: Specifications for the technologies to be used during the relaunch, such as the selection of a content management system (CMS) or the implementation of certain functions. This also includes the use of modern image and graphic formats (WebP, AVIF, SVG).
• Manual and automatic backups and revisions of content edits.
• Content requirements: Clear specifications for revising, updating or creating new content, including text, images, videos and other media. Handling of metadata and structured data.
• SEO requirements: more on this in the next content section.
• Schedule and milestones: A schedule that defines the planned start and completion dates for the relaunch as well as important milestones.
• Budget: Information about the budget for the relaunch, including the costs for design, development, hosting and any third-party services.
• Quality assurance with testing tools: Description of the testing and quality control procedures that will be performed during the relaunch to ensure that the website functions properly.
• Maintenance and support requirements: Requirements for ongoing maintenance and support of the website after the relaunch.

A well-structured specification document is crucial to avoid misunderstandings, manage the project efficiently and ensure that the expectations of all stakeholders are met. It serves as a guideline and reference document for the entire project team and helps to ensure the success of the website relaunch.

When we planned our TutKit.com relaunch with a complete framework change from CodIgniter to Laravel, our requirements specification was 220 pages - (not) a tempting prospect for an agency to work through.

Note: My article will not go into detail about the concept, design, function and technology used. The new website will definitely be pretty. The biggest danger with a relaunch is actually a deterioration in the technical user experience and on-page quality due to missing 301 redirects etc., which then leads to a loss of ranking and visibility. To prevent this, the focus below is primarily on ensuring the success of the project from a user experience and SEO perspective.

Defining the SEO requirements for the new website

The customer briefing or a more extensive specification sheet already regulates what is desired in terms of design, content, functionality and technology and is the basis for an agency to draw up a calculation.

For the relaunch checklist to ensure the success of the project , the individual passages must be considered from an SEO perspective. There are special SEO requirements due to, for example

• a changing URL structure (URL redirect map!) and changing link paths
• a changing navigation (important due to internal linking and link hierarchy)
• changing technologies (CMS, JavaScript framework, server, ...)
• changing content (potential loss of visibility for pages that rank well)

Pages rank well on Google because of their content relevance , which is why it is important to ask whether existing content is changing or being merged, whether content is being removed and/or new content is being added? Will the content structure of categories or pages change? SEO requirements that belong in the relaunch checklist must be derived from these points.

Will the metadata of the old content also be transferred and will it change? How is the content maintained by the editor and is the page content linked to structured data?

Are the existing or new images stored in modern image formats for websites (WebP/Avif) and is attention paid to image SEO with URLs in lower case letters, i.e. instead of 1234.jpg => hotel-ostsee-warnemuende_suite-nachtigall.avif.

Care should also be taken to ensure that image files are transferred to Google via structured data (ImageObject) and <meta> thumbnails in order to increase the probability of image embedding in search snippets and listing on Google Images.

Another interesting question in this context is how user signals can be improved . For example, image videos, explanatory and help videos could be embedded on content pages. If a user who comes to the landing page from Google clicks on the video and watches it, the length of stay increases (good user signal) and the return-to-SERP rate also improves (good user signal).

It should also be checked how content sections are integrated on the pages that meet Google's requirements for Helpful Content and the E-E-A-T principle.

For Google, " helpful content " is content that is relevant and useful to users. It answers users' questions comprehensively and informatively, offers solutions to problems and provides added value that goes beyond mere advertising messages.

Here are some examples of helpful content:

• Tutorials and how-to guides: This content helps users learn new tasks or solve existing problems.
• Reviews and comparisons: This content helps users decide on the right product or service.
• News and updates: This content keeps users up to date with current events and trends.
• Infographics and diagrams: This content can help visualize complex data and information.
• Blog posts and articles: This content provides a deeper insight into a particular topic.

Google uses various signals to recognize helpful content. These include, among others:

• User behavior: Google observes how users interact with content, such as how long they stay on a page, how often they share it and how often they rate it.
• Quality signals: Google evaluates the quality of content based on factors such as relevance, completeness and topicality.
• User feedback: Google also takes user feedback into account, e.g. ratings and comments.
• By taking these signals into account, website operators can increase their chances of their content being rated as helpful.

The EEAT principle is a concept developed by Google that evaluates the quality of websites and web content. It stands for Expertise, Experience, Authority and Trustworthiness, i.e. expertise, experience, authority and trustworthiness.

• Expertise refers to the knowledge and experience of the people who create the content. Google evaluates expertise based on factors such as education, professional experience and awards.
• Experience is attested if the content was also created with some experience, e.g. based on actually using a product, actually visiting a place or a person's description of what they experienced?
• Authority refers to the reputation of a website or web content. Google evaluates authority based on factors such as backlinks, social media activity and user reviews.
• Trustworthiness refers to the reliability and credibility of a website or web content. Google evaluates trustworthiness based on factors such as privacy, security and transparency.

What SEO requirements do existing and new functions have in terms of frontend and backend? Here are some examples:

• Crawlability (relevant content must be visible and crawlable even without JavaScript).
• Clarity of the goal of the website and clarity about the call-to-action (the desired behavior of the target customer on the pages)
• Avoidance of duplicate content through, for example, automatically created category pages or page duplicates through variant articles
• Ensuring a high PageSpeed by avoiding too many JavaScript and CSS files, by using modern image formats (WebP/AVIF)

These SEO requirements belong in the project briefing or in the specifications, but also belong in the quality assurance of the project via a test tool-related checklist or as an ACTUAL-TARGET comparison and also as an acceptance criterion for the agency service. More on this below.

Determine the internal and external project participants

Determine the project participants - here from the perspective of the customer or website owner:

• Who is responsible for project management and makes the final decisions?
• Who is responsible for coordination and communication with the agency or client?
• Who is responsible for internal project management?
• Who prepares the content and input for the agency internally?
• Who implements the user experience design?
• Who implements the development?
• Who reports to the client on the agency side and at what specified intervals?
• Who is responsible for testing and quality assurance on the agency/client side?
• Is an external consultant brought in (e.g. for SEO or legal requirements)?
• Who releases the tasks? Who approves the tasks in the ticket system after processing?
• Who needs to be informed and when (employees, customers, partners, ad campaign managers, etc.)?

Four points are important when selecting external project managers

1. Has the agency realized one or more projects of this type? Are there references ? Do customer testimonials exist and would it be possible to have a feedback discussion with the agency's customers - which is recommended for large individual developments?
   
2. Do the services offered and the technical implementation (CMS/shop system/framework) already meet all the requirements associated with the relaunch? Are there individual functions or requirements that still need to be programmed (also via plugins or modules)? Are certain services excluded from the offer or earmarked for a later date, but which are crucial for the success of the project? It is important that no new problems are added that are greater than the actual reason for the relaunch.
   
3. Is the implementing agency or service provider a good fit for the company in terms of team size, regional location and employee turnover (which can be determined via Kununu reviews) for further support?
   
4. Is direct contact with the implementing design and development team possible? It makes sense to get to know the actual agency project team. The sales professionals who are in a good mood and promise the blue sky get the job and are no longer responsible later on. This is why direct contact with the team implementing the project should be agreed.

Four tips to protect yourself in this context

1. As a customer, I would pay close attention to the technology used by the agency. Just Google "CMS + disadvantages" or "CMS + experience" to find out what the offer says. You should know exactly what you are getting into. It makes sense to rely on open source solutions . I am aware that this is not always possible. It's best to make sure that there is as large a developer community as possible for the technology used , so that you don't end up with an agency's own isolated solution that only your agency can work on, which in some ways puts you under considerable constraints later on.
   
2. Also make sure that you receive unlimited usage and editing rights to the agency's services so that you always have the right to further develop the website internally or externally . Such a clause belongs in the contract for work and services.
   
3. If your company is a bit more technical and you have system administrators, software developers or similar in your team, it makes sense to set up Git for version management and JIRA (or a similar tool) for project management or ticket system in a separate account . Then give the agency full access rights and the work can begin. The larger a project is, the rougher and more painful it can become. So it's good if you are in control of the key accesses and accounts. However, I am aware that this recommendation can only be followed by a few customers from a purely professional point of view.
   
4. Sometimes agencies offer hosting for customers directly. We ourselves are not a fan of this, because on the one hand it increases the dependency in the customer relationship, on the other hand we tell ourselves that web hosters are best suited for web hosting because they specialize in it. We had already set up and managed servers for ourselves and wasted a lot of human and time resources. We rowed back again. Now our systems run on cloud servers from one of the big web hosts in Germany and we are happy. When choosing web hosting, always make sure that server-side backups are already included in the package and can be imported with just a few clicks.

Determining the time period and launch date

A relaunch is carried out in several project sprints. In our agency experience, these can be

• Actual status is recorded (via test tools, but also in writing with impressions of what is going well on the customer side and where improvements are needed)
• Research phase with competitive analysis and research for solutions/inspiration
• Wireframe conception
• Creation of the user interface design
• Frontend and backend development
• Migration of data or content import (automated/manual)
• Structural and content optimization (text and image) & SEO sprint

Project sprints overlap because new project participants become active during the course of the project.

It is important to define the time frame for individual project sprints and to coordinate this with those involved.

If the project is larger, does the agency set up a separate Slack channel for the client for faster communication?

A tip at this point: It is good if the agency works with clickable prototypes at a very early stage, i.e. as early as the wireframe conception and even more so when presenting and testing the user interface design. This gives customers a better feel for the website experience. Simple JPG or PNG files as layout proposals are no longer up to date. They should be clickable prototypes created with Sketch, Figma, Adobe XD or another professional tool.

At this early stage, changes are easy to implement. If functions and sections of a website have already been developed, changes are much more complex and may lead to renegotiations that are absolutely unsexy.

Here you can see what a prototype for the mobile user interface design looks like with the click paths in the overview:

The question needs to be clarified as to when ongoing testing from the customer side is possible. Developers should also test their local work after merging into the stage system. Sounds banal, but anyone who works with developers will immediately understand what I mean. The person responsible for quality assurance on the agency side should then test the ticket or function. Only then is the ticket released to the customer for testing. The customer should never feel like an alpha tester , but should find a system that has already been tested by four eyes. The agency is the alpha tester, the customer is the beta tester ! Is there even access to the agency ticket system?

It should also be defined in writing that agency-side reports are to be sent to the customer at a certain frequency. For example, a report could be sent by e-mail every Friday about the current status of work, necessary feedback loops or requests for additional work. This is also a tip from our agency experience: it's a good idea not to let a customer go into the weekend without knowing. It will only give them stupid ideas. It's better to explain what has happened and what is coming up the following week. Transparency helps to ensure that everyone has a good feeling about the project.

The launch date should also be set. According to Parkinson's law, work expands to fill the time available to complete it. In other words, the more time available to complete a task, the more time it will take, regardless of the actual complexity or amount of work involved. The planned completion then also belongs in the contract for work. Missing the deadline could even be subject to a contractual penalty in the contract. As a guideline, contractual penalties of 0.2 % of the contract sum per working day of delay and a maximum of 5 % of the contract sum are effective. The contractual penalty does not necessarily have to be claimed by the client, but gives you leeway to elicit a few special requests from the agency as compensation.

Important: No launch on Friday . Not even between public holidays or during the company's main business hours. We actually recommend the night hours from Sunday to Monday for large relaunches, especially if the IP changes, so that the DNS settings are updated again on Monday with most providers, which is often the case in the late morning if the DNS entry was adjusted during the night hours. This effectively leaves 4.5 working days for live testing and bug fixing in the event of errors.

Logging the current status of your website

The status quo must be recorded before work begins. The actual status records the technical measurement results for the parameters. You can enter the target values to the right:

In the list you will find the SEO tool Seobility, which we like to use to check the on-page factors, for which I have also published an SEO training course. There are many counterparts such as Sistrix, Semrush, Ryte, SE Ranking, Screamingfrog etc. The SEO tool is primarily about identifying and fixing the typical on-page mistakes . The three core areas of technology & meta, structure and content are how Seobility sets up the evaluations. You will also find this in a similar form with the other seo tools. On the one hand, it is important that a full check is always carried out, i.e. ALL pages are crawled and not just the homepage, and on the other hand that you enter a score or error value for the current status and the target value that should be achieved after optimization. For Seobility, a value of 90 or higher is desirable. You can also find alternative tools for other purposes. The decisive factor is that one is used at all to ensure outstanding data.

For example, this is our current value for on-page quality:

User signals can be statistically recorded with metrics from Google Analytics 4 such as bounce rate, pages/visitors, length of stay, etc. If Google Analytics or another analysis tool is used in a data-compliant manner, this data should also be included in the logging of the current status.

A backlink list should also be created, which can be generated free of charge here, for example: https://www.seobility.net/de/backlinkcheck/

Furthermore, the old sitemap.xml should be saved , as well as a full backup of the site. All relevant pages should also be transferred as a list to a Google Sheets, which forms the starting point for the URL redirect map . Such a CSV list can be easily exported using an SEO tool such as Seobility. The URL redirect map includes all relevant pages and linked pages via external backlinks (see backlink list) that need to be redirected later due to changing page URLs. URLs that have been removed must redirect to the new URLs that correspond to the old ones. It is important to prevent redirect chains ! The old, still existing redirects must redirect directly to the new end URL. You should also think about the PDF files and images to which links exist so that these are also forwarded correctly and do not become a 404 link.

The redirects are set up as 301 redirects based on the URL redirect map in the .htaccess, via redirect maps via Vhost configuration or a database solution. The customer should be able to maintain these themselves. It must also be ensured that the redirects are permanent.

It is also advisable to back up each page type with a full-page screenshot . On the one hand, this is a backup of the old inventory in case there are questions after going live as to whether content types have not been transferred, etc.

Based on the existing pages, functions and content and on the measurement results, it is possible to identify what is already working well and what is identified as an area where there is potential for optimization and what should be improved by the relaunch.

Checklist: Before the relaunch

As soon as the user interface design has been confirmed and the agency is in the development sprint, the following checklist becomes relevant, which lists the key points chronologically up to the relaunch date:

1. Dev environment with access for all stakeholders is available for testing
2. Dev environment runs on noindex
3. Accessibility for test tools on dev environment (IP sharing or http login) is set up
4. Configuration of the dev environment corresponds as closely as possible to that of the live system
5. Page structure of the dev environment corresponds to the later live page
6. Data migration of the old data has been completed
7. Content adjustments have been made
8. Image SEO has been carried out
9. 301 redirects based on the URL redirect map have been set up
10. OnPage check with Seobility has been carried out, errors have been corrected, target values have been achieved
11. Open Graph data is valid
12. Structured data is valid
13. Pagespeed check for all page types has been carried out, target values have been achieved
14. Content cookie policy works
15. Security headers are set up
16. Accessibility is given, target values are achieved
17. Hreflang is valid (for multilingual pages)
18. Legal texts (terms and conditions, imprint, revocation declaration, data protection) have been updated, GDPR compliance has been achieved
19. CMS, frameworks, plugins and modules used have been updated to the latest version
20. Final cross-browser and cross-device functional test revealed no errors
21. Final status and launch date has been announced
22. Full backup has been created

The use of structured data (schema markup) - see point 12 of the list - is still given far too little consideration today. Familiarize yourself with the topic and read what Google says about structured data markup in Google Search. Google will increasingly weight valid data more heavily in the context of SBU, i.e. search results generated by AI. Google's Helpful Content Update also requires content to be much more verified through expertise, experience, authority and credibility. Structured data is part of the solution to make this validation easier for Google. Use the Schema Markup Validator after integrating structured data, but also check your pages with the Structed Data Linter, which is also recommended and linked by Google in PageSpeed Insights. This will give you more in-depth information about code errors related to your use of structured data.

Accessibility appears for the first time in this article under point 16. Accessibility already has its own section in PageSpeed Insights and green numbers are desirable there. In addition to PageSpeed Insights, you should also use https://www.accessibilitychecker.org and/or https://wave.webaim.org to test whether a page is accessible or not. Especially if a relaunch is imminent, this point should be taken into account as a mandatory requirement, as the topic will become topical for websites from 2025 with the Accessibility Reinforcement Act. Use such a tool to check not only the start page, but every page type - the same applies to the PageSpeed tests!

A relaunch often also involves adjustments and updates to the legal texts . It is important to think about this at an early stage, so that the texts are provided by a specialist lawyer or legal generators if necessary. You should also think about the order processing contracts if, for example, a new web host is used or the newsletter service changes.

Point 18 with the update of the CMS, the JavaScript libraries used, the installed modules and plugins is as underestimated as it is important. A relaunch can take several months or longer. With the WordPress system, it is easy-peasy to see that numerous updates may already be available before the relaunch date. Customers should make sure that the latest versions are used when going live .

If external services change , there are additional tasks that should also be included in the checklist, such as changing the newsletter service:

• Data import of the newsletter contact data to the new NL service
• Connection to the newsletter service on the website in the registration form
• AV contract
• Creation of new mailing templates
• and so on

During the entire development sprint, continuous testing of the functions etc. naturally takes place. It makes sense to make an extremely detailed checklist for the tests so that nothing is forgotten. It is not enough for both the implementing agency and the customer to just click around a bit. After our relaunch of TutKit.com, our acceptance checklist certainly had 1,000 lines. And we still keep it that way today: after important major updates, we check around 70 interactions via the checklist for Chrome, Safari and Android.

Checklist: The relaunch day and the following days

The relaunch day has arrived and it's not a Friday or a day between public holidays. The new website goes live, the DNS settings are adjusted. Now it's time to check and evaluate everything again from the beginning. Check the following:

1. Check robots.txt to ensure that robots are not blocked
2. Live environment is running on index, follow.
3. Canonical tags are set correctly
4. Check page source text for absolute paths (link paths of the test environment on the live page)
5. Redirection from http to https with/without www to target page on start page and subpages works
6. Test redirects via the URL redirect map, also for the presence of redirect chains
7. OnPage check of the live page with Seobility for technology & meta, structure and content ... especially check the noindex pages that are output via Seobility
8. Open Graph data is valid
9. Structured data is valid
10. Pagespeed check for all page types has been carried out, target values have been reached
11. Cookie policy with consent cookie tool works as it should
12. Security headers are set up
13. Accessibility is given
14. Check hreflang for multilingual website(https://app.sistrix.com/de/hreflang-validator)
15. Final cross-browser and cross-device functional test showed no errors
16. Submit new sitemap.xml to Google Search Console
17. Update new landing pages for Google Ads campaigns
18. For certain domain changes, remember the links in social media, email signatures etc.

We use Mailhog in our dev environment to test emails locally. In such cases, it is important that the correct SMTP data for receiving emails is stored in the live system so that the emails go where they are supposed to go.

It is also important to ensure that the sandbox is implemented in the dev system for payment providers such as PayPal, while the correct connection must of course be established in the live system.

In the days that follow, it is important to monitor the Google Search Console in particular. Of course, the most interesting thing is how your rankings change. Focus in particular on unexpected changes and error messages:

1. Crawling: Host status ... robots.txt retrieval, DNS resolution, server connection
2. Crawling statistics ... requests, download size, average response time
3. Clicks in the SERPs
4. Impressions in the SERPs
5. Average CTR in the SERPs
6. Average SERP position
7. Passing the Core Web Vitals

Above all, Google Search Console notifies you of errors such as URL errors, href-long errors, page indexing with spread indexed/not indexed. There must be a reason for not indexed (redirect, noindex)...). You can also see duplicate content or other problems there. If the Search Console reports problems with the structured data or the Core Web Vitals, get to the bottom of it. Only through the live data will you find out, for example, that your pages have problems with the Core Web Vitals despite a high PageSpeed due to CLS errors, for example. Here you can clearly see the jumps that are possible when changes are made to the website:

You can directly display the poor URLs or URLs that need to be optimized. Take a URL and run a PageSpeed test with it in PageSpeed Insights. You will then receive information on why the Core Web Vitals are not being met and what you can do to rectify the errors. Click the small arrow on the right for more information. As a rule, these recommendations can only be implemented by developers. However, it is important that you are able to identify the problems and then address them accordingly with the help of your agency.

You should also evaluate your data from your analytics tools, such as Google Analytics 4, and keep an eye on the metrics that you can record on the system side, such as bookings, conversion rate, shopping cart size, purchases/turnover per day, NL sign-up numbers, contact requests, downloads of certain content or video views.

The crawling statistics in Google Search Console are elementary for the checks in the following days. You can find these via the settings in the menu on the left. More crawl activity should be visible immediately. If not, are there crawl errors?

The host status shows you errors directly, as can be seen here after a relaunch, for example, when crawl requests to robots.txt failed and the server connection was repeatedly interrupted:

It is also interesting to see what the crawling statistics reveal. After a relaunch, there is usually a revival in crawling requests. There you can also see whether 404 pages are still being crawled. If some do not fit the picture, discuss them with the developers.

You can tell if your server, PageSpeed and code are relatively good if your page response time is below 400. The closer it gets to 1000 ms, the more advisable it is to optimize PageSpeed, for example by reducing database queries and increasing server power (e.g. more computing power, updating to the latest server software, switching to HTTP2 or HTTP3 (with Nginx)).

In the future, the crawl budget for individual websites will probably become more limited due to more and more (AI) content on websites, which is why you should also aim for a good value for the page response time so that the bots crawl as much as possible on your pages in the time available.

Relaunch checklist for download

The relaunch checklists embedded above are also available as PDF files for you to download here. Download them and ensure the success of your project!

Confessions of an agency owner

The seo requirements in the checklist could also include detailed instructions such as observing the headline structure from H1 to H6 and so on. Fortunately, the definition of target values in the test tools shortens the entire relaunch checklist in terms of content, because achieving the top values of the test tools mentioned in the checklist can only be achieved by adhering to clean code, using modern technology, observing SEO on-page factors, etc. Otherwise, you would have to use the latest web standards. Otherwise, the latest web standards and technical and SEO requirements would have to be formulated in great detail in the specifications, which clients are not even technically capable of doing. If agencies have to achieve high scores in the test tools, they have no choice but to work according to best practice - a new experience for agencies too :-)

It's time for a commitment . The definition of SEO requirements and the checklist-like procedure with the safeguarding and binding achievement of target values in various test tools represents an ideal that is rarely found in reality. This depends on

• budget limitations on the client side
• Profit optimization interests on the agency side
• Restrictions due to the technologies used
• and unfortunately also: ignorance and incompetence on both sides

I can hardly blame the clients. They are looking for professional help and almost every digital agency writes on their website and in their white papers that search engine optimization is one of their core competencies. There are always references that prove that online visibility increased by a factor of 3, 5 or 10 after the relaunch. The fact that 100 visitors a day now come from 10 is a 1000% increase, but this is by no means a success. Many search engine successes mean that competitors are simply much weaker digitally .

Agencies continue to do mediocre work with outdated methods because they still don't use modern tools for quality assurance , even if the posts, references, best practices etc. boast that they have SEO expertise. Perhaps such agencies are knowledge giants, but then they are also execution gnomes. That sounds harsh, but it's just the rule. In all seriousness. Take a closer look! Take the checklist from above and enter the best agency from the region you come from with its URL in the tools mentioned above. And then take the latest website reference you find from the agency and repeat. What results will you see? Exactly what you can expect in a collaboration. You can also check our own references in this way and you'll see that we don't always achieve the best results, even in our customer projects. Such a workflow with an attitude towards data-driven quality assurance has only grown from project to project and has become established primarily through our work on TutKit.com.

You can do such reviews with almost any agency, because only a few work in a truly data-driven way in quality assurance, because none of them stay on the ball with their own projects on the market for years and have to compete with international players in the tough competition for online visibility , and because agencies can almost not care whether a project succeeds or fails as long as the agency bill is paid and the clients can celebrate the beautiful (but mediocre quality) websites in their posts and with awards. The particular irony here is that according to the test tools mentioned above, it is often the SEO agencies with their own websites that perform the worst, because they often only have one method in stock like a one-trick pony ... a content package for the website that is tailored to the client's keywords. There is often simply a lack of competent developers for the other technical requirements.

It's also an advantage if the agency is located somewhere else and you don't meet the customer while shopping in the DIY store as the responsible agency employee who is simply responsible for a visibility drop in the double-digit percentage range after a relaunch. But customers hardly ever check this drop in visibility anyway , because although everyone has a cookie consent banner, few actually evaluate the figures and extract action to-do's from them. In case of doubt, the ad spend must be increased. Fortunately, customers don't know that organic ranking today depends primarily on technical parameters, user signals and (still) backlinks due to an oversupply of websites with comparable content. And thanks to AI text tools , websites will upgrade their content in an unprecedented quantity and quality and we will soon be able to welcome many new websites from abroad in our national language in the SERPs, because AI translation tools will make it easier and easier to translate online stores, portals, SAAS and other websites and attack the digital domestic market. We can expect fierce competition. It's only just beginning ...

Conclusion on the data-driven website relaunch checklist

A data-driven checklist is one of the few effective ways to force agencies to do a good job. It is even advisable to make the achievement of certain values in the test tools an acceptance criterion . It should be contractually regulated that a partial amount may only be invoiced after four weeks after the relaunch if all important data is available and confirms that the top values have been achieved (such as Core Web Vitals and the validated product snippets according to schema markup in the Search Console). With the help of this workflow - as described in this article - your loss of visibility after a relaunch with major content, structural and technical changes will remain limited and you will create the basis for Google to rank your website or online store higher soon.

If you found this article interesting, please check out our other content: