Skip to main content

Most DIY Launches Are Incomplete

The typical DIY website launch goes something like this: weeks of building in WordPress or Squarespace, a growing sense of urgency as the deadline approaches, a flurry of last-minute content changes, and then someone hits publish. The homepage looks right, the contact form works, and everyone breathes a sigh of relief.

Three weeks later, someone notices the site isn't appearing in Google. A customer mentions the contact form on the services page doesn't actually send emails. The page takes eleven seconds to load on a phone. The privacy policy still says the name of the template company.

None of this happens because people don't care. It happens because standard launch checklists are flat — eighty items presented as equally important, with no context for why any of them matter. When everything is critical, nothing is. People check the easy boxes, skip the ones they don't understand, and hope for the best.

This guide is structured differently. Each section explains why it matters, what actually goes wrong when it's missed, and then gives you the specific items to check. The sections are ordered roughly by business impact: the things that cost you customers and credibility come first.

A Word About AI Website Builders

Tools like Wix ADI, Hostinger AI Builder, and various "build a website in sixty seconds" platforms have made it genuinely easy to get something online quickly. They can generate layouts, suggest colour schemes, and populate pages with placeholder content that looks surprisingly professional at first glance.

What they generate is a starting point, not a finished product. AI builders are reasonably good at visual layout and passable at basic content structure. What they consistently miss is everything below the surface: meaningful information architecture, SEO foundations that will actually help you rank, accessibility compliance, security hardening, and performance optimisation beyond the platform's defaults.

This isn't a criticism — these tools serve a genuine purpose for people who need something basic online quickly. But there's a significant gap between "a website exists" and "a website works for your business," and this checklist is about closing that gap. Whether your site was built by a developer, assembled in WordPress, or generated by AI, every item here still applies.

The risk with AI builders specifically is that they create a false sense of completeness. The site looks done. It has pages, images, text, a navigation menu. But looking done and being ready to represent your business to the world are different things entirely.

Content and Credibility Come First

The items most often skipped at launch are content items, which is unfortunate because they're the ones your visitors will actually notice. A broken security header is invisible to customers. A paragraph of Lorem ipsum on your about page is not.

Business information consistency deserves particular attention. Your business name, address, and phone number need to match exactly across your website, your Google Business Profile, and any directory listings. Google cross-references these details when deciding how confident to be about recommending your business in local search results. "Smith & Co Accountants" on your website and "Smith and Company" on Google creates a trust signal mismatch that quietly undermines your visibility.

Legal pages are a regulatory requirement in the UK, not a nice-to-have. GDPR requires a privacy policy explaining how you handle personal data. PECR governs how you use cookies and electronic communications. If your website collects any information — and a contact form counts — you need these pages in place before launch, not added as an afterthought three months later.

Calls to action should tell visitors exactly what happens next. "Submit" is functional. "Get a Free Quote" is useful. "Click Here" is neither. Every page should make it obvious what the visitor should do next and what they'll get when they do it.

Content Checklist

  • All placeholder text replaced with final copy
  • Spelling and grammar checked on every page
  • Business name, address, and phone number match your Google Business Profile exactly
  • Contact information is correct and consistent site-wide
  • Privacy policy, terms of service, and cookie policy are in place
  • Copyright notice in footer shows correct year and company name
  • All internal links point to the correct pages (no broken links)
  • Every call-to-action button has clear, specific text describing what happens next

Images That Help Rather Than Hinder

For most websites, images are the single largest factor in page load time. An unoptimised hero image can be 3-5MB — larger than the rest of the page combined. Multiply that across a few pages and you've built a site that feels sluggish before anyone reads a word.

Format matters. WebP images are typically 25-35% smaller than equivalent JPEGs with no visible quality loss. Modern browsers all support WebP, so there's little reason not to use it. For logos and simple graphics, SVG gives you sharp rendering at any size with tiny file sizes.

Alt text is not optional. Every image needs a description that makes sense if the image fails to load or is being read by a screen reader. This is an accessibility requirement, but it also helps search engines understand what your images show. "Team photo" is inadequate. "The Smith & Co accounting team in their Witney office" is useful to both humans and machines.

