The short answer

Generated sites are usually finished where you can see and unfinished where you can’t. The four checks that matter most: submit your own contact form and confirm the enquiry genuinely arrives, open the site on a real phone, run PageSpeed Insights on it, and confirm no API keys are sitting in your page source. If those four pass, you’re in better shape than most. The other eight are below.

None of this requires writing code. Set aside an afternoon.


The blocking four

Fix these before the site takes any real traffic.

1. Your contact form actually delivers

Why it matters: this is the single most common failure, and the most expensive, because it fails silently. The form shows a success message, the visitor believes they’ve contacted you, and nothing arrives. You don’t discover it from an error — you discover it from a quiet month.

It happens because a generated form’s success message is often wired to appear when the button is clicked, rather than when the server confirms it actually sent something.

How to test it:

  1. Submit the form with a real email address you can check.
  2. Check the destination inbox — including spam and any promotions tab.
  3. Do it again from your phone on mobile data, not home wifi.
  4. Submit it with a deliberately invalid email and confirm you get a sensible error rather than a false success.

If it fails: stop and fix this before anything else on the list. Nothing else matters if enquiries aren’t arriving.

2. No secrets in your page source

Why it matters: API keys, database credentials or email-service passwords left in client-side code are visible to anyone who views the page source. Not hypothetically — the page is served to every visitor, and there are automated scanners that do nothing but look for this.

How to test it: open your site, press Ctrl+U (Cmd+Option+U on a Mac) to view source, then search the page for key, secret, token, password and api. You’re looking for anything that resembles a long random string.

If it fails: treat any exposed key as compromised. Rotate it at the provider, then get the code changed so it never reaches the browser. This is worth paying someone for the same week.

3. Spam protection on every form

Why it matters: an unprotected form gets found by bots, usually within days of going live. At best your inbox becomes unusable and real enquiries get buried. At worst your email-sending service suspends you for the volume, which takes the form down entirely.

How to test it: look for a honeypot field, a rate limit, or a challenge like Turnstile or reCAPTCHA. If you don’t know, ask whoever built it — or watch what arrives over the first fortnight.

If it fails: this is a small, cheap fix and there’s no reason to leave it.

4. It works on a real phone

Why it matters: most people will see your site on a phone, and a browser’s mobile preview lies. It doesn’t reproduce real touch targets, real network speed, or the way an on-screen keyboard covers half the viewport when someone taps into a form field.

How to test it: on your actual phone, on mobile data with wifi off — load the site, scroll every page, tap every button, and fill in the contact form completely. Look for text you have to pinch to read, buttons too close together to hit accurately, anything scrolling sideways, and form fields that vanish behind the keyboard.


The eight that cost you slowly

Not emergencies. All worth handling before you spend money driving traffic.

5. Google can actually index it

Search site:yourdomain.com.au in Google. If nothing comes back after the site’s been live a couple of weeks, Google isn’t indexing it.

Check that you have a robots.txt that isn’t blocking everything (yourdomain.com.au/robots.txt), an XML sitemap (/sitemap.xml or /sitemap-index.xml), and that every page has its own unique <title> and meta description rather than the same one repeated. Then set up Google Search Console — free, and it will tell you directly what Google can and can’t see.

6. It loads fast enough

Run your homepage through PageSpeed Insights and read the mobile score, not desktop. Under 50 is a real problem; 50–89 has room to improve; 90+ is good.

Generated sites commonly ship far more JavaScript than their content warrants, and images at full camera resolution scaled down in the browser. Both are fixable, and images are usually the quickest win. Speed has been a Google ranking signal since 2021, so this is a traffic issue as well as a user-experience one.

7. You find out when something breaks

Right now, if your site throws an error for a visitor, you almost certainly never learn about it. They just leave.

Error monitoring — Sentry has a free tier that’s plenty for a small site — emails you when something fails. Also check your uptime: if the site goes down at 2am on a Saturday, is anyone told?

8. You can see what people do

Analytics you actually look at. Google Analytics 4, or a lighter privacy-focused option like Plausible or Fathom. The specific questions worth being able to answer: how many people visit, which pages they land on, how many submit the form, and where they come from.

Without this you’re guessing about your own business.

9. It’s backed up, and you’ve tested restoring it

Ask two questions: if the site vanished tonight, where’s the copy? And has anyone actually restored from that copy to confirm it works?

An untested backup isn’t a backup. If the code lives in a Git repository, that’s most of the job — but confirm you can access it independently of whoever set it up.

10. Someone can read it who can’t see it

Roughly one in five people has a disability affecting how they use the web, and in Australia accessibility carries legal weight under the Disability Discrimination Act.

Quick self-check: can you navigate the whole site with only the Tab key, and always see where you are? Do images have alt text? Is text a strong enough contrast against its background? Run any page through the free WAVE tool for a fast read.

An Australian business site collecting any personal information — a contact form counts — needs a privacy policy explaining what you collect and why. If you use analytics or advertising cookies, that needs disclosing too. Check your business name and ABN appear somewhere findable.

Not glamorous, cheap to fix, awkward if someone asks and you don’t have it.

12. You know who’s holding what

Write down, somewhere you’ll find it again: who the domain is registered to and when it renews, where the site is hosted and who pays for it, where the code lives, and who has admin access to all three.

The failure this prevents is specific and depressingly common: a business that can’t move or update its own site because the only person with access has moved on.


What to do with the results

All twelve pass? Genuinely well done — you’re ahead of most.

One to four failing? These are the ones costing you money right now, most likely in enquiries you never knew existed. Worth paying someone for even if you fix nothing else.

Several of five to twelve failing? Normal for a generated site, and a reasonable prompt to think about whether patching each one individually is the right move, or whether rebuilding it properly costs less in total. Twelve small fixes to a codebase nobody can explain often adds up to more than one clean build.

If you’d rather not run the list yourself, send the URL and you’ll get an honest read on which of these your site passes — including if the answer is that it’s fine as it is.