Risk list before launching a new website

A new website launch rarely falls over because of one spectacular mistake. More often, it is the sum of small details that nobody finalised before publication: redirects, analytics, forms, consents, performance, or the launch process itself. A risk list organises these threats and forces the team to make concrete decisions before go-live. A well-prepared risk list is not a “just in case” document, but a tool for stopping costly mistakes before users and Google see them. In practice, it helps separate problems that block the launch from those that can be fixed shortly after implementation. Because with a new website, it is not only the appearance that matters, but also the continuity of traffic, measurement and conversions.

What is a risk list before launching a new website?

A risk list before launching a new website is an operational register of threats that may derail the launch of the service or worsen results after publication. It does not summarise the project in general terms, but lists concrete problems, the conditions under which they occur and the response method. It is a tool for quality control, staging sign-off and deciding whether the website can go live.

A good list does not stop at a label such as “SEO risk” or “analytics risk”. Each entry should have an area, a description of the problem, business impact, a detection method, an owner, a preventive action and a contingency plan. If for a risk you cannot identify the responsible person and the verification method, then in practice that risk is not being managed at all.

Such a list should be based on data from the current website, rather than solely on mock-ups or the contractor’s assurances. You need to check which URLs generate traffic, where leads come from, which events are being measured, which forms are critical and what dependencies there are on CRM, payments, chat or external APIs. That way you are not guessing, but know what really has to work from the first minute after launch.

In practice, risks touch on several areas at once: SEO, analytics, performance, security, legal compliance, content, integrations, accessibility and the publication process itself. The problem is that many failures do not stem from the code itself, but from the lack of a launch plan, backup, rollback or a blurred responsibility for DNS, CDN or SSL certificate. The most dangerous risks are the ones “between teams”, because then everyone assumes that someone else has already checked it.

The outcome of work on the risk list should not be the document itself, but implementation decisions. The team must clearly mark what blocks the launch, what needs to be fixed before publication, what can be monitored after launch and what workaround is acceptable from a business perspective. The question is: does this list lead to decisions, or does it just look nice in a folder? Only then does the risk list genuinely reduce the chance of traffic loss, tracking errors, broken forms and a drop in conversions.

What are the most common SEO and analytics risks during implementation?

This is where it is easiest to make a mistake. The most common SEO and analytics risks during implementation are loss of visibility in Google, incorrect redirects, indexation blocks and interrupted or distorted data collection. These are the areas that make a new website “look good”, but after launch lose traffic or stop reporting conversions. The problem usually only emerges in production, when the real domain, consents, integrations and actual user traffic start to operate.

In SEO, the most common mistakes revolve around URL migration and changes to the information architecture. If old URLs do not receive correct 301 redirects, strong subpages drop out of search results or lose link equity. Equally common are incorrect canonicals, meta noindex left over from staging, a poorly prepared XML sitemap and the uncontrolled removal of content that previously brought in traffic. Before launch, you need to know the list of the most important URLs and exactly what will happen to them after implementation.

SEO risk also grows when the new website changes headings, internal linking, pagination, structured data or language versions without comparing them to the current site. For the user, such a change may be invisible, but for Google it often means a different page context and a different assessment of quality. The question is whether we want to test that on a live system. That is why the pre-launch audit should cover not only technical tags, but also the behaviour of key content and templates.

On the analytics side, the most common mistake is assuming that “GA4 is already there, so everything works”. That is a myth. In practice, the problem lies in missing events, incorrectly marked conversions, incomplete parameters, incorrect tag firing conditions and broken connections with Google Ads, CRM or an e-commerce system. Form tracking, phone clicks, internal search and thank-you pages are usually the first things to break.

An additional risk is privacy and consent logic. A cookies banner alone does not guarantee that tags work correctly, because you still need to check Consent Mode, the timing of script firing and whether advertising tools are not firing before consent. But note this. If the way consents are collected changes after implementation, the results in GA4 and campaigns may look worse not because performance has declined, but because the measurement has changed.

The safest approach is to treat SEO and analytics as critical areas that require separate tests on staging and a fresh check after publication. The data speaks clearly: paper checklists are not enough. You need to run real scenarios: landing from Google, moving to a key subpage, submitting a form, going to the thank-you page and recording the event in the tools. Only such tests show whether the new website not only works technically, but also retains traffic and measures the business outcome correctly.

How does the risk assessment process work before implementation?

Risk assessment before implementation is a reality check. It checks what could derail traffic, measurement, conversions or the launch itself, and then prioritises it and assigns an owner. It starts with gathering data from the current site: key URLs, page types, forms, traffic sources, integrations and the elements that actually drive sales or leads. Without this inventory, the team usually assesses the new site “by eye”, rather than against what works today and what must not be lost.

Then the business steps in. And it has the final say here. You need to clearly define the requirements: which functions are critical at launch, and which can wait, because otherwise a minor visual tweak ends up on the same shelf as a form, CRM integration or correct conversion tracking. The question is whether we really want to risk such a tie.

