Launching a website: the complete checklist

Finalise content and approvals

Publication starts by asking whether the website’s content is ready. Read every page in full and check spelling, figures, service names and contact information. Pay particular attention to outdated statements, placeholder copy and content still awaiting approval. Also check that images and copy are actually approved for their intended use. A final review by a second person often reveals inconsistencies missed during creation.

Contact information must match in all relevant places: the header, footer, contact page and forms. Test telephone numbers and email links on a real device. Check navigation from the logo through to subpages and make sure important offerings do not lead to dead ends. Internal links should lead to the expected destination and have meaningful labels. In particular, open links in copy, buttons and footer areas.

Product and website content, imagery and approvals must be available in good time. Record who is responsible for copy, offers and legal notices. Remove internal draft notes and checking instructions from visible areas. Decide who gives final approval and which changes are still allowed afterwards. For essential content, you can also use the guidance on good website content.

Include every page accessible through navigation or search engines in the approval process, not just the homepage. Check spelling and factual statements in the actual layout, as line breaks, captions and buttons can change the meaning of a statement. Make sure the final copy matches the approved version and older content has not returned through a later change.

Link testing should also cover destinations outside the website. External links should lead to the intended official or specialist page; check that the destination is still available and relevant. For internal links, descriptive wording helps more than repeated phrases such as ‘click here’. Check that contact methods work and redirects arrive as expected.

Test forms from different perspectives: with complete information, missing required fields, long text and on a mobile device. Establish whether someone knows how to continue after an error. A test message should arrive in the intended mailbox and be answerable by the responsible person. Record when test data will be removed and who is responsible for ongoing checks.

Work through features and forms properly

Do not just click around the homepage. Check every important button, navigation element, search feature and internal link. Test forms with both valid and invalid input. Check that required fields are marked clearly, error messages are specific and successful submission is followed by an unambiguous confirmation. Test enquiries must arrive in the correct internal mailbox; also check that the reply address is suitable for responses.

Email notifications are part of the process, not merely a technical detail. Establish who receives the notification, whether cover is arranged and whether the message content is limited to necessary information. Business email is a separate service from the website. Check delivery and sender configuration separately rather than assuming a website launch automatically includes working business email.

Also test loading states, confirmation pages and error cases. What does someone see if the connection is interrupted or a field is not accepted? Prevent duplicate submissions where the existing technical solution supports this, without assuming an untested feature exists. Document outstanding points and resolve critical errors before launch. A complete test covers the whole journey from entering information to internal handling.

Check presentation, images and speed

Do not check the website on just one screen. Review narrow smartphones, larger mobile devices, tablets and wide desktop views. Menus, tables, forms and headings must remain readable and usable. Watch for cut-off content, unexpected spacing, overlapping buttons and horizontal scrolling. Responsive presentation adapts to different available widths but does not replace actually checking the most important pages.

Open images in their respective contexts. Are the crop and resolution suitable? Are image descriptions used where needed for orientation? Check whether large files take unnecessarily long to load and whether essential content remains understandable without decorative images. Compression should not visibly damage the presentation. Performance checks should consider real pages and typical use, not just one laboratory score. web.dev describes Web Vitals as measures of user experience.

Check forms and navigation particularly carefully on mobile devices. Fields should not be too small, and labels must not be cut off. Test keyboard interaction and magnification. If you will manage content yourself after launch, establish who may review images and text changes and how training or handover is organised. This keeps content maintainable beyond the first day of publication.

Screen sizes are about robust presentation, not one technical width. Change the window width and font size and check that content remains readable. Particularly long page titles, tables and forms can cause problems in narrow views. Avoid making important information visible only on hover or an essential action accessible only with a mouse.

Check images for both technical suitability and content. Suitable alternative text conveys the relevant image content when the image is not visible; purely decorative images do not necessarily need a detailed description. Aim for sharp presentation without unnecessarily large files. Also check that images have sensible crops on small displays and are approved for use.

Check search engine settings

Check page titles and meta descriptions for your key pages. They should accurately summarise the actual content rather than use generic placeholders. Check that the intended canonical address is set. A canonical signal specifies a preferred URL for comparable content; it does not replace clear internal linking and correct redirects.

Checking noindex is an essential part of approval before launch. An exclusion instruction may be intentional during a protected development phase. For public pages, the responsible person must decide whether and when it is removed. Check both meta robots information and HTTP headers where your platform uses them. Google documents robots meta tags. Do not blindly enable indexing globally if individual pages should remain excluded.

Check the sitemap and robots.txt together. The sitemap should contain suitable public URLs; robots.txt controls crawling but is not a way to hide confidential content securely. Check that structured data matches visible content and avoid information that is not true. Search engine optimisation does not promise a particular ranking. An introduction to technical SEO helps put the main technical aspects in context.

For page titles and descriptions, alignment with the particular page matters. Avoid identical generic information across all subpages. A description may be used in search results but will not necessarily appear exactly as written in every situation. Review the information as a clear content summary, not as a promise of a particular presentation or ranking.

