A launch moves an approved website into a real operating environment. Acceptance testing matters, but production has its own risks: missing credentials, redirects to old pages, forms that never deliver, and a rollback nobody has rehearsed. Use this checklist to assign those responsibilities and verify the public site after the release.
Identify exactly what is being released
Record the release version, the production hostname, the deployment owner, and the time window. List whether the release changes the frontend, backend, database structure, uploads, or email delivery. A successful frontend build does not establish that the correct backend is running or that its storage configuration is ready.
Before deployment, check the production configuration against the application’s documented requirements. Name the responsible person for each external service: authentication, email, payments, file storage, and any integrations. Verify credentials through safe test operations without copying secrets into a launch document. If preview and production use different services, test each target explicitly.
- Record the source revision and the expected frontend and backend deployment targets.
- Confirm access to DNS, hosting, application logs, and any service needed to recover the site.
- Confirm when caches expire or need revalidation, and how to distinguish a stale response from the new release.
- Keep the final acceptance record separate from the operational release checklist.
Use the UAT checklist for acceptance before the launch window
Check search access, canonical URLs, and redirects
Make an inventory of important public URLs and, for a redesign, their former addresses. Match retired pages to the most relevant replacement instead of redirecting every old address to the homepage. Inspect the final destination and status of representative redirects, including the preferred host and HTTPS. Avoid chains when a direct destination is available.
- Confirm that public pages return usable content and are accessible without a login.
- Inspect important pages for accidental noindex directives left over from staging.
- Review robots.txt without assuming that a disallow rule removes a page from search results.
- Use consistent preferred URLs in canonical tags, internal links, and the sitemap.
- Remove staging, account, and duplicate parameter URLs from the public sitemap.
Google distinguishes crawling from indexing: robots.txt manages crawler access, while noindex or access protection serves different purposes. A sitemap helps discovery and does not guarantee indexing. Check both the page response and the settings that produced it.
Test that important actions actually arrive
For an inquiry site, submit a clearly labeled test inquiry on production and verify that the intended inbox or system receives it. Seeing a success message is only the first half of the test. Check the received content, attachments, links, and reply destination. Remove or label test records according to your team’s procedure.
Exercise file uploads through the complete path: select a small safe file, save the record, reopen it, and retrieve the file as the intended user. Test an expired sign-in session where relevant. Check authentication redirects on the public host, especially if login uses a separate window or an embedded widget.
If the site accepts payments, use the provider’s documented safe verification method. Record which parts were checked and which need a live follow-up; do not describe a test-mode transaction as proof that production payments settled. For email, verify the sender and destination configuration instead of checking only that an API request returned successfully.
Prepare consent, backups, and recovery
Review optional tracking in both consent states. Load the site before making a choice, decline optional tracking, and then enable it. Verify behavior through the implementation and appropriate browser tools. A banner appearing on the page is not evidence that the underlying collection respects its setting. Ask the responsible specialist to review requirements that apply to your site.
Document what rollback restores and what it cannot undo. Returning to a previous frontend may leave database changes, published content, and customer submissions intact. Identify compatibility constraints before release, preserve necessary backups, and name the person who can run the recovery procedure.
| Finding | Decision to make |
|---|---|
| New code requires a schema migration | Who runs it, verifies completion, and handles partial failure? |
| Old content URLs change | Which exact replacements preserve the visitor’s destination? |
| Email service is unavailable | Does the site queue messages, show a retry, or block the action? |
| Release needs to be reverted | Can the earlier application read data created by this release? |
Verify the public release and own the follow-up
After deployment, test the public hostname from a fresh browser session and confirm that the intended release is visible. Repeat the few journeys that matter most, verify delivery again, and review errors. If a new page initially returns a cached response, retest appropriately before making a diagnosis.
In Search Console, inspect representative public pages, review the sitemap, and investigate exclusions before requesting indexing. Google says recrawl requests do not guarantee inclusion or immediate processing. Record the check date and the observed status so a later review can distinguish an old report from a new problem.
Google: request recrawling and understand its limits
Assign the first post-launch review a date and an owner. Check real errors, failed submissions, broken destinations, and user reports. Annot8 can collect page-specific feedback; if you want its widget visible on production, enable that project setting deliberately. Analytics additionally needs both project enablement and page consent.