Along the way comes content and URL migration. In practice, this means mapping the old and new structures, identifying pages to keep, remove or merge, and preparing 301 redirect rules. The map of old and new addresses is one of the most important documents before launch, because it determines the continuity of organic traffic, link equity and user experience. Without it, it is easy to create SEO dominoes: one mistake and the rest follow.

The next stop is the SEO audit and analytics on staging, i.e. in the test environment. Among other things, you check robots.txt, meta robots, canonicals, the sitemap, HTTP statuses, headers, internal linking and 404 pages, because the devil usually lives in the details. At the same time, you verify GTM, GA4, events, conversions, ad integrations, form tracking, clicks, internal search and other actions that matter for reporting or sales. But be careful, this is not about whether something is there, but whether it works as it should.

From the user’s perspective, journeys matter, not building blocks. Instead of testing individual elements, you need to follow a real scenario: entering the site, navigating through the menu, using search, filling in a form, receiving confirmation and saving the data where it should end up. Most problems emerge when staging mirrors production not only visually, but also in terms of integrations, consents, cache and system logic. In other words, when the test stops being a little play.

The technical layer and the deployment environment itself are examined separately. Here you verify performance, external scripts, images, fonts, security, SSL, backups, error logs, form resilience to spam and operational issues: DNS, CDN, WAF, www/non-www rules, HTTP to HTTPS, permissions and access to admin panels. And this is often where the paradox appears: it is not the code that blocks publishing, but the lack of an owner for these areas. They may seem like minor issues, yet they can stop the whole train.

At the finish, every risk gets a status. It either blocks launch, or is high risk and must be fixed before publication, or medium and monitored after launch, or low and goes into the backlog. Only then can you make a sensible go-live decision, prepare a backup and rollback plan, and set up post-publication monitoring. Launching without closing blocking risks is not a time saving, but a shift of cost to the moment when the problem is seen by users, ad systems and Google.

What should be checked before launch of a new site?

Before the launch of a new site, everything is checked. And it is not about a “nice launch”, but about visibility, measurement, leads, compliance and operational security after publication. To begin with, SEO is finalised: the 301 redirect map, the list of priority URLs, the export of metadata and a plan for preserving the content that currently drives traffic or conversions. But be careful, it is just as easy to fall over on the details: staging must not be indexable, and production after launch must not have an accidental block in robots.txt, meta noindex or canonicals pointing to old or test addresses.

Analytics can be more treacherous than SEO. You need to recreate the full measurement specification: which events are tracked, which of them we treat as conversions, which parameters we pass on and how the data should flow into GA4, GTM and advertising tools. The mere presence of the GA4 code does not guarantee anything, so validation is done in DebugView, GTM preview or Tag Assistant. The question is whether reporting actually reflects what is happening on the site.

Forms and the entire lead flow need to be tested step by step. That means validating fields, error messages, submission, saving to the CRM or inbox, autoresponder, thank-you page and triggering the conversion in analytics. Every form needs to be tested end-to-end, because the most dangerous errors are not visible on the user’s screen, but only emerge on the integration side. And that is exactly when they hurt the most.

Privacy and consents are not “an add-on at the end”. Before publication, you need to check the cookie banner, Consent Mode, marketing scripts, checkboxes in forms, policies and the way tags load, so that they work as intended. The problem is that the banner may be visible, and yet tags still fire before consent or do not change state after consent is given. It is only a minor detail on the surface.

Performance is assessed where users really suffer. That is, on key templates and on mobile devices, not just on the homepage. You need to check images, cache, lazy loading, heavy JS libraries, fonts, external widgets and the impact of these elements on LCP and CLS. If the new site is clearly heavier than the old one, you need to be able to identify what is worth that cost and what is simply dragging the result down.

Content, UX and accessibility can also sink the launch. In practice, you compare the old and new site in terms of missing sections, FAQs, terms and conditions, contact details, category names, CTAs, menus, focus states, contrast, keyboard operation and readability on mobile. This is especially important where the information architecture changes, because even a great-looking site can make it harder to find an offer or complete an action. And then the whole “wow effect” stops mattering.

At the finish line, technical and operational matters remain. SSL, backup before publication, rollback capability, up-to-date plugins and dependencies, securing forms, error logging, and responsibility for DNS, hosting, CDN, WAF, the repository and environment variables. The lack of a publication and rollback plan is one of the most expensive oversights, because even a small production error then turns into a long outage. And that is when frantic patching on the live system begins, instead of a calm return to the previous version. In practice, it is good to have a ready risk register, redirect map, analytics specification, UAT test protocol, list of critical URLs, launch plan and post-launch checklist.

