Website audit checklist: where to start

Four situations to check before anything else

Four situations hit every visitor on the first page, whatever the rest of the site looks like. Get them checked before anything else:

• The site does not work over HTTPS.
• The certificate is expired, self-signed, or issued for a name other than yours.
• The domain name has expired, or expires in less than 15 days.
• The site is on a list of dangerous sites that browsers check.

The first three are fixed at your host or at your domain registrar. The fourth means finding out why the site is on the list before asking for it to be removed. An audit report covers them in one sentence when none applies: that is the case in both published sample reports, which give the domain's expiry at the same time.

Next come the items that weigh most in the scoring behind our method: trackers that fire before consent and personal data sent outside the EU without safeguards, then no consent mechanism, no legal notice, critical layers concentrated with a single provider, and SPF or DMARC missing while the domain receives email. In each pillar below, the list starts with what weighs most.

A check that doesn't apply doesn't count: online sales rules don't apply to a site that sells nothing. And the pillars themselves carry different weights depending on what the site is for: the methodology page publishes the weightings.

Security and encryption: the connection, and what the site gives away

The question: are the connections with your visitors properly protected, and does the site publish nothing that should stay private? The chapter on website security gives the basis for each check.

• The site works over HTTPS, and the http address redirects to it permanently. Without HTTPS, the browser flags the site as not secure on every visit.
• The certificate is valid, not about to expire, and issued for your domain name. A certificate issued for your host's name triggers a warning that stops visitors before they read a line.
• The JavaScript served contains no secret key. Any script a page loads can be read by any visitor, and a secret key that has been published should be treated as known.
• The server refuses TLS 1.0, TLS 1.1 and weak cipher suites. Accepting them lets a connection settle on the weakest level the server tolerates.
• No resource loads over http on an https page. The browser blocks or flags that mixed content, and anything sent unencrypted can be read or altered on the way.
• JavaScript libraries and the CMS are not on a version with a known vulnerability. Those vulnerabilities are listed in public databases that anyone can read.
• No subdomain points to an abandoned third-party service. Whoever claims that service can publish under your domain name.
• On an online store, the checkout pages load no third-party script unrelated to payment. Each of those scripts runs on the pages where customers enter their details.
• The HSTS and CSP headers are sent. The first keeps the browser on HTTPS; the second limits which scripts a page can run.
• Session cookies carry the Secure, HttpOnly and SameSite attributes. Without them, a cookie can travel unencrypted, be read by a script, or ride along with a request from another site.
• Source maps aren't published. They hand anyone the code as it was written, comments included.

The certificate, TLS versions and headers are set at your host. A vulnerable library or CMS gets updated. A published secret key gets replaced: deleting it from the code isn't enough.

Three guides go deeper: HTTP security headers, what HSTS commits you to and secure cookie attributes.

Performance: Google's three thresholds, and what explains them

The question: is the site fast enough for its visitors? The first three items are Google's Core Web Vitals, and the chapter on web performance explains how they are measured.

• The page responds to a tap or click in under 500 milliseconds (INP). Beyond that, a button you just pressed seems to do nothing.
• The main content appears in under 4 seconds (LCP). Beyond that, Google rates the page "poor" on this metric, and the visitor waits in front of an unfinished page.
• Cumulative layout shift stays under 0.25 (CLS). Content that moves while the page loads makes people tap the wrong button.
• Those thresholds hold on a phone, not just on a desktop. A page that is fast on an office computer can still be slow on a phone over a mobile network.
• Bytes downloaded, number of requests, images served larger than the screen, anything that isn't compressed or cached. That is where the cause of a slow page shows up.
• The share of weight and waiting time that comes from third-party services. An analytics or ad script can slow down a page you haven't touched.

Oversized images and files that aren't compressed or cached can be fixed without a redesign. A third-party script that weighs on every page is a conversation with whoever asked for it.

The guides on Largest Contentful Paint and on why a website is slow go further.

SEO: what search engines actually read

The question: can search engines understand your pages? The chapter on technical SEO auditing explains why a page is judged in two versions, as the server sends it and as the browser renders it.

• No text present in the page as sent disappears from the page as rendered. Search engines would then read something visitors never see: that is the mechanism Google's spam policies target under the name cloaking. The gap can be accidental; it is a fact about the text, not about intent.
• A robots.txt file and a sitemap exist, and robots.txt has no line that a compliant crawler ignores. A badly written rule protects nothing, and nothing tells you so.
• The canonical URL and the noindex directive are the same in the page as sent and the page as rendered, and they sit in the page's head. A tag that only the browser adds, or one placed outside the head, may be ignored.
• Fewer than 5% of the internal links followed lead to an error. A broken link stops the visitor and wastes the crawler's time.
• No staging site is public and indexable. A copy of the site in search results competes with the original.
• A multilingual site declares its language versions to each other, both ways (hreflang). Without that, search engines may show the wrong language.
• No URL goes through two or more redirects, a loop, or a JavaScript redirect. Each hop slows the visitor down and blurs which address the search engine should keep.
• Every page has a title and a description of useful length, distinct from one page to the next; structured data carries the fields its type requires.

