Small-business website launch checklist: what to test before the DNS changes

The launch gate: finished pages are not a finished launch

Do not switch DNS merely because the pages look finished.

A website is ready when the team can prove that customers can complete critical actions, the business receives the results, search and analytics systems see the intended signals, and a responsible person can recover the previous working version. A polished homepage proves none of those things.

Use this website launch checklist as a go/no-go record. Give every group an owner, attach evidence to important checks, and define launch blockers before the launch window.

Passing this risk-control checklist does not certify security or accessibility, prevent every defect, or promise rankings. New sites can take time to be discovered, and migration visibility can fluctuate during recrawling (Google Search Central).

First decide: new website or migration?

A brand-new website has no public URL history to preserve. Make production crawlable, publish accurate metadata and a sitemap, verify ownership, and start a measurement baseline.

A replacement or migration inherits traffic, backlinks, bookmarks, ad destinations and search history. Capture the old URLs and performance baseline, map valuable URLs to relevant new destinations, and test redirects. Google recommends preparing the new site, creating a URL map, using server-side permanent redirects where possible, and monitoring old and new URLs (Google’s site-move guidance).

Do not treat a redesign as new merely because the design changed.

The 12-check critical path

If time is tight, these are the launch blockers. A failure means hold or document a risk decision with the business and technical owners.

• Shared: A named launch lead has authority to call go, hold or rollback.
• Business: The business controls the domain, hosting, source, analytics and key provider accounts; recovery access works.
• Shared: The approved production release is frozen, backed up and identifiable.
• Shared: Every critical call, email, form, booking, checkout or login works end to end.
• Business: Form, order and booking notifications reach the people and systems that must act on them.
• Developer: The production hostname serves valid HTTPS without mixed-content or certificate errors.
• Developer: DNS changes are reviewed against a current zone export, with web and email records treated separately.
• Developer: Mobile navigation and critical tasks work on representative devices and browsers.
• Shared: Keyboard use, focus, labels, contrast and error handling pass manual accessibility checks.
• Developer: Crawl controls, canonicals, sitemap and Search Console ownership are correct for production.
• Shared: Analytics records page views and agreed conversion events under the intended consent states.
• Shared: The rollback method, decision trigger, operator and post-launch monitoring channel are confirmed.

Ownership and access

Owner: business

• Record the owner, administrative contact and renewal method for the domain.
• Confirm appropriate people can recover domain, DNS, hosting, CMS, source, analytics, Search Console, payment, booking and email accounts.
• Remove obsolete access, apply least privilege, and store credentials and recovery codes in an approved password manager.
• Confirm ownership of source, content, licensed assets and data exports. CMT Web’s services process includes source at launch, but verify access.
• Name the launch lead, technical operator, content approver, analytics owner, lead-routing owner and rollback approver.

Content

Owner: designer/content

• Approve services, prices, hours, locations, policies, biographies and claims.
• Check spelling, dates, copyright notices and business-name formatting; remove placeholders, watermarks and test content.
• Confirm every page has a clear purpose and next action.
• Verify contact details, addresses and service areas against a business-controlled source.
• Give meaningful images useful alternative text; use empty alternative text for purely decorative images.
• Check downloads, policies and embedded media on desktop and mobile.
• Confirm the 404 page helps a visitor recover and that genuinely missing pages return a real 404 response.

Navigation

Owner: designer/content

• Test every header, footer, in-page, logo, button and breadcrumb link.
• Confirm the current page and keyboard focus are visually identifiable.
• Check that menu labels match destination headings and do not create surprises.
• Walk from the homepage to every priority service, location and contact action.
• Test external links and the mobile menu, including opening, closing, focus and orientation changes.

Forms and transactions

Owner: shared

• Submit every form and verify the stored record, inbox or CRM entry—not just the success message.
• Test required fields, invalid formats, helpful error messages, duplicate submissions and resubmission after a failure.
• Test every phone and email link on a real phone.
• Complete a real or provider-approved test booking; verify time zone, availability, reminders, cancellation and staff-calendar delivery.
• In provider test mode, verify commerce totals, tax, shipping, confirmation, refunds/cancellations and inventory. Use a live card only with business approval.
• Confirm transactional emails use the intended sender, contain correct links, arrive in representative inboxes, accept replies appropriately and report failures to an owner.
• Confirm anti-spam controls accept legitimate submissions and offer an accessible alternative.
• Remove test recipients, sandbox credentials and debug output before launch.

Mobile and browser testing

Owner: developer