One thing that damages credibility more than people realise: stock photos with visible watermarks, or worse, the generic stock images that appear on thousands of other websites. A visitor who recognises the same "diverse team in a boardroom" image from three other websites instantly questions whether anything else on your site is genuine either.

Image Checklist

  • All images compressed and saved in appropriate format (WebP for photos, SVG for graphics)
  • Every image has descriptive alt text that explains the content, not just a filename
  • No placeholder, watermarked, or stock images that undermine credibility
  • Favicon displays correctly in browser tabs and bookmarks
  • Open Graph images are set for social media sharing previews
  • Logo renders correctly at all sizes and on both light and dark backgrounds
  • Images are responsive and scale properly on mobile devices

The SEO Foundation You Can't Retrofit

Here's what most people don't realise about SEO at launch: Google will crawl and index your site within days of it going live. Whatever it finds first is what it stores. If your page titles are generic ("Home", "Services", "About"), if your meta descriptions are missing, if you've got duplicate content across pages or canonical URLs pointing nowhere — that's the version Google learns. Fixing it later isn't impossible, but it means waiting weeks or months for Google to recrawl, reassess, and update its understanding of your site.

Getting the foundations right at launch is dramatically cheaper than correcting them afterwards. This doesn't mean you need a full SEO strategy before going live — that develops over time. It means the structural elements need to be in place so you're not starting from a deficit.

Page titles are the single most important on-page SEO element. Each page needs a unique, descriptive title under 60 characters that communicates what the page is about. Your homepage title is not "Home" — it's your business name and what you do. Your services page title describes the specific services offered.

Your sitemap is how you tell search engines what pages exist and which ones matter. Generate it automatically, submit it to Google Search Console, and verify it doesn't include pages you don't want indexed (staging URLs, admin pages, test content).

For a deeper understanding of how search engines evaluate websites, our guide to making sense of SEO covers the landscape without the sales pitch.

SEO Foundation Checklist

  • Every page has a unique, descriptive title under 60 characters
  • Meta descriptions are written for each page (under 155 characters, compelling)
  • URL structure is clean and readable — no parameter strings or auto-generated IDs
  • XML sitemap is generated and submitted to Google Search Console
  • robots.txt is configured correctly (not accidentally blocking the whole site)
  • Canonical URLs are set on every page to prevent duplicate content issues
  • Heading hierarchy is logical — one H1 per page, proper H2-H6 structure
  • Structured data (Schema.org) is implemented for your business type

Performance Is a Business Decision

Page speed is not a technical concern. It's a commercial one. Research consistently shows that every additional second of load time reduces conversions by a measurable percentage. For a business that gets fifty enquiries a month through its website, a two-second improvement in load time could mean the difference between fifty enquiries and sixty. Over a year, that adds up.

Google measures three specific performance metrics — collectively called Core Web Vitals — and uses them as ranking signals. Largest Contentful Paint (LCP) measures how quickly the main content loads and should be under 2.5 seconds. Interaction to Next Paint (INP) measures how responsive the page is to user interaction. Cumulative Layout Shift (CLS) measures whether elements jump around as the page loads, which is as annoying as it sounds.

You can check your site's performance using Google's PageSpeed Insights. Don't chase a perfect score — that's a distraction. Focus on passing Core Web Vitals thresholds, because that's what affects both rankings and user experience.

Performance Checklist

  • Largest Contentful Paint (LCP) is under 2.5 seconds on mobile
  • Core Web Vitals pass in Google PageSpeed Insights (LCP, INP, CLS)
  • Images below the fold use lazy loading
  • CSS and JavaScript are minified for production
  • Browser caching is configured with appropriate expiry headers
  • CDN is configured if serving visitors across multiple regions
  • No render-blocking resources delaying initial page paint

Mobile Is Not a Separate Concern

Over 60% of web traffic in the UK comes from mobile devices. Google indexes the mobile version of your site, not the desktop version. Testing on mobile is not an extra step — it's the primary test. Desktop is the secondary check.

The most common mobile problems at launch are touch targets that are too small (buttons and links should be at least 44x44 pixels), text that requires pinching to read, horizontal scrolling caused by oversized images or tables, and navigation menus that don't collapse properly on smaller screens. These all feel fine on a large monitor during the build and fall apart on a phone in someone's hand.