Robots.txt, the sitemap and redirects can be fixed without touching the pages. Tags that only the browser adds mean revisiting how the site is built: that is a project for whoever maintains the code.

To go further: what robots.txt really blocks, redirect chains and a staging site indexed by Google.

Accessibility: contrast, labels, keyboard

The question: can people with different needs use your pages? The chapter on accessibility auditing cites the WCAG criteria behind these checks.

• No critical barrier repeats across nearly every page. A barrier present everywhere weighs far more than an isolated defect: it shuts people out of the whole site.
• Text meets the required contrast, measured on the rendered page, consent banner included. Low contrast makes text unreadable for some visitors.
• Images that carry information have a text alternative; decorative ones stay silent. A screen reader reads the first kind and should skip the second.
• Every link and button has a name that says where it leads. A run of identical "Read more" links tells a screen reader user nothing.
• Form fields have labels, and headings follow a hierarchy. A field whose only cue is placeholder text loses its name as soon as you type in it.
• Everything works from the keyboard, and the focus indicator is visible. A menu that only opens on hover locks out anyone navigating without a mouse.

A barrier that repeats on nearly every page usually comes from a shared element, such as the menu, header or footer: fixed there, it goes away everywhere.

The guides on WCAG levels A and AA, on RGAA, the French standard and on the European Accessibility Act explain who has to meet what.

Compliance and privacy: consent, legal notice, online sales

The question: is what the site shows to meet its obligations present and working? The chapter on GDPR compliance for a website limits this scope to what can be seen from outside. These are EU and French rules: they apply to businesses established in the EU, the EEA, the UK or Switzerland.

• No third-party tracker loads before the visitor has answered the consent banner. This is the heaviest item in the pillar, and a banner on screen isn't enough if the trackers fire before the answer.
• As soon as non-essential cookies are set, a consent mechanism exists, and refusing is as easy as accepting.
• The legal notice is published, complete, and linked from the site's pages, and the company it names is still active. A notice no page links to, or one naming a company that has ceased trading, informs no one.
• On a site that sells to consumers: the right of withdrawal, the legal guarantee of conformity and the consumer mediator are stated, and no link points to the EU's online dispute resolution platform, closed since July 20, 2025.
• Where the law requires it, an accessibility statement is published.
• No session recording or browser fingerprinting starts before the visitor agrees. The first replays someone's visit, the second identifies them without a cookie.
• Customer reviews on display say whether, and how, their authenticity is checked.
• A privacy policy exists and states the processing, its purposes and people's rights.

Blocking trackers until consent and publishing a complete legal notice, linked from the site, leave the rest of the site untouched. To know which obligations your business is bound by, the text of the law is the reference, and a lawyer settles the doubtful cases.

Four guides cover these obligations: what an EU legal notice must contain, EU ecommerce legal requirements, accessibility statements and session recording under the GDPR.

Domain and network: expiry, email, DNS

The question: are your domain and email properly protected? These settings live at your registrar, not in the site, and the chapter on domain and email security explains why they so often go unchecked.

• The domain name doesn't expire within 90 days. An expired domain takes the website and the email down at the same time.
• As soon as the domain receives email, it publishes complete SPF and DMARC records. Without them, someone else can email your customers in your name; an incomplete record is hardly better, and harder to notice.
• The DNS zone is signed with DNSSEC. Without a signature, nothing guarantees that the answer a visitor gets is the one you published.
• The domain is locked against transfer. It then cannot move to another registrar until someone lifts the lock.
• There are several name servers, and they are diverse; a CAA record, if published, limits which certificate authorities can issue a certificate for your domain.

These settings are made in your registrar account and wherever your DNS zone is managed. While you're there, check that the domain is in your name, on an account you control, and that renewal reminders go to an inbox someone reads.

The guides on domain expiration, on DMARC and DKIM and on DNSSEC cover each setting.

Independence and resilience: providers, jurisdiction, data

The question: who does the site depend on, and what happens if one of its providers goes down? The chapter on a site's hosting and dependencies keeps the two halves of the subject apart, jurisdiction and resilience. Like compliance, the EU transfer check applies to publishers in Europe.

• No personal data leaves the EU during a visit without safeguards. A font, an analytics tag or a map served from outside the EU receives at least the visitor's IP address.
• Hosting, DNS, content delivery and email don't all rest on a single provider. If the one carrying all the traffic goes down, the site goes down with it.
• The provider behind each layer is named, with its country and the law it answers to. A server in Europe run by a company subject to US law remains within reach of US orders.
• Leaving stays possible: a site built on open formats can move its content, a site on a closed platform has to be rebuilt.

Replacing a font, map or analytics tag served from outside the EU takes no redesign. Changing hosts, or spreading the layers across several providers, is a project best decided once you know what the site depends on.

