What Should Be Checked Before Launching a New Website?
A thorough pre-launch check proves that a new website is accurate, usable and ready to replace the current site without avoidable disruption.
Part of our guide: How to Replace an Existing Website: A Step-by-Step Guide
Before launching a new website, check that its content is accurate, its important customer journeys work, its pages are accessible and responsive, and its technical migration plan protects existing URLs, email and measurement. The final decision should be based on recorded evidence, not simply how polished the homepage looks.
A useful pre-launch process gives every check an owner, an expected result and a status. It also separates launch-blocking faults from improvements that can safely follow later.
Confirm the launch scope
Start with an agreed list of pages and functions that must be live. Compare the built website with the approved page map, content plan and requirements. This prevents a forgotten service page or integration being discovered after the switch.
Record any deferred work and make sure it does not leave an incomplete customer journey. A planned later enhancement is different from an essential feature that quietly missed the deadline.
Confirm who can approve launch, who will make technical changes and who can decide to roll back.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
Assign owners, evidence and an approval decision using the launch responsibility worksheet.
Review every page of content
Read the published view rather than relying only on source documents. Check headings, body copy, captions, calls to action, contact details, opening hours, prices and legal statements.
Look for placeholder text, internal notes, empty sections and claims that have not been approved. Test telephone numbers and email links. Confirm names, job titles and service areas with their owners.
Make sure each page answers the question implied by its title. A well-written page can still fail if it does not help the intended visitor make the next decision.
Check spelling, consistency and originality
Review copy for spelling, grammar, tone and consistent terminology. Search the site for old company names, outdated offers and text copied from templates.
Original writing should express the organisation’s own knowledge. Cite authoritative sources where an important factual claim, rule or statistic depends on external evidence. Do not publish copied passages simply because a source is linked.
Check that punctuation follows the editorial guide and that headings use a consistent style.
Inspect images and other media
Confirm that every image is licensed or owned for the intended use. Remove old stock images that no longer fit the brand and check that generated images follow the project’s visual rules.
Meaningful images need concise alternative text that communicates their purpose. Decorative images should use an empty alt attribute so assistive technology can ignore them. The W3C image decision tree provides practical guidance for choosing the right treatment.
Check crops on wide and narrow screens. Compress large assets and provide appropriate dimensions so images do not cause layout shifts or unnecessary downloads.
Test navigation and internal links
Use the main navigation, footer, breadcrumbs, article links and calls to action. Every link should lead to the intended current destination.
Check keyboard access to menus and ensure focus does not become trapped. Confirm that the active state is understandable and that visitors can return from deeper pages.
Run an automated broken-link check, then manually test the most important routes. Automation can confirm that a page responds, but not that it is the right destination.
Test forms from beginning to end
Submit every public form with realistic valid information. Confirm validation, consent wording, error messages, success messages and the notification received by the business.
Test missing and invalid fields. Errors should identify the problem clearly and preserve information that the customer already entered where appropriate.
Check the sender and reply-to behaviour. A confirmation displayed in the browser does not prove that the enquiry reached the correct inbox or customer system.
Test the primary customer journeys
Write down the essential tasks, such as understanding a service, requesting a quote, finding directions, booking an appointment or downloading information. Complete each task on the built site.
Test from common entry pages, not only from the homepage. Search visitors often arrive deep within a website and need enough context to continue.
Ask somebody who was not involved in the build to try the tasks. Familiarity can make missing explanations and confusing labels difficult for the project team to notice.
Review accessibility
Navigate the site with a keyboard and verify visible focus, logical order and usable controls. Zoom the page and increase text size. Check colour contrast, headings, form labels, status messages and alternatives for non-text content.
Automated accessibility tests are useful but incomplete. Combine them with manual inspection and task-based testing. The Web Content Accessibility Guidelines provide the recognised success criteria behind these checks.
Do not postpone known barriers simply because they affect a minority of visitors. Accessibility faults often expose wider usability and code-quality problems.
Check mobile and responsive layouts
Test real phones and tablets as well as resized desktop windows. Review navigation, forms, tables, long headings, cards, accordions and sticky elements at several widths.
Check portrait and landscape orientation. Make sure touch targets are usable and that content is not hidden behind consent banners or fixed controls.
Use realistic content lengths. A component that works with a two-word title may fail when the real article title wraps across several lines.
Test browsers and device capabilities
Agree which current browsers and devices the organisation supports. Check representative versions rather than testing only in the development team’s preferred browser.
Verify downloads, telephone links, email links, maps and embedded services. Test what happens when scripts, cookies or third-party resources are unavailable.
The site should fail honestly. A booking button should not appear successful if the service behind it is blocked.
Review performance
Test important page types on mobile and slower network conditions. Look for oversized images, excessive scripts, font delays and layout movement.
Measure representative pages rather than treating one homepage score as proof of site-wide performance. Google explains the current user-experience measures in its Core Web Vitals documentation.
Investigate the causes of poor results. Do not remove useful content or accessibility features merely to improve a synthetic score.
Check page titles and descriptions
Every indexable page should have a unique, accurate title. Meta descriptions should summarise the page honestly and help a searcher understand its value.
Check one clear main heading, sensible heading order and descriptive link text. Confirm that social sharing metadata uses the intended title, summary and image where it is supported.
Avoid keyword repetition. Metadata should represent the page for people first.
Verify canonical, robots and sitemap settings
Check that canonical links point to the intended public HTTPS URLs. Remove development hostnames and ensure the preferred hostname is consistent.
Review robots directives at both page and site level. Staging environments may be blocked, but those settings must not accidentally prevent public pages from being indexed after launch.
Generate the XML sitemap from final public routes. Exclude drafts, redirected URLs, error pages and private areas. Google’s sitemap guidance explains what a sitemap can and cannot do.
Inventory old URLs
Compare the current public website with the replacement. Preserve URLs where their purpose remains the same. For every changed address, choose the closest relevant new destination.
Build and approve a redirect map before launch. Include valuable pages, documents and known variants. The explanation of URL redirects and why they matter covers status codes, chains and destination choices.
Test every planned rule against the built website. A redirect to a missing or unrelated page is not a successful migration.
Check analytics and consent
Define what genuinely needs to be measured and why. Verify that analytics uses the correct production property and does not contaminate reports with staging traffic.
Test consent choices, withdrawal and any tags governed by those choices. Confirm that privacy information accurately describes the services in use.
Check key events, such as form submissions, without recording sensitive form contents. Measurement should support decisions without collecting unnecessary data.
Protect domains, DNS and email
Record domain registrar, DNS provider and administrators. Export or capture the existing DNS configuration before any change.
Identify exactly which records the launch will alter. Preserve MX, SPF, DKIM, DMARC and verification records unless email is intentionally migrating as a separate project.
The guide to what happens to email during a rebuild provides a dedicated continuity checklist.
Review security and privacy
Confirm HTTPS, certificate coverage, secure form handling and appropriate headers. Remove test accounts, default passwords, exposed keys and development diagnostics.
Apply updates and scan dependencies according to the chosen platform. Restrict administration to people who need it and enable stronger authentication where supported.
Collect only information the business needs. Confirm retention, access and deletion processes with the responsible people rather than assuming the website supplier owns those decisions.
Prepare backups and rollback
Take a verified backup of the current site, its database and relevant configuration. Record how it would be restored and who has access.
Define the conditions for rollback, such as unavailable primary journeys, broken email or widespread server errors. Agree who makes the decision.
A backup is not a rollback plan unless the team knows how long restoration takes and which changes would need to be reversed.
Create a launch runbook
List actions in order with owners, timings and evidence. Include deployment, DNS or proxy changes, redirect activation, cache clearing, certificate checks and public verification.
Choose a time when the necessary business and technical people are available. Avoid tying launch to a promotional deadline unless the system has already been proven.
Prepare a communication route outside the website and affected domain for incident coordination.
Set launch acceptance criteria
Classify issues by impact. A broken enquiry route, inaccessible navigation, missing legal information or lost email is normally a blocker. A minor spacing inconsistency may be recorded for later.
Require evidence for essential checks. Screenshots, test submissions, crawl reports and redirect results create a shared record of readiness.
Make the launch decision explicit. Silence from reviewers should not be treated as approval.
Frequently asked questions
Does every page need to be perfect before launch?
Every published page should be accurate, complete and safe to use. Minor non-blocking refinements can follow when they are documented and owned.
Is an automated website audit enough?
No. Automation is excellent for repeatable technical checks, but people must judge accuracy, relevance, usability and real customer journeys.
Should the old website be taken down during testing?
Usually not. Keep it live while the replacement is tested separately, then switch deliberately when the new site is ready.
When should redirects be tested?
Test the configuration before launch where possible, immediately after the switch and again during post-launch monitoring.
Who should approve the website?
Named owners should approve content, business processes and technical readiness. One person should hold the final launch decision.
Launch when the evidence supports it
Record the results of the checks before agreeing to launch. Test the content and customer tasks, protect the existing domain and URLs, and agree how the team will respond if something goes wrong.
Afterworks manages these checks as part of a controlled website replacement process and practical website rebuild service.