• Test critical journeys on representative real phones, not only a narrow desktop window.
• Cover current audience browsers, including Safari on iPhone and Chrome on Android where relevant.
• Check orientation, zoom, long names, large text, virtual keyboards and touch targets.
• Confirm sticky headers, cookie notices, chat tools and booking widgets do not cover controls or content.
• Test interrupted connections and prevent uncertain submissions from creating duplicates.

Accessibility

Owner: shared

• Navigate every representative template and complete each critical task using only a keyboard.
• Confirm focus order follows the visual task, focus is visible, and dialogs return focus sensibly when closed.
• Check headings, landmarks, link purpose, form labels and error announcements.
• Review text and interface contrast, zoom and reflow, reduced-motion behavior, captions and transcripts where applicable.
• Test an appropriate screen reader/browser combination and run automated checks, then review results manually.

Automation can identify some barriers, but it cannot determine that a site is accessible. W3C WAI recommends early, ongoing testing and knowledgeable human evaluation (WAI evaluation resources). Record the review’s pages, tasks, tools and limitations.

Performance

Owner: developer

• Test the homepage and at least one page from each important template in PageSpeed Insights.
• Investigate slow largest content, layout shifts, delayed interactions and blocking third-party scripts without breaking the customer journey to chase a score.
• Compress and size images appropriately, avoid loading unseen media eagerly, and confirm fonts fail gracefully.
• Check production caching and delivery from a cold mobile load and a customer-relevant location where practical.
• Save the tested URLs, date and results as a baseline. One passing run is evidence for those conditions, not a permanent performance guarantee.

Define ongoing monitoring under managed hosting, not as an assumption.

SEO and indexing

Owner: developer

• Confirm production pages do not carry staging passwords, unintended noindex directives or crawl blocks.
• Check the preferred HTTPS hostname, self-referencing canonicals and internal links for consistency.
• Give important pages accurate titles and descriptions; use production URLs and images in sharing metadata.
• Validate the XML sitemap contains canonical, indexable production URLs and excludes staging, search-result and private URLs.
• Verify the correct Search Console property. Verification is required because the service exposes private site data and search controls (Search Console getting started).
• Inspect representative URLs in Search Console after launch and submit the production sitemap.
• Validate structured data against visible content; for migrations, record organic landing pages, clicks, impressions and rankings without promising they will remain unchanged.

Technical readiness does not guarantee indexing or rankings. Define ongoing search work under SEO services.

Analytics

Owner: shared

• Confirm production sends data to the intended GA4 property and stream.
• Create an event dictionary for meaningful outcomes: successful form submission, qualified call click, email click, completed booking, purchase or other agreed conversion.
• Verify events fire once and only after success, with no personal information in names or parameters.
• Test the intended consent choices: before a choice, after acceptance, after refusal and after preference withdrawal.
• Use Google Tag Assistant preview mode to enable debug mode, then watch the journey in GA4 DebugView (Google Analytics DebugView).
• Check the Realtime report to confirm the property is receiving production data; standard reports can take longer to populate (Google Analytics data confirmation).
• Document internal/test traffic handling and record the launch time.

DebugView proves selected test events arrived, not attribution, reporting quality or every path.

Security and privacy

Owner: shared

• Confirm HTTPS is valid for every public hostname and that HTTP requests reach the intended HTTPS version.
• Remove default accounts, shared logins, unused plugins, exposed test files, secrets and public backups.
• Apply supported software versions and security updates; document who owns future patching.
• Confirm backups are current, separate from production and restorable.
• Review forms, analytics, embeds, cookies and logs against approved privacy and consent behavior; minimize data and define access and retention.
• Check error pages and application responses do not reveal credentials, stack traces or sensitive customer data.
• Enable appropriate uptime, error and certificate monitoring with an alert recipient.

This pass reduces obvious launch risk. It is not a penetration test, legal opinion, privacy certification or guarantee against compromise.

DNS and email

Owner: developer

• Capture the current DNS zone and identify the authoritative provider.
• Separate web records from mail and verification records; label each change, approver and rollback value.
• Preserve required MX and email-authentication records, including the business’s approved SPF, DKIM and DMARC configuration.
• Check whether any vendor depends on a validation record that looks unused.
• Review the planned record names, targets and proxy/CDN settings with the actual hosting and email providers. Do not copy generic values from a checklist.
• Plan propagation and support coverage. A lower cache lifetime helps only if changed early; it cannot make a bad change safe.
• After the change, verify the public hostname, certificate, mail delivery and transactional email from outside the office network.

Do not change mail records unless mail is also changing. Before replacing nameservers, compare the complete old and new zones; the switch can affect far more than the website.