The guides on data transfers outside the EU, on single-provider dependency and on the CLOUD Act go further.

Content and trust: what makes a reader doubt

The question: is the content clear, credible and well structured? Some of these items are judged rather than measured, and the chapter on content auditing explains how each judgment rests on a page and a quote.

• No placeholder text is left online: lorem ipsum, values stuck at zero, headings with no text under them, a forgotten "coming soon". Visitors read it as an unfinished site.
• Each language version is translated, not copied from the main version. A page offered in one language and written in another loses the reader who chose it.
• The main content was updated within the last 24 months. A page that is visibly out of date makes people wonder whether the business is still running.
• Facts don't contradict each other from one page to the next, and spelling is kept in check. A figure that changes from page to page casts doubt on both.
• The business identity, contact details and "about" page can be reached from the navigation. They are the first signals a careful visitor looks for.
• Important information is stated clearly and structured, so an automated system can extract it and attribute it to the site.

These fixes are yours, or your copywriter's: reread the flagged pages, remove placeholder text, update what has aged.

The guides on lorem ipsum left on a live site, on untranslated content and on Google's E-E-A-T criteria cover these points.

User experience and reliability: what breaks without warning

The question: do the pages and journeys that matter actually work? This pillar has no dedicated standard, and the chapter on website bugs and reliability sets out the facts it rests on.

• No JavaScript error occurs while the page loads. An error can stop a menu, a form or a cart without showing anything.
• No resource the page requests comes back with an error. A missing image, script or stylesheet leaves a gap or breaks the layout.
• A URL that doesn't exist returns a 404, with a page that leads back into the site. An unknown URL that returns 200 gets empty pages indexed.
• The site stays usable at every screen width. At one specific width, a button can slide off screen with no scrollbar to give it away.
• Buttons, menus and tabs do what they say. A screenshot shows a button, not what it does.
• The journeys your business runs on, contact, quote or purchase, can be reached and read all the way to the form.

Walk through your contact, quote or purchase journeys yourself, all the way to the end, on a phone as well as a computer: it is the path your customers take. A JavaScript error or a missing file gets fixed on the page where it happens.

The guides on JavaScript console errors, on images and files that fail to load and on 404 and soft 404 errors explain what each of these defects breaks.

Who checks what, and what to ask for

Some of this list can be checked by reading the site: the legal notice, the contact details, placeholder text, the journeys. The rest has to be measured, in the server's responses and in what the browser loads and sends during a visit. Hand that part to someone who didn't build the site, and ask for the results in writing. On a new site, do it before you sign off. The guide to website acceptance testing covers who checks what.

Ask for each defect to come with the affected page and the value recorded, the source when the check rests on a law, a standard or a specification, and the list of what could not be verified. A point that wasn't verified should never show up as compliant.

The list also helps you read an audit someone offers you: every missing pillar is a question left unanswered. An SEO-only audit covers one section, and our guide on SEO audits vs website audits compares the two.

The most frequent failures, and the rarest

These percentages cover about 30 websites we audited between August 14, 2026 and September 24, 2026. Each one counts only the sites where the point could be checked. Many were audited because a defect showed up quickly, so these figures describe our audits, not websites in general.

The three most frequent belong to independence and compliance, two pillars the top-ranking checklists barely cover.

The last two figures say the opposite. HTTPS and the certificate appear on nearly every website audit checklist, and they open this one because a failure stops every visitor, not because it is common on the sites we audit. A checklist that stops there leaves out the defects that come up most, and that don't show on screen.

The whole list, on every page analyzed

Our audit checks the items on these lists across the analyzed pages of your site, on all 9 pillars, and brings them together in a single report.

Measurements happen in a browser, the way a visitor sees the site. The page is loaded without a single click, and whatever is already there gets recorded. The keyboard is tested with real key presses, the site is displayed at three screen widths, and controls are actually clicked when that changes nothing on your side. On the reference page, usually the homepage, the server's response is compared with the rendered page. Load times come from real visitors when Google publishes that data for the site, and from a lab test otherwise; responsiveness can only be measured on real visitors, so without their data it is reported as not verifiable, never assumed to be fine.

Each pillar gets a score out of 100 on a documented, stable scoring system applied to the facts recorded during the audit. The four situations at the top cap the overall score, and a check that doesn't apply doesn't count. For a business established outside the EU, the EEA, the UK or Switzerland, the report records the compliance and EU transfer observations without counting them against the score.

For each defect found, the report names the page and the value observed; when the check rests on a law, a standard or a specification, it cites the source. It is the document you hand to whoever does the fixing. Every limit of the review is stated in the report, and a point we could not verify is never presented as compliant. The two sample reports show these checks the way a report presents them, pillar by pillar.

You give us the site's URL, with no access to hand over. Plans start at €200 excl. VAT; only the number of pages analyzed and the price change. They are listed on the pricing page. The report is delivered in 5 working days up to 60 pages, payment collected on delivery.