Pre-launch checklist for a small business website

Run this list before the domain is pointed at a new site, and run the last section again once it is live. Every item is written as something you can verify, not something you hope is true. It is the gate in my launch process: the DNS change is not scheduled until every box is checked. If someone else is building your site, you can use it to check their work.

Content and facts

Placeholders survive launch because people look for them on the pages they can see. Search the site's files as well.

• Every phone number, address, email address, price, and set of hours has been confirmed by the owner, on every page, not only the homepage.
• No placeholder content remains: no dummy filler paragraphs, no "coming soon" sections, no stand-in prices, and no demo controls such as a color switcher.
• A search of the site files for any placeholder phone number, address, or email comes back empty, including tap-to-call links, the footer, and meta descriptions.
• Structured data (schema) holds verified facts only: the real business name, phone, address or city, and hours. Placeholder data in schema is worse than no schema.
• No invented reviews, testimonials, star ratings, or logos of companies that are not customers appear anywhere.
• Claims about licenses, certifications, insurance, and years in business have been confirmed with the owner.
• Every stand-in photo has been replaced with the owner's real photos, with location data stripped from the image files.
• Hard policies are honored, such as keeping the street address off the site for a business that works at customers' homes.

Search

• The noindex tag is gone from every production page, and the server is not sending an X-Robots-Tag: noindex header. Review and demo copies keep theirs.
• robots.txt exists, allows crawling, and points to the sitemap.
• sitemap.xml exists and lists production URLs on the real domain only.
• Canonical tags and social sharing (Open Graph) URLs point at the real domain, not a staging or review address.
• Every page has its own title of about 55 characters and its own meta description of about 150.
• Every page has one H1 that says what the page is about.
• Structured data passes a validator, with a LocalBusiness type, hours, and a city-level address.
• A 301 redirect map covers every URL in the old site's sitemap, each pointing at the closest new page.
• Every internal link resolves, and the built site has no 404s.

Measurement

• The Google Tag Manager snippet is on every page: the script immediately after the charset tag in the head, and the noscript part immediately after the opening body tag.
• The container ID is the business's real ID, it appears exactly twice on each page, and no placeholder ID remains anywhere.
• Tag Manager's preview mode connects to the site and shows the container firing on page load.
• A test page view shows up in GA4's realtime report before launch, so results can be measured from day one.
• Key events fire on real actions: a form submission the server confirmed, a tap on the phone number, and a click on the email link.

The GA4 and Tag Manager quickstart covers setting those events up.

Forms

• A real submission sent through the live page arrived in the business's inbox and the backup inbox, not in spam.
• The same submission appears as a new line in the submission log.
• Replying to the notification email addresses the customer, not the website.
• The inbox that receives leads belongs to someone who checks it every day.
• A submission with the hidden spam-trap field filled in returns success but sends no email and writes no log line.
• Repeated submissions from one IP address are refused after the limit, with a message that gives the phone number.
• When a submission fails, the page shows an error with the phone number. It never shows a thank-you for a message that was not received.
• Source fields, such as click IDs and UTM tags, arrive with the submission.
• No API keys, mail passwords, or tokens appear anywhere in the page source.
• The submission log and any configuration files return a 404 when requested directly by URL.

The full build is in Build contact forms that actually reach you.

Mobile at 375 pixels

Set your browser's developer tools to a 375 pixel wide viewport, then confirm on a real phone.

• Every page has been checked at a 375 pixel width.
• The menu opens with a tap, covers the screen, closes again, and every link in it works. It also works with a keyboard.
• No page scrolls sideways.
• Buttons and menu links are at least 44 pixels in each direction.
• The headline reads without zooming, and the main call to action is not hidden on phones.
• Phone numbers are tap-to-call links.
• Form fields use at least a 16 pixel font, so iPhones do not zoom in when a field is tapped.

Speed and images

• Images are compressed and served in a modern format such as WebP, in responsive sizes (for example 480, 800, and 1200 pixels wide) so phones do not download desktop images.
• Images below the first screen load lazily.
• The homepage's total download on a phone is under roughly 600 KB.
• Fonts load with a preconnect, and every font the styles declare actually loads.
• The site has a real favicon set: an .ico file, a PNG, and an Apple touch icon.

One old homepage I replaced shipped about 2.4 MB. The 600 KB budget exists so the new one never does.

Accessibility basics

• Text and background colors pass WCAG AA contrast, including any colors added after the design system was set.
• Every meaningful image has alt text that describes it, and decorative images have empty alt text.
• Every form field has a visible label.
• Headings run in order: one H1, then H2s, then H3s inside them.
• Each page declares its language, such as lang="en".
• Link text says where the link goes, and a keyboard user can see which link or button has focus.
• Animation stops or reduces for visitors who have set their device to reduce motion.
• Form errors and the thank-you message are announced to screen readers.

Legal pages

• A privacy policy is published, linked from the footer of every page, and describes what the site actually collects: form fields, analytics, and any advertising pixels.
• Terms of service are published and linked from the footer if the business needs them.
• If the site needs a consent banner for its visitors, the banner works and has been tested before launch, not added later.
• Someone qualified has reviewed the legal pages. A template is a starting point, not a finished policy.

Ownership

A site the business cannot take with it is a liability. Everything below should survive the business changing who helps with its website.

• The domain is registered to the business, in a registrar account the business controls, with auto-renew turned on.
• DNS is managed in an account the business can log in to.
• The hosting account is in the business's name, or, if the builder hosts the site, the business can get a complete copy of the site files at any time.
• The business is the primary owner of its Google Business Profile.
• Google Analytics, Tag Manager, Search Console, and any ad accounts belong to the business, with the builder added as a user the business can remove.
• The business knows where every login is kept.
• A current backup of the site files exists somewhere other than the web server, such as a private Git repository.

After launch

Run these on the live domain the day the DNS change goes through. Repeat the form and tracking checks after every deploy.

• Every old URL returns a 301 to the right new page, confirmed by requesting each one.
• New pages return 200 over HTTPS, with a valid certificate on both the www and the bare domain.
• The live pages carry no noindex tag.
• A real form submission from the live site produced both the email and the log line.
• Tag Manager's preview mode connects to the live domain, and the key events fire.
• The sitemap is submitted in Search Console, and the page indexing report is checked over the next one to two weeks as old URLs drop out and new ones are indexed.
• The Google Business Profile's website link points at the right page on the new site.
• The old hosting is cancelled only after the new site is verified live and indexed.
• An uptime check is watching both the site and the form endpoint.