12 checks to run after an AI website is built.

Give every important page a useful title and description

Open the source or SEO settings. Each important page needs a title that names the page and a description that matches its real content. Repeated titles such as “Home” weaken the search result before anyone clicks it.

Google uses the title element, the main visible heading, prominent page text, and other signals when it creates a title link. Keep those signals consistent. Read Google's title-link guidance.

Use links that crawlers can follow

Click through the site without search, hidden menus, or scripted buttons. Every important service, location, and contact page should be reachable through a normal link.

Google can generally crawl an anchor element when it has an href attribute. A styled container or isolated page can look fine to a visitor while remaining hard to discover. Read Google's crawlable-link guidance.

Check canonical URLs, indexing rules, and the sitemap

Confirm that each canonical points to the final HTTPS URL. Remove accidental noindex rules. Open the sitemap and check that it lists only the URLs you want indexed, using the correct domain and protocol.

Google recommends absolute sitemap URLs and says entries should use the preferred canonical versions. Read Google's sitemap documentation.

Keep the main business information readable without an interaction

The business name, service, location, phone number, and primary offer should exist in the rendered page content. Do not hide the only useful copy behind a slider, hover effect, or button that loads it later.

Google renders JavaScript, but rendering adds another stage before indexing. Read Google's JavaScript SEO basics.

Remove secrets from browser code and shared files

Search the delivered folder for API keys, administrator passwords, private tokens, database strings, and test credentials. Anything sent to the browser or included in a public download should be treated as visible.

Move secrets to server-side environment settings. Rotate a key if it was exposed during development. See OWASP's secrets-management guidance.

Test the live forms from end to end

Submit every form from the live domain. Try a valid entry, an empty field, an invalid email, a long message, and a second submission. Confirm that the business receives the message and the visitor sees a clear success or error state.

Add server-side validation and reasonable abuse controls. Browser validation helps the visitor, but it does not protect the server by itself. See OWASP's input-validation guidance.

Review dependencies and assign updates

List the framework, packages, plugins, form service, analytics tool, and hosting runtime. Record who checks updates and how often. Remove packages the site does not use.

Prove that recovery works

A backup file is half a recovery plan. Record where backups live, how often they run, who can access them, and the last date a restore was tested. Keep the recovery instructions outside the account they are meant to recover.

Test the main action on a real phone

Call the phone number. Tap the email link. Submit the form. Open the booking link. Test the payment path if the site has one. Do this on a real phone over a normal connection.

Put essential accounts under client control

Record the owner of the domain, DNS, hosting, analytics, email service, form service, source files, and repository. Give collaborators the access they need without sharing one master password.

Check accessibility, browsers, and common screen sizes

Use a keyboard to reach the navigation, fields, and primary action. Check focus states, contrast, labels, image alternatives, zoom, overflow, and error messages. Then test common mobile, tablet, and desktop widths in more than one browser.

Write down support limits

State the response time, included update hours, backup responsibility, renewal owner, form-check schedule, and what counts as a new project. The agreement and handoff note should use the same limits.