Mobile Checklist

  • Site tested on actual mobile devices, not just browser dev tools
  • Touch targets are at least 44x44 pixels with adequate spacing
  • No horizontal scrolling on any page at any viewport width
  • Navigation collapses and functions correctly on small screens
  • Forms are usable on mobile — appropriate input types, readable labels
  • Text is readable without zooming

Security You Cannot Skip

HTTPS is the baseline. If your site doesn't have an SSL certificate in 2026, browsers will actively warn visitors away from it. But HTTPS is the starting line, not the finish. The security items most often missing at launch are the ones that require deliberate configuration rather than just checking a box.

Security headers tell browsers how to handle your content. A Content Security Policy (CSP) prevents malicious scripts from running on your pages. X-Frame-Options stops your site from being embedded in someone else's page (a common phishing technique). These are lines of server configuration that take minutes to add and significantly reduce your attack surface.

Form protection matters because every form on your website is an invitation for automated bots to submit spam — or worse. At minimum, implement rate limiting and some form of bot detection. If your site is built on WordPress, make sure the login URL isn't the default /wp-admin that every automated attack script targets.

And verify — properly verify — that no database credentials, API keys, or internal configuration files are accessible from the public web. This sounds obvious, but exposed .env files are one of the most common security findings on newly launched sites.

Security Checklist

  • SSL certificate is installed and HTTPS enforced — HTTP redirects automatically
  • Security headers configured: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options
  • Forms are protected against spam (honeypot, CAPTCHA, or similar)
  • Admin areas are protected and not accessible at default URLs
  • No credentials, API keys, or configuration files are publicly accessible
  • File upload restrictions are in place if the site accepts uploads

Forms That Actually Deliver

The number of DIY and template websites that launch with forms that silently fail is genuinely remarkable. The form looks fine. The visitor fills it in, clicks submit, sees a confirmation message, and assumes their enquiry has been sent. It hasn't. The emails are going to a test address, or being caught by a spam filter, or not being generated at all because the mail server isn't configured.

The only way to catch this is to test every form yourself, from a device that isn't logged into any admin panel. Submit the form. Check the receiving inbox. Check the spam folder. If there's an auto-responder, verify it actually sends and that the content is correct and professional. If the form feeds into a CRM or ticketing system, verify the data arrives there too.

It takes ten minutes to test properly. The cost of not testing is enquiries from potential customers disappearing into the void, with neither you nor they ever knowing.

Forms Checklist

  • Every form tested by submitting from a non-admin device
  • Confirmation emails arrive in the correct inbox (check spam folders)
  • Auto-responder content is accurate and professional
  • Form validation shows helpful, specific error messages
  • Required fields are clearly marked
  • Form data reaches any connected CRM or booking system

Analytics: What to Measure From Day One

You need to know three things from the moment your site goes live: where your visitors come from, what they do when they arrive, and whether they take the action you want them to take. Everything else is detail that can wait.

Which analytics platform you use matters less than having one in place. Google Analytics is the most common choice, but cookieless alternatives like Cloudflare Web Analytics and Plausible exist for businesses that want visitor insights without the complexity of cookie consent management. Whatever you choose, configure it before launch — not three weeks later when you realise you have no data on your busiest period.

Cookie consent is a legal requirement under PECR (the Privacy and Electronic Communications Regulations) if you use any cookies that aren't strictly necessary for the site to function. Analytics cookies fall into this category unless you're using a cookieless solution. The consent banner is not optional, and "by continuing to use this site you agree" is not valid consent. Users must actively opt in.

Analytics Checklist

  • Analytics tracking is installed and verified on all pages
  • Conversion tracking is configured for key actions (form submissions, calls, purchases)
  • Cookie consent banner is compliant with PECR — requires active opt-in
  • Analytics respects user cookie preferences and does not track without consent
  • Google Search Console is set up and verified
  • 404 error monitoring is in place to catch broken links quickly

Browser Testing Without Going Mad

You do not need to test every browser ever made. You need to test the browsers your visitors actually use. In the UK, that's Chrome (roughly 50% of traffic), Safari (about 30%, mostly mobile), Firefox (around 5-8%), and Edge (around 5%). Between those four, you've covered over 90% of your audience.