Migration-only checks

Owner: developer

• Export old URLs from sitemaps, analytics, Search Console, the CMS, backlinks and logs.
• Map each valuable old URL to the closest relevant new URL; do not send everything to the homepage.
• Test permanent redirects directly to final destinations, avoiding loops, chains and irrelevant targets.
• Update internal links, canonicals, hreflang, structured data, image references and sitemap entries to new URLs.
• Preserve Search Console verification, analytics tags, downloads and campaign landing pages.
• Confirm removed content returns an honest 404 or 410 when no relevant replacement exists.
• Verify old and new Search Console properties. Use Change of Address only for a qualifying domain or subdomain move.
• Keep redirects active for as long as practical; Google recommends generally at least one year, while user needs may justify longer (Google’s site-move guidance).
• Monitor traffic and crawl behavior on both old and new URLs after cutover.

Launch evidence and approval

Owner: shared

“Passed” should point to something another person can inspect.

Check	Acceptable proof	Approver
Release identity	Deployment ID, commit or immutable build reference	Launch lead
Critical form	Production URL, timestamp, received message/CRM record	Lead-routing owner
Booking or payment	Provider-approved test record and confirmation	Business owner
Phone and email	Device-tested result and monitored destination	Business owner
HTTPS	External certificate result for every public hostname	Developer
Accessibility	Pages/tasks tested, methods, findings and accepted limitations	Shared
Performance	Dated PageSpeed URLs/results and resolved blocker list	Developer
Search readiness	Crawl-control review, sitemap URL and inspected examples	SEO/content approver
Analytics	DebugView event evidence plus Realtime receipt	Analytics owner
DNS and mail	Approved change record, zone capture and external smoke test	Domain owner
Redirects	Tested old-to-new map with status and final destination	Developer
Rollback	Restore/redeploy test or documented rehearsal with operator	Launch lead

Rollback without improvisation

Rollback is the quickest safe route to the last known-good service: perhaps a previous build, origin, database snapshot, feature flag or approved DNS state. Document this site’s steps, operator, access and triggers, such as failed lead delivery, widespread errors, data corruption or checkout failure.

Keep the old site or release recoverable until production smoke tests and agreed stabilization checks pass. There is no universally safe period: a brochure site differs from a booking platform, and DNS cutover differs from data migration. Base the window on data risk, vendor retention, restore time, traffic cycles and downtime tolerance.

“Recoverable” does not mean two public, indexable copies. Restrict the old environment and avoid accepting customer data in two places. Recovery is also separate from redirects: the old application may retire while old URLs continue redirecting.

Launch-day checks

Owner: shared

• Freeze unrelated changes; confirm the release, DNS plan, approvers and support channel.
• Capture the final backup, zone state, URL list and analytics/search baseline.
• Deploy before moving traffic where possible, then run the critical path on the production hostname.
• Make only the approved DNS changes and record the actual time and operator.
• Externally test HTTPS, priority pages, forms, calls, email, booking/checkout, redirects and analytics.
• Purge or refresh caches deliberately, then repeat the critical smoke tests.
• Inspect server, application, CDN and form-delivery errors during the launch window.
• Announce go, hold or rollback with evidence and a named owner for every deferred defect.

Post-launch monitoring

Owner: shared

• In the first hour, watch availability, errors, certificates, critical journeys, lead delivery and analytics.
• During the first business day, reconcile forms, calls, bookings and orders with downstream systems.
• Review Search Console indexing, sitemap and crawl data after collection time; a short delay is not proof of failure.
• For migrations, compare old/new URL traffic, sample logged redirects and watch unexpected 404s.
• Check email bounces, spam placement, consent behavior and third-party widget failures.
• Compare performance and conversion data with the baseline, allowing for normal variation.
• Schedule risk-based day, week and month reviews; move unresolved work into an owned backlog.
• Keep monitoring, backups, updates and incident contacts current. CMT Web’s hosting service covers monitoring, backups, SSL and updates for businesses that want ongoing coverage.

The aim is a calm release with observable proof, not a heroic late-night switch. If you want a second set of eyes on the evidence, rollback plan or migration map, review CMT Web’s services and pricing approach, then request a launch review.

Sources

• CMT Web services
• CMT Web pricing
• Google Search Central: Get your website on Google
• Google Search Central: How to move a site
• Google Search Console Help: Getting started with Search Console
• Google Analytics Help: Monitor events in DebugView
• Google Analytics Help: Confirm data is being collected
• PageSpeed Insights
• W3C WAI: Evaluating Web Accessibility Overview