Website audit template: check an AI-built site before launch

A successful build means the files were assembled. A successful publish means a host accepted them. Neither proves that a stranger can understand the page, use it on a phone, follow its links, find it in search, or avoid seeing a secret that slipped into browser code.

Audit the public address you intend to share, in a private window, before you call the site finished. This template is that last pre-publication review of a static commercial site. It is not a full SEO audit, an accessibility certificate or a security assessment.

If you are not sure the project is a static site at all, use the site-versus-application test first.

Use the template on the public URL

Put the final public address in the copied template, note the version or date, and work from the first category to the last. Do not audit the editor's preview: it can borrow local files, a signed-in session, cached assets or extensions a first-time visitor will not have.

The checklist is deliberately pass/fail. A weighted score would create false precision, because a broken contact link is not balanced out by five correct meta tags. Record failed checks as fixes, make the changes, and repeat the affected category on the address visitors will open.

Start by testing the promise

The first check is not technical. Read the first screen without using what you know about the business. It should answer three questions:

1. Who is this for?
2. What can they get here?
3. What should they do next?

This is a correctness test, not a debate about taste. "Book a first appointment" can be checked against the real booking path; "Innovative solutions for modern businesses" cannot be checked against anything. If the promise was never made specific, go back to turning the prompt into a real brief.

Then verify every fact that can cost trust or money: business name, service area, price, availability, email, phone, and claims about work or customers, each against a current source from the owner. An agent writes plausible details that are still wrong, and a valid page publishes them without objection.

Finally, search for residue from drafting: example addresses, placeholder testimonials, disabled buttons, # links that go nowhere, stock copy, and comments meant for the reviewer.

Test the visitor path, not the build result

Open the public URL in a private window and hard-refresh. Start at the logo, move through the header and page, finish in the footer, checking it carries the same few items on every page. Open every internal route. Activate buttons rather than judging their labels. Test email and phone links on a device that can handle them.

Keep the console and network panel open for one pass. A missing image leaves an obvious hole, but a failed analytics request, font or background asset is quieter. Record unexplained errors, then fix or consciously accept each one.

Forms, booking calendars and checkouts are conditional. If the page submits to a separately managed service, complete one safe end-to-end test, verify the result arrived, and delete the test record. A form-shaped box is not proof that a person receives anything.

Repeat the important path on the exact branded domain you plan to share, because the project address and a custom domain can point at the same files while DNS or cached metadata makes them behave differently. If the domain is the failing part, use the guide to apex, www and domain verification rather than changing page code at random.

Check accessibility without pretending it is certification

A useful first review needs no specialist equipment. Navigate the whole page with Tab, Shift+Tab, Enter, Space and arrow keys. You should always see which control has focus, reach items in a logical order, and operate every menu, disclosure, link, button and field.

Zoom to 200%. Check a narrow phone viewport. Read the heading outline. Inspect meaningful images for useful alternatives and fields for labels. These come from W3C's Easy Checks accessibility review, which also covers page language, contrast, captions and skip links.

The wording matters, because "we tested keyboard navigation" is a reproducible fact. "The site is accessible" is a much larger claim needing defined criteria and often people who use assistive technology.

Check what search engines and shared links can read

Inspect the response from the public page, not a title field in the tool that made it. Each important page needs a distinct document title that describes it. Google calls the title link one of the main things people use to choose a result and recommends titles that are clear, concise and unique, while noting it may generate a different one; the details are in its title-link guidance. If you are not sure which element you are editing, four different things get called the website title and only one fills the browser tab.

Check the meta description as an accurate preview. Google usually builds a snippet from the page itself and may use the description when it is a better summary, according to its SEO Starter Guide, so the first paragraphs still have to answer the page's question.

Also verify:

• the HTML declares the page's actual language;
• an accidental noindex is not blocking a page meant for search;
• duplicate public addresses identify one preferred canonical address;
• a shared link produces the intended title, description and image.

This is the launch floor, not a technical SEO audit. It says nothing about backlinks, content strategy, rankings, or whether the page deserves to rank.

Measure performance as evidence, not a single score

Run a mobile Lighthouse or PageSpeed check and record its conditions. Use the waterfall to find the largest images, fonts, scripts and third-party embeds. Watch for a late-loading hero that moves the page, a slow button, or a large asset downloaded for a tiny slot.

