The short answer
A launch is a business acceptance decision, not merely a deployment. Name the decision-maker, define blockers and rollback conditions, collect evidence before and after production release, test real enquiries, and assign owners for the first 30 days. A signed exception list keeps minor defects visible without allowing critical failures to hide.
- Define observable acceptance criteria and launch blockers before go-live day.
- Test the production domain, forms and receipts rather than relying on staging evidence.
- Check search controls, canonicals, redirects and sitemap after deployment.
- Operate a scheduled 30-day review with named owners and prioritized fixes.
On this page
Define go-live acceptance and authority
A website is ready when agreed customer tasks work in production and accountable people accept known risk. A completed development task list is useful evidence, but it is not the business decision.
Name one launch decision-maker, technical lead, content owner and contact for lead delivery. Set a decision time, rollback trigger and communication route. Decide what blocks launch before pressure rises.
For a lead-generation site, a broken form, wrong domain, exposed staging restriction or lost high-value URLs should block release. A minor decorative inconsistency can enter a dated follow-up queue if it does not obstruct the task.
- Name the person with final go or no-go authority.
- Define rollback ownership and the latest safe decision time.
- Separate blockers from accepted follow-up work.
- Store evidence beside each acceptance item.
| Item | Owner | Evidence | Go or no-go rule | Retest |
|---|---|---|---|---|
| Lead form | Sales operations | Received production message | Failure blocks launch | Required |
| Canonical domain | Technical lead | Header and redirect check | Wrong host blocks launch | Required |
| Minor spacing issue | Design owner | Screenshot | May enter follow-up queue | Scheduled |
| Privacy copy | Business owner | Approved production page | Missing approval blocks launch | Required |
Sign off content and customer journeys
Review the website as a customer would. Confirm service descriptions, scope, contacts, locations and calls to action. Follow navigation and internal links across mobile and desktop, including empty and error states.
Use named journeys rather than a vague visual review. Can a visitor identify the offer, assess fit, reach relevant proof and submit an enquiry? Can staff explain what the visitor was promised? Check downloads, phone links and email addresses.
Freeze critical copy for the deployment window. Late edits without review are a common way to reintroduce broken links and unapproved claims.
- Approve claims, contacts, calls to action and legal notices.
- Check menus, search if present, downloads and error pages.
- Test long content and translated variants.
- Record intentional omissions and their owners.
| Journey | Start | Successful end | Evidence |
|---|---|---|---|
| New prospect | Landing page | Accepted enquiry and receipt | Mobile and desktop test |
| Returning buyer | Saved service URL | Current service detail | Redirect and content check |
| Wrong URL | Nonexistent path | Useful error page with true 404 | HTTP response and page review |
| Language switch | Localized service | Equivalent localized page | Cluster test |
Confirm accessibility blockers are resolved
Run a focused manual review of the critical journeys. Keyboard focus should be visible and logical, controls should remain unobscured, form labels and errors should be understandable, and zoom should not hide essential actions.
W3C's Easy Checks are deliberately preliminary. They support launch triage but do not certify conformance. Combine them with automated results, component testing and broader evaluation appropriate to the project.
Keep unresolved findings in the signoff record with customer impact and an owner. Navigation traps, unusable forms and hidden actions are blockers, not cosmetic backlog.
- Complete the journey with a keyboard.
- Check focus, headings, alternatives, contrast and form recovery.
- Test zoom, narrow reflow and moving content.
- Retest fixes in production.
Verify production technology and ownership
Confirm HTTPS, canonical host redirects, production environment settings, error handling, backups and monitoring. Inventory third-party services such as forms, consent, maps, video, fonts and CRM connections, then identify who owns each account.
Test from outside the project team's authenticated sessions. Cached credentials and administrator cookies can hide failures. Use a private browser and a mobile network where practical.
Handover should include domain, hosting, repository, analytics and search accounts, recovery methods, supplier contacts and renewal responsibilities. Avoid a launch that works only while one contractor remains available.
- Confirm domain and certificate behavior.
- Check backups and a realistic restore owner.
- Test error pages and external dependencies.
- Document account ownership and renewal dates.
| Asset | Business owner | Technical access | Recovery method | Renewal or review |
|---|---|---|---|---|
| Domain | Named company role | Registrar administrators | Documented recovery contact | Before expiry |
| Hosting | Named company role | Platform team | Rollback and support route | Quarterly |
| Repository | Named company role | Maintainers | Protected recovery admin | On staff changes |
| Form delivery | Sales owner | Technical and mail admins | Fallback contact route | After every release |
Protect search discovery at launch
Development sites commonly block crawling or carry noindex directives. Before launch, prepare the intended production robots rules and a precise list of pages from which noindex must be removed. Do not remove protection from the staging host itself.
Check production canonical URLs, redirect mappings, hreflang if used, structured data and the sitemap. Google's site-move guidance recommends permanent server-side redirects for lasting URL changes. Deleted pages without a relevant replacement should return a true 404 or 410 rather than redirecting everything to the homepage.
Verify relevant Search Console properties and submit the sitemap. Google describes sitemap submission as a hint, not a guarantee of crawling or indexing. For a small number of priority pages, URL Inspection can support diagnosis and submission.
- Remove unintended production noindex and crawl blocks.
- Validate canonical host, redirects and internal links.
- List fully qualified canonical URLs in the sitemap.
- Keep Search Console access and verification after launch.
Test measurement, consent and lead delivery
Measurement should answer business questions without claiming more precision than the setup provides. Confirm production analytics configuration, consent behavior, internal traffic handling and the events that represent meaningful actions.
Submit a realistic production enquiry from start to finish. Check validation, failure handling, accepted status, delivery to the intended inbox or CRM and the human follow-up route. Provider acceptance alone may not prove final inbox arrival, so inspect the actual destination where possible.
Use test data that is recognizable and safe. Do not place passwords, customer records or confidential information in forms.
- Confirm consent behavior matches the approved setup.
- Verify page views and agreed conversion events.
- Test one successful and one failed form path.
- Confirm the receiving team recognizes and owns new leads.
| Signal | Production test | Business interpretation | Owner |
|---|---|---|---|
| Form accepted | Submit and inspect receipt | System accepted delivery request | Technical owner |
| Message received | Inspect intended destination | Operational handoff works | Sales owner |
| Conversion event | Inspect analytics debug or report | Measurement fired under intended consent | Analytics owner |
| Failed delivery | Simulate safe failure where supported | Visitor receives honest recovery path | Technical owner |
Run a production go or no-go review
Use two evidence stages. Before deployment, approve content, migration rules, configuration and journeys. After deployment, verify actual HTTP responses, canonical domain, forms, consent, sitemap and priority redirects. Staging evidence cannot replace production checks.
Keep the review short enough to execute and strict enough to matter. Each row needs an owner, status and evidence link. Unknown is not passed.
If rollback would create more harm than a controlled fix, the decision-maker may choose a restricted release, but the exception, customer impact and deadline should be explicit.
- Stage one: configuration, content, migration and acceptance readiness.
- Stage two: production responses, customer tasks and delivery.
- Require evidence for pass status.
- Publish the signed exception list to the operating team.
Manage the first 30 days with evidence
Launch begins an operating period. Use a planned cadence rather than watching dashboards continuously or waiting for complaints. The schedule below is an editorial model, not a universal recovery timeline.
On day one, watch critical errors, form delivery, key redirects and production analytics. During the first week, review crawl and indexing signals, customer feedback and high-impact defects. By days 14 and 30, prioritize recurring patterns, content gaps and performance observations.
Core Web Vitals field data accumulates from real visits and should be interpreted at the appropriate percentile and page grouping. Avoid promising that search visibility will settle by a fixed date. Google notes that migrations can take time as pages are recrawled and reindexed.
- Day 1: verify critical journeys and error monitoring.
- Days 2 to 7: review leads, redirects, crawl signals and urgent feedback.
- Day 14: assess recurring issues and owners.
- Day 30: close launch governance and approve the improvement backlog.
| Cadence | Review | Escalate when | Output |
|---|---|---|---|
| Launch day | Forms, errors, redirects, domain | Critical task fails | Fix, rollback or documented restriction |
| First week | Indexing signals, enquiries, feedback | High-value pages or leads fail | Prioritized incident |
| Day 14 | Recurring defects and content gaps | Pattern affects customer decisions | Owned change plan |
| Day 30 | Performance, search, lead quality, backlog | Risk remains unowned | Operating review and next priorities |
YOUR QUESTIONS, ANSWERED
Frequently asked questions
What should block a website launch?
Failures in critical customer tasks, lead or payment delivery, canonical domain setup, privacy approval, security or preservation of valuable URLs commonly justify a no-go decision. Define project-specific blockers in advance.
Is a staging test enough for the contact form?
No. Test the production route, receipt and actual destination because environment settings and delivery bindings can differ.
Does submitting a sitemap guarantee indexing?
No. Google describes sitemap submission as a hint. It supports discovery and monitoring but does not guarantee crawling or indexing.
How soon should rankings stabilize after a relaunch?
There is no fixed promise. Recrawling and reindexing depend on the site and change. Monitor technical signals and customer outcomes without inventing a recovery deadline.
What belongs in the first 30-day review?
Critical errors, lead delivery, redirects, indexing signals, customer feedback, performance evidence and an owned backlog. Adjust cadence to risk and traffic.
CHECK THE DETAIL
