Website Technical Audit Checklist: What to Check Before Launch or Handover

The most expensive website defects are often invisible during a normal homepage review. An orphaned landing page, a private portal in a sitemap, a broken redirect, a missing backup or a security rule that challenges legitimate visitors can sit unnoticed until customers or search engines encounter it.

1. Confirm what the public internet can access

Start from an anonymous session, not an administrator's logged-in browser. Request the homepage, top product pages, main landing pages and the sitemap. Check actual status codes and response headers. A visible page can still be marked `noindex`; a sitemap can return success while many contained URLs are redirects or duplicates.

• Check every important indexable page for `200`, a real H1, useful HTML and the right canonical.
• Check the sitemap contains only preferred, public URLs.
• Check robots.txt is not unintentionally blocking content or essential files.
• Check login pages and private portals are access-controlled and not advertised as public content.

2. Test redirects and invalid URLs deliberately

Write down one canonical version of the website and each major product route. Test `http` to `https`, trailing slash rules, retired paths, renamed products, and direct `index.html` links. Aim for one redirect step to the intended destination when practical. Do not rewrite unrelated old URLs to the homepage merely to avoid a `404`.

Visit a deliberately invalid URL. It should return an actual `404` and a page that helps visitors recover. Search engines use these status codes to distinguish unavailable content from legitimate resources.

3. Measure real navigation, not only scores

Test on a modest mobile device or a throttled connection. Can a first-time visitor identify what the product does? Are key links accessible without animation? Do images reserve their layout space? Can someone use forms and filters with a keyboard?

Core Web Vitals are useful signals, but a missing interactive data table or a search button that does nothing can harm users more than a marginal lab score. Observe the full journey from entry page to the intended action.

4. Separate search visibility from access control

Do not rely on `robots.txt` or `noindex` to secure records, dashboards or API endpoints. Verify authentication on the server, session expiry, role-based permissions and appropriate rate limits. Check that public-facing security rules do not accidentally challenge verified search crawlers. Review error logging without exposing private data.

For WordPress deployments, check core, themes, plugins, least-privilege accounts and tested backups. The official WordPress hardening handbook is a better baseline than a random "security tricks" post.

5. Prove you can restore the site

A backup is not enough if nobody knows what it contains or how to restore it. A meaningful recovery test answers: where are files stored, where is the database, how are secrets managed, who has access, how often are backups taken, and what does a restore actually recover?

6. Rank by user impact

When the audit is finished, use an issue tracker with screenshots or command output, an owner and a date for verification. Our Site Audit & Technical Handover and Site Health Toolkit pages describe tools developed for this type of workflow.

Bottom line: a website is ready when important journeys work, private resources are protected and someone can maintain and restore it. Visual polish is the last layer, not the first.