How often should I audit my website?

The checks that catch a deployment accident, and only those. A full audit on every deploy is noise nobody reads by the third week.

Indexing directives: no `noindex` promoted from staging, no `Disallow: /` in robots.txt, canonical tags still pointing at themselves.

Status codes: the home page and one page per template return 200, and an invalid path returns 404 rather than 200.

HTTPS still works on every hostname, and no mixed content was introduced.

Four checks, automatable, and they cover the failures that are cheap now and expensive in a fortnight.

Run them against the real production hostname after the deploy completes, not against a preview URL, which has different hostnames and frequently different headers.

Broken internal links, which accumulate from ordinary editing rather than from anything dramatic.

New redirect chains, which appear when a rule is added without folding in the existing ones.

Page weight and Core Web Vitals field data, which drift as scripts and images are added by people who are not watching the total.

Newly added third-party scripts, which are the most common uncontrolled change on any site.

Sitemap health: that it still parses, still lists canonical URLs, and has not started advertising pages that redirect or 404.

New content that shipped without a title or a meta description, which editing workflows produce steadily and no deploy check catches.

The complete audit: accessibility, security headers, structured data, metadata quality, mail authentication, DNS.

This is where slow drift shows up — the things no single deploy caused and no monitoring alerts on.

It is also the right cadence for re-reading what you deliberately deferred last time, which is the part most often skipped.

Quarterly is a default rather than a rule. A site under heavy development earns monthly; a brochure site that changes annually does not need four a year.

Mail authentication belongs here specifically because nothing on the website reveals when it breaks — a DNS change made for an unrelated reason can invalidate SPF without any visible symptom.

Certificate expiry. Renewal is automated on most sites, and automated renewal that breaks fails silently until the day it expires.

Domain expiry. A lapsed registration takes the site, the mail and every subdomain at once, and recovery is neither guaranteed nor cheap.

Whether the site is still indexable, because this is the failure with the longest delay between cause and symptom.

These three want monitoring rather than auditing: a check that runs continuously and tells you when the answer changes.

Treat them as alerts with an owner rather than as findings in a report. A finding in a quarterly audit about a certificate expiring next week has arrived too late to be useful.

Before a launch or a redesign, and again after it goes live.

After a migration, where the redirect map needs verifying against the real list of old URLs.

After a traffic drop, where the audit is a diagnostic rather than a routine.

When taking over a site you did not build, where you are establishing a baseline rather than detecting a change.

After a platform or plugin change, which alters generated markup in ways nobody reviews.

Compare against your own previous run rather than against an absolute target. The delta is the useful signal, and it holds the weighting constant.

Keep the scope identical between runs. Changing the crawl limit between audits makes the comparison meaningless.

VeriFixScan reports coverage alongside its results — the share of applicable checks it could verify — which is what tells you whether two runs are comparable at all.

Record what you deliberately deferred. Without that, every audit re-surfaces the same accepted findings and the report loses credibility.