What to actually test: does the layout hold together? Do interactive elements (menus, accordions, forms) work? Does the site print sensibly if someone tries to print a page? Are there any JavaScript errors in the browser console? You're looking for broken functionality, not pixel-perfect consistency across every browser.

Browser Testing Checklist

  • Layout and styling verified in Chrome, Safari, Firefox, and Edge
  • Interactive elements (navigation, forms, accordions) work in all browsers
  • No JavaScript errors in the browser console
  • Print stylesheet renders sensibly if applicable

Accessibility Is Not Optional

Under the Equality Act 2010, UK businesses have a legal obligation to make reasonable adjustments so that disabled people are not put at a substantial disadvantage when accessing services — and that includes websites. This is not new legislation, but enforcement is increasing and case law is expanding.

Beyond the legal requirement, roughly 20% of the UK population has some form of disability. If your website is inaccessible, you are excluding a significant portion of your potential customers. The most impactful items to check at launch are colour contrast, keyboard navigation, and form labels — these three alone address the majority of common accessibility failures.

Colour contrast must meet WCAG AA standards: a ratio of at least 4.5:1 for normal text and 3:1 for large text. Keyboard navigation means every interactive element can be reached and operated without a mouse — tab through your entire site and see if you can complete every action. Form labels must be programmatically associated with their inputs, not just visually positioned nearby.

This checklist does not replace a full accessibility audit. But getting these fundamentals right at launch means you're starting from a defensible position rather than building on a foundation that needs to be corrected later.

Accessibility Checklist

  • Colour contrast meets WCAG AA standards (4.5:1 for normal text, 3:1 for large text)
  • Entire site is navigable by keyboard alone — tab through every page
  • Focus states are visible on all interactive elements (links, buttons, inputs)
  • All form inputs have properly associated labels
  • ARIA attributes are used where HTML semantics alone are insufficient
  • A skip-to-content link is available for keyboard users
  • No information is conveyed by colour alone (use text, icons, or patterns too)

Launch Day and the 48 Hours After

Do not launch on a Friday. If something goes wrong — and something usually does — you want working days available to fix it. Tuesday or Wednesday mornings are ideal: early enough in the week to resolve issues, late enough that Monday's meetings aren't competing for attention.

If you're migrating from an old site, redirect mapping is critical. Every page on the old site that received traffic or had external links pointing to it needs a 301 redirect to the equivalent page on the new site. Miss this, and you lose both the search equity those pages had accumulated and the visitors who find your old URLs through bookmarks, links from other websites, or cached search results.

Have a rollback plan. Keep the old site accessible (even if only at a staging URL) so you can switch back quickly if a critical issue emerges. DNS changes can take up to 48 hours to propagate fully, so some visitors will see the old site while others see the new one during that window. This is normal.

Monitor closely for the first 48 hours. Watch analytics for unusual patterns, check your email deliverability, test the site from different devices and locations, and keep an eye on Google Search Console for crawl errors. Most problems surface within this window.

Launch Day Checklist

  • DNS configured and propagating — allow up to 48 hours for full propagation
  • 301 redirects in place for all old URLs (if migrating from a previous site)
  • Backup of the site created before launch
  • Uptime monitoring and alerts configured
  • Rollback plan documented and tested
  • Stakeholders notified of launch with a point of contact for issues
  • XML sitemap submitted to Google Search Console post-launch

When a Checklist Isn't Enough

For a straightforward brochure website with a contact form, this checklist covers the essentials. But some launches need professional review beyond what any checklist can provide.

Site migrations — moving from an old domain or platform to a new one — involve redirect mapping, search equity preservation, and careful monitoring that goes well beyond checking boxes. Ecommerce launches add payment processing, tax calculations, inventory management, and PCI compliance to the equation. Sites in regulated industries — financial services, healthcare, legal — may have specific compliance requirements that generic checklists don't cover.

The honest answer is that a checklist helps you avoid the most common mistakes. It doesn't replace experience with launches that have gone wrong — and the judgment that comes from knowing what to look for because you've seen what happens when it's missed. If your launch is complex, getting a professional review before going live is an investment that typically pays for itself in problems avoided.

Launching Soon?

We can review your site before launch or handle the entire process. A pre-launch audit catches the problems this checklist can't.