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 result 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 browser window, before you call the site finished. The website audit template below is for 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 whether the project is a static site at all, use the site-versus-application test first. Authentication, private data, a database, or project-owned server code needs a different production review.

Use the template on the public URL

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

The checklist is deliberately pass/fail. A weighted score would create false precision: 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 same address visitors will open.

Start by testing the promise

The first check is not technical. Read the first screen without using what you already 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, return to the work of turning the prompt into a real brief before polishing the output.

Then verify every fact that can cost trust or money: the business name, service area, price, availability, email address, phone number, and claims about work or customers. Check them against a current source supplied by the owner. An agent can write plausible details that are still wrong, and a technically valid page will publish them without objection.

Finally, search for residue from the drafting process: example addresses, placeholder testimonials, disabled buttons, # links that go nowhere, generic stock copy, and comments meant for the person reviewing the draft. “Looks done” is not evidence that the draft stopped leaking into the result.

Test the visitor path, not the build result

Open the public URL in a private window and hard-refresh it. Start at the logo, move through the header and page, and finish in the footer, checking that 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 browser's console and network panel open for one pass. A missing image may leave an obvious hole, but a failed analytics request, font, script, or background asset can be much quieter. Record unexplained errors and failed requests, then decide whether to fix or consciously accept each one.

Forms, booking calendars, and checkouts are conditional. If the static page links or submits to a separately managed service, complete one safe end-to-end test and verify that the result reached the intended destination. Remove the test record afterward. The presence of a form-shaped box is not proof that a person will receive anything.

Repeat the important path on the exact branded domain you plan to share. The standard project address and a custom domain can point at the same files while DNS or cached metadata still makes them behave differently. If the domain is the failing part, use the dedicated 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 is possible without specialist equipment. Navigate the whole page with Tab, Shift+Tab, Enter, Space, and arrow keys where the control expects them. 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 checks come directly 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 requiring broader testing, 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 accurately describes it. Google calls the title link one of the main pieces people use to choose a search result and recommends titles that are clear, concise, and unique; it may still generate a different title from the visible page and other signals. The details are in Google's title-link guidance. If the check fails and you are not sure which element you are supposed to be editing, four different things get called the website title and only one of them fills the browser tab.

Check the meta description as an accurate preview, not a bag of variants. 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. That means the first paragraphs still have to answer the page's question even when a description exists.

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 complete technical SEO audit. It says nothing about backlinks, ongoing content strategy, rankings, or whether the page deserves to rank. Birta's own blog and documentation automate their metadata; a customer site still needs its own title, description, and indexing decisions.

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 button that responds slowly, or a large asset downloaded for a tiny display 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 actually experienced. A new or lightly visited site may not have enough field data yet, so keep the lab run reproducible and use it to fix causes rather than chase a badge.

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 much harder to interpret when the run conditions also changed.

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 delivered to the visitor. 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 specifically calls out sensitive information hardcoded in front-end JavaScript and other page source. The safe assumption is simple: 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 useful guard, not content scanning. A token pasted into an otherwise allowed script can still look like ordinary text to a package validator. The audit must check the served output.

Know what Birta checked automatically

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

The distinction is intentional. Automatic validation can enforce objective file rules quickly and consistently. 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 copied template. In Birta, a draft can have 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 make the fix and run the failed audit category again. The full edit-and-restore loop is covered in updating a live website without rebuilding the workflow.

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 audit record should say what was tested, not only which version number passed.

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:

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

That boundary makes the template more useful, not less. It gives a small static site a review that can actually be repeated without pretending that thirty minutes of checking replaces every specialist.