One lab run is diagnostic evidence, not a verdict about every visitor. Google's Core Web Vitals tooling guide explains that Lighthouse simulates a particular device and network while field data describes what real visitors experienced, and a new site may not have enough field data yet.

Run it again after the fix under the same conditions. "The main image fell from 2.4 MB to 280 KB" is a useful result. "The score changed from 83 to 91" is hard to interpret when the run conditions changed too.

Assume every browser file is public

A static site cannot keep a value secret in HTML, JavaScript, a source map, a comment, browser storage or a network response. Search the files that actually went online for API keys, access tokens, credentials, personal records, internal addresses and proprietary notes.

OWASP's guide to reviewing web pages for information leakage calls out sensitive information hardcoded in front-end JavaScript. The safe assumption: if the browser receives it, the visitor can inspect it.

Birta excludes recognized secret files such as .env settings, private keys, certificates and known credential files from a package. That is a guard, not content scanning: a token pasted into an otherwise allowed script looks like ordinary text to a validator, so the audit checks the served output.

Know what Birta checked automatically

Birta's publishing checks and this audit answer different questions:

The distinction is intentional. Automatic validation enforces objective file rules quickly. It cannot decide whether a physiotherapist's phone number is current, whether keyboard focus is visible, or whether the main button makes the right promise.

Keep a rollback point before the next change

Record the tested URL, version, date and known-good restore point in the template. In Birta a draft has a separate preview while the public address keeps showing the active version, published versions can be previewed, and a previous one restored if the next change is wrong.

Do not wait for a failure to learn the restore path. List the versions, identify the tested one, and know which action makes it active. Then fix and re-run the failed category. The full loop is in updating a live website.

When the client runs part of this audit, have them leave each failed check on the page itself rather than in an email. On a Birta version they can do that with no account; for a site hosted anywhere else, the website feedback tools comparison shows which tool pins a remark to the element and what happens to it next.

Version history protects the release, not the business facts inside it. Restoring a technically working page with an old price is still the wrong outcome, which is why the record should say what was tested rather than only which version passed.

Work one fix log, not a list of fixes

A completed checklist gives you failed checks. What turns them into a finished page is a record of three things per fix: what the check caught, what you asked the agent for, and which version carries the result.

Here is one worked pass on a demonstration site, a one-page landing for a physiotherapy clinic generated from a two-sentence prompt and audited on its public address. Four failed checks, four fixes, four versions. It demonstrates the loop and the wording, and makes no claim about what the changes did to enquiries.

1. The first screen named nobody. The hero read "Professional care for a better you" over a stock photo: no audience, no offer, no next step. The re-prompt was specific about the replacement rather than the quality: "Rewrite the hero heading and subheading to say who the clinic treats, what it treats, and where it is. Use sports physiotherapy, adults recovering from running and gym injuries, and the city name. No adjectives about the practice."

2. Two calls to action competed on the same screen. "Book an appointment" in the header, "Get in touch" in the hero, pointing at different destinations. The fix removed the second rather than rewording it.

3. The form asked for more than the first visit needed. Seven fields, including a company name. Every field is a reason to leave, so it went to name, email, phone and a free-text field for the injury, then the conditional form check ran again.

4. The page order followed the agent's habit, not the visitor's question. Pricing sat three screens down, under testimonials and an about section. Nothing was broken, which is why a checklist has to be read as a whole rather than category by category.

Three habits make the log worth keeping. Record the before and after wording verbatim, because "improved the headline" is not checkable later. Save one version per fix rather than one for the batch, so a rollback undoes the change that was wrong instead of all four. And re-run only the affected category, which keeps the loop short enough to finish.

The before state stays openable for as long as the versions do, which is why this reads as a comparison rather than a story: v1 is still there, so "the hero named nobody" can be verified against the page that made it.

Know where this template stops

Completing every checkbox means you performed this first review. It does not mean the site is legally compliant, secure against attack, accessible to every person, optimized for search or commercially effective.

Escalate when the consequence exceeds the checklist:

• a qualified accessibility evaluation when conformance or legal duties matter;
• a security review for applications, sensitive data, authentication or valuable transactions;
• broader SEO research when organic discovery is a real acquisition channel;
• real customer evidence when deciding whether the offer converts.

That boundary makes the template more useful, not less. It gives a small static site a review that can actually be repeated.