Canonical information should point to the intended preferred address and must not unintentionally refer to a development address or another page. Compare it with the URLs actually linked and planned redirects. Where several domain versions exist, use a consistent main address. If you are unsure, ask the technical lead rather than carrying the values into launch unchecked.

Noindex, robots.txt and access protection have different roles. A development page may temporarily be protected from indexing while the public website should be discoverable. Do not remove protection before the domain and approval are clear; equally, do not accidentally leave it on public pages after launch. Do not rely on robots.txt to protect private content from access.

Sitemaps should list only appropriate public pages. Check accessibility and content after launch and submit the sitemap through the intended service if one is used. Inclusion in a sitemap does not guarantee indexing. Structured data, in turn, must truthfully match the visible content. Test it with suitable official tools and remove information that is no longer accurate.

Coordinate the domain, HTTPS and measurement

Confirm which domain will be used for publication and who has access to the necessary accounts. Connecting a domain is different from transferring it. Check the main domain and www version, destination address and existing email records before making DNS changes. Changes should be agreed with the responsible person and clearly documented. Existing business email must not be affected accidentally.

Open the website over HTTPS and check that all relevant pages and resources load securely. Watch for browser warnings and mixed content. Make sure access is assigned by role rather than passed around through shared passwords. Handover must include account ownership, recovery options and responsibility. Document who will manage content and technical settings after publication.

If Analytics or other measurement tools are used, check consent, scope and actual integration before activation. Tracking takes place only with consent. A technical configuration alone does not confirm legal permissibility. Avoid unnecessary data and test that measurement behaves in line with the defined choice. Search Console can help monitor search appearance and indexing after publication; a website analysis can also be useful after launch.

Before changing the domain or DNS, briefly coordinate with the person responsible for the domain and email. Record the planned end state, check the existing email configuration and clarify who will make the change. Transferring a domain is a different process from connecting it to a website. Avoid uncoordinated changes by several people.

HTTPS must work for the addresses used publicly. Check both the main address and the www version, noting whether one consistently redirects to the other. Resolve warnings, insecurely loaded elements or conflicting URLs before launch. Do not promise that a certificate or redirect is automatically configured correctly on every platform without checking.

If tracking is used, list the tools actually integrated and their associated purposes. Check which choices visitors can make and whether the technical integration follows their decision. Tracking only with consent also means not activating unnecessary measurement as a precaution. A successful technical test cannot replace a specialist data protection review.

Access handover belongs in launch preparation. Establish who owns key accounts, who needs administrative rights and how multi-factor authentication and recovery are organised. Do not hand over shared passwords in unsecured messages. Brief training can enable those responsible to maintain everyday content without unintentionally changing technical settings.

Coordinate launch and follow - up checks

A launch needs an agreed time and clear responsibility. Inform everyone involved, avoid parallel changes and record how to roll back or request support if problems occur. Check that the latest version is backed up and the responsible people have the access they need. A backup is only useful if its location is known and people understand the basic process for starting a restoration.

Immediately after publication, repeat the main tests on the public domain: homepage, navigation, forms, contact links, HTTPS, mobile view and key pages. Check redirects from old addresses and avoid chains or destinations that no longer exist. An understandable error page should guide people back to helpful content. Also check that no accidental noindex protection is active and that the sitemap is accessible.

Arrange follow-up checks rather than treating launch as a one-off finishing point. Check new enquiries, internal notifications, error reports and search engine notices. Assign content or technical changes to a responsible person. If support with planning or checking would be useful, you can request a website analysis or discuss website creation. This keeps the next step aligned with your actual needs.

The complete pre - launch checklist

The checking route from content to follow - up

Work through the checks in a clear sequence: content and approval first, then features and device views, followed by technical settings and measurement. Finally, publish and check again. This sequence reduces the risk of a late page change invalidating earlier test results.

Not every task belongs to the same person. Distribute responsibility for content, the domain, forms, analysis and backup. Record status and timing so an outstanding check is not silently treated as complete. If a technical or data protection point is unclear, expert clarification before launch is better than an unsupported assumption. A brief follow-up check remains part of the plan after launch.

Summary

• Check content, contact methods and key features before launch.
• Make targeted checks of mobile views, the domain, HTTPS and search engine settings.
• Activate tracking only with consent and after checking the actual integration.
• Define access, responsibilities, backup and follow-up checks.

Frequently asked questions

Sources

1. Robots Meta Tags Specifications | Google Search Central | Documentation | Google for DevelopersGoogle Search Central · checked on 2026 - 11 - 05
2. What Is a Sitemap | Google Search Central | Documentation | Google for DevelopersGoogle Search Central · checked on 2026 - 11 - 05
3. Web Vitals | Articles | web.devweb.dev · checked on 2026 - 11 - 05

Related articles

• Connecting a domain to your website: explained step by step
• Setting up and using Google Search Console correctly
• Optimising images for websites properly