On the tools side, simple and specific things win. A crawler to compare the old and new structure, Search Console for indexing, GA4 and GTM to validate measurement, Lighthouse for performance, and server logs for error analysis. The most common mistake is treating publication as the end of the job, even though in practice for the first few days after launch you need to check data, 404s, redirects, forms and changes in visibility every day. The question is: who will do it and when, if there is no on-call rota and no clear division of roles.

What decisions are key before publishing the site?

Before publication, you need to decide what blocks the launch, what must be finalised before go-live, and what can be moved to post-launch fixes. This is not bureaucracy, but a condition for a safe rollout. If the team does not separate risks into critical and secondary, it is easy to push the site live with an error that will stop leads or cut off traffic from Google. First it is “a minor thing”, then “just one more fix”, and in the end an expensive outage. The launch of a new site should take place only after blocking risks have been closed, not after a general statement that “most things work”.

The second key decision concerns responsibility. It needs to be clearly stated who approves SEO, who analytics, who forms and integrations, who infrastructure, and who finally makes the decision to publish or hold back the launch. Without that, errors become “nobody’s”. And in production, the search for someone to blame begins instead of a quick fix and a return to normal operation.

Equally important is the operational decision: when to launch and according to what plan. The deployment window should take into account the availability of developers, the administrator, the person responsible for analytics, and someone on the business side who can confirm that the critical paths work. Not at night “because it will be quieter”, but when there are hands to work and minds to make decisions. Backup and rollback must be prepared before launch, not only when an incident appears.

Before publication, you also need to settle whether the elements that maintain traffic and data continuity are ready. This is primarily about the 301 redirect map, priority URLs, correct canonicals, no indexing blocks, reproduction of events and conversions in GA4, GTM working properly, and the consent banner matching the actual firing of tags. Put it another way: the point is not whether “something is being measured”, but whether the same thing is being measured as before. Having “analytics” is not enough if you do not know whether conversions are being recorded in the same way as before the migration.

Form readiness and integrations require a separate decision. Each form should be traced from the user’s first click all the way to the record in the CRM, inbox or another system, together with the autoresponder, thank-you page and conversion event. The biggest losses after deployment do not come from the look of the site, but from the fact that the lead technically “disappears” after submitting the form.

At the finish line, the post-publication monitoring plan needs to be closed off. This is not a decorative extra. In practice, it means a checklist for the first hours and the first days: 404s, server statuses, indexing, organic traffic, redirect accuracy, data in GA4, form functionality and performance of key templates. The question is: who checks it and when. If there is no such plan, the team only sees the problem when leads drop or campaigns start reporting incorrect data.

What are the most common mistakes and how can you avoid them?

The most common set of blunders is surprisingly repetitive: launch without priorities, without end-to-end tests and without a post-publication action plan. On paper, the deployment then looks complete, but the reality is that problems with traffic, measurement and conversion only come to light after launch. To avoid fighting fires blindly, each risk needs to be described and assigned an impact, an owner and a decision deadline.

A very common mistake is to put all faults in one basket. The team polishes visual details while at the same time letting a missing conversion tracking setup, incorrect redirects or a broken form integration slip through. Instead of chaos — a simple classification: blocking launch, high priority to fix before launch, medium to monitor after launch, and low to move into the backlog. The key is that this classification must genuinely drive decisions, not be just another table.

Another mistake is testing the site only “by eye”. The fact that the site loads on staging and looks good does not yet mean that it works correctly on the SEO, analytics, consent, cache or API integration side. Put it another way: what matters is not the impression, but the result in a real scenario. That is why you need to run through user journeys on real test data, ideally in an environment as close to production as possible.

In SEO, the migration of URLs and indexing control usually fall apart. First there is no 301 map, then the new URLs do not match the old intents, then canonicals point to the wrong version of the page, and finally production inherits noindex or an incorrect robots.txt from staging. The safest approach is to compare the old and new structure with a crawler, isolate the list of critical URLs and check production immediately after publication.

In analytics and privacy, a common mistake is to assume that because GTM and the consent banner have been added, the setup is complete. But beware, that only works in theory. In practice, tags can fire without consent, conversions can diverge in definition from the previous version, and links with Google Ads or CRM can stop passing data. A consent banner alone does not guarantee compliance or correct measurement — you need to check the actual behaviour of scripts and events.

The same sin returns too: forms tested “half-heartedly”. Someone checks whether the form sends at all, but does not follow through on field validation, CRM writeback, the autoresponder, the thank-you page, anti-spam and conversion tracking. And then there is surprise that the leads “vanished”. There is only one way to avoid this: run an end-to-end test of every form, on all key devices and in the most important path variants.

Operational errors are left for dessert. No owner for DNS, CDN, WAF, certificates, the repository and environment variables, plus no backup and an unpractised rollback. In such a setup, even a minor technical incident can spill into hours of downtime, because no one knows who is supposed to press the right button. The key is a simple approach: run a publishing dry run, confirm responsibilities and prepare a checklist of the first checks after launch, instead of treating the deployment as closed the moment “publish” is clicked.