What Should Be Checked After a Website Goes Live?
Post-launch checks confirm that the public website, its customer journeys and its supporting services work outside the test environment.
Part of our guide: How to Replace an Existing Website: A Step-by-Step Guide
After a website goes live, immediately verify the public pages, forms, email, redirects, security and measurement, then monitor search visibility, performance and customer feedback over the following weeks. A successful deployment is only the beginning of launch verification.
Tests should use the public domain from ordinary networks and devices. A site can work in staging or for the development team while failing for customers because of DNS, caching, permissions or production configuration.
Start with the essential public journey
Open the preferred HTTPS address in a private browser window. Visit the homepage, main service pages, contact route and any high-value landing pages.
Complete the most important action as a customer would. Submit a genuine test enquiry, make a test booking if a safe process exists, or complete the agreed equivalent.
Confirm the visitor sees an accurate outcome and the business receives what it needs to respond.
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.
Carry the launch responsibility worksheet into the public verification so unresolved tasks retain an owner.
Confirm the correct version is live
Check that the public site contains the approved content and release. Look for staging banners, placeholder copy, old images and missing pages.
Verify the preferred hostname, HTTPS and page canonical links. Make sure alternate hostnames and HTTP requests reach the correct secure destination without unnecessary hops.
Test from a connection outside the office or supplier network. Local DNS and cached sessions can conceal a public problem.
Test every form again
Production form settings often differ from staging. Submit each public form with valid information and check delivery, acknowledgement, reply-to behaviour and any customer record created.
Repeat key validation tests. Confirm errors remain helpful and that spam protection does not block reasonable submissions.
Review logs or provider dashboards for failures. Do not rely solely on an on-screen success message.
Verify email continuity
Send messages to important business addresses from an external account and reply. Test shared mailboxes and aliases that support enquiries.
Check website-generated messages separately. Normal mailbox delivery does not prove that the new web server or form provider is authorised to send.
If mail changed unexpectedly, compare DNS with the pre-launch record and the mail provider’s required settings. Avoid speculative changes to multiple records at once.
Check DNS and certificates
Confirm that public DNS resolves to the intended service across relevant locations. Propagation can vary when records have recently changed.
Inspect the certificate on the preferred domain and valid variants. Check expiry arrangements and automatic renewal ownership.
Remove temporary verification records only when their provider confirms they are no longer needed. Preserve mail and third-party service records.
Run the redirect list
Test every mapped old URL and verify its response status, final destination and number of hops. Permanent moves should reach one relevant, working page directly.
Look for loops, chains and redirects to errors. Confirm that old documents and campaign URLs included in the migration plan still work.
Use the URL redirect guide to review the difference between permanent, temporary and irrelevant redirects.
Look for broken links and missing assets
Crawl the public website after deployment. Find internal links that return errors, images that fail to load and files that were not copied to production.
Manually review important results. A response can be technically successful while displaying the wrong page or an access-denied message.
Check navigation, footer, breadcrumbs and article cross-links on several page types. Correct internal links to the final URL instead of relying on redirects.
Verify robots and sitemap files
Open the public robots file and make sure production content is not blocked by a staging rule. Review page-level robots directives on representative pages.
Check that the XML sitemap loads, uses the public hostname and contains only intended canonical pages. It should not list drafts, redirects or error pages.
Submit or resubmit the sitemap through the relevant search-engine tools after confirming it is correct. Google’s sitemap documentation explains submission and reporting.
Inspect search-engine access
Use Search Console URL Inspection on the homepage and selected important pages. Confirm that Google can access the live version and sees the intended canonical information.
Do not request indexing for hundreds of URLs individually. A correct internal structure and sitemap support normal discovery.
Google’s site move guidance recommends monitoring both old and new URLs when addresses have changed.
Confirm analytics and events
Visit the site with the appropriate consent choices and verify that the production analytics property receives the visit. Test the few meaningful events agreed before launch.
Check that staging hostnames, internal tools and duplicate tags are not inflating reports. Compare event names and definitions with the measurement plan.
Never submit real sensitive information merely to test tracking. Analytics should not capture form contents that the business has no reason to record there.
Test consent and privacy controls
Try accepting, rejecting and changing optional consent. Confirm governed services follow the choice and that the preference control remains available.
Review the live privacy and cookie information against the actual production tools. A late script addition can make approved wording inaccurate.
Check that essential functions remain usable when optional tracking is refused.
Review accessibility in production
Repeat keyboard navigation, zoom, focus and form tests on the public site. Production widgets, consent tools and optimised assets may behave differently from staging.
Run automated checks on representative templates, then inspect results manually. The Web Content Accessibility Guidelines remain the reference for success criteria.
Ask people to report barriers through an accessible contact route. Prioritise anything that prevents navigation, understanding or completion of an essential task.
Measure real performance
Test representative public pages on mobile and slower connections. Watch for delayed images, layout movement, blocked fonts and scripts that perform differently through the live domain.
Synthetic tests provide immediate diagnostics. Field data takes time to accumulate and reflects actual visitors and devices. Google’s Core Web Vitals guidance explains the distinction.
Investigate regressions against the tested build. CDN, tag-manager and third-party configuration are common production differences.
Check responsive layouts on real devices
Review the public site on several phone sizes as well as desktop. Open menus, submit forms, rotate the screen and follow links into third-party services.
Look for content hidden behind banners, overflowing headings, cropped images and controls too close together. Test real page content, including the longest titles.
Record the device, browser and evidence for each issue so it can be reproduced.
Review server and application errors
Inspect hosting, application and edge-service logs for unexpected errors. Establish a normal baseline rather than waiting for a customer report.
Pay particular attention to repeated failures on public routes, form endpoints and asset requests. Distinguish real customer problems from automated requests for paths that never existed.
Configure alerts for material outages without generating so much noise that warnings are ignored.
Watch 404 reports
Some missing URLs will only surface after launch through old bookmarks, external links or search crawls. Review 404 logs and Search Console reports regularly.
Add a redirect when an old URL has a clear, useful replacement. Do not send arbitrary or malicious requests to the homepage.
Improve the not-found page so a genuine visitor can search, navigate or contact the business when no replacement exists.
Verify structured data and sharing previews
Test structured data on page types that use it and correct production-only URL or image errors. Markup must describe content that visitors can see.
Share selected pages privately in the platforms important to the business and inspect title, description and image previews. Cached previews may need time or platform-specific refreshing.
Do not delay essential launch repairs for cosmetic social-preview issues, but record them for prompt correction.
Protect the old platform for now
Do not immediately cancel old hosting, delete its database or remove access. Retain a secure backup and the ability to investigate missing content during the agreed transition period.
Prevent any retained copy from becoming an indexable duplicate. Restrict it or keep it offline according to the migration plan.
Once the replacement is proven, close obsolete services deliberately and export records the business must retain.
Gather feedback from customer-facing staff
Ask the people answering calls, messages and enquiries whether customers encounter confusion. They may notice missing explanations or broken journeys before analytics show a pattern.
Give staff a simple reporting route with the affected page, action, device and time. Separate urgent faults from suggestions.
Treat repeated questions as content evidence. The site may be technically correct but still unclear.
Monitor search visibility sensibly
Track indexed pages, crawl problems, impressions and clicks for important topics. Expect some fluctuation after substantial changes and compare appropriate periods.
Do not react to one day’s movement by making broad, untested changes. Look for patterns connected to lost content, incorrect redirects, blocking or changed relevance.
The guide to redesigning without losing rankings explains what can be protected and what cannot be guaranteed.
Prioritise post-launch issues
Use impact and urgency. Security faults, unavailable pages, broken forms, inaccessible core navigation, lost email and incorrect legal claims need immediate attention.
Next address widespread confusion, important redirect gaps and performance regressions. Cosmetic inconsistencies can follow through the normal improvement process.
Record each issue, owner, decision and verification result. A hurried repair is not complete until it has been retested in public.
Establish an ongoing maintenance rhythm
Move from launch monitoring into routine ownership. Schedule content reviews, dependency updates, backups, security checks and accessibility testing.
Review analytics against business questions rather than reporting numbers without action. Test forms periodically and whenever email, integrations or hosting change.
Keep the URL and redirect record current. Future editors should understand why important routes must be preserved.
Suggested checking schedule
During the first hour, verify public access, certificates, essential pages, forms, email, redirects, robots and analytics. During the first day, complete the crawl, device checks and log review.
During the first week, review 404s, search access, customer feedback and performance. During the following month, assess indexing, field performance and real customer journeys.
Adjust the schedule to traffic and risk. A transactional or time-critical service needs closer monitoring than a small informational brochure site.
Frequently asked questions
How long should a website be monitored after launch?
Monitor closely through the initial days and weeks, then continue routine checks for the life of the site. Search migration effects can take longer to become clear.
Should the old hosting be cancelled immediately?
No. Keep a secure backup and an agreed transition period until the new site, data and redirects are verified.
Why test forms again if they passed in staging?
Production domains, credentials, mail permissions and integrations can differ. Only a public end-to-end test proves the live path.
Are ranking changes proof that the launch failed?
Not by themselves. Investigate technical access, content, redirects and normal market variation before drawing a conclusion.
What is the first thing to fix?
Fix anything that compromises security, blocks a core customer task, loses an enquiry or prevents access to essential information.
Treat launch as a monitored transition
Verify the essentials on the public website, then keep monitoring as customers use it. Review the evidence over time and give every meaningful issue a clear owner.
Afterworks includes launch and post-launch verification within website rebuilds so the replacement is supported beyond the moment it goes live.
