--- name: site-advice-audit description: Audit a website against the 50 Site Advice checks — domains & DNS, hosting & infrastructure, security/privacy/compliance, email deliverability, SEO, performance, design & UX, and marketing & conversion. Use when asked to review/health-check a website. Produces a scored report with PASS / CHECK / FIX per item and concrete fixes. --- # Site Advice website audit This skill turns the 50 website tips from **siteadvice.be** into a repeatable audit you can run against your *own* website. It walks through eight areas — domains & DNS, hosting & infrastructure, security/privacy/compliance, email & deliverability, SEO & findability, performance, design & UX, and marketing & conversion — and for each of 50 checks tells you exactly how to verify it and what a PASS looks like versus how to FIX it. Many checks are **automatable**: fetch the page and its response headers, resolve DNS records over DNS-over-HTTPS, read `robots.txt` and the sitemap, follow the HTTP→HTTPS and www redirects, and inspect the HTML for titles, meta tags, structured data, favicons/manifest, image formats, form labels, and language markup. A minority are **operational** — backups, monitoring, patching cadence, follow-up processes — that no amount of fetching can prove; those can only be **confirmed manually with the owner**, so the skill reports them as CHECK rather than pretending to verify them. A further group need **human judgment** — design fit, copy quality, whether reviews are genuine. Everything that can't be settled by a fetch is marked so you don't score it mechanically. The output is a single scored Markdown report: one status per check (**PASS / CHECK / FIX**), a one-line note, the concrete fix, an overall score, and a "Top 3 things to fix first" list. Each check links back to its full explanation at `https://www.siteadvice.be/tips//`. ## How to run 1. **Ask for the target.** Get the canonical domain (e.g. `example.com`). Confirm whether the audit covers the whole site or a specific section. Ask if there's anything you should skip (staging, gated areas). Ask the two conditionals up front: **does the site sell online?** (check 37) and **is it multilingual?** (check 38) — mark them N/A if not. 2. **Be gentle and non-destructive.** Only make normal `GET`/`HEAD` requests. Never submit forms, never POST, never hit checkout/cart/login endpoints, never crawl aggressively — a handful of pages (homepage plus two or three inner pages) is enough. Space requests out; obey `robots.txt`. This is a health check, not a load test. 3. **Gather evidence** (reuse it across many checks — fetch once): - **Homepage over both schemes.** `curl -sI http://example.com` and `curl -sI https://example.com`, plus the same for the `www` and non-`www` hosts. Record the status codes and the `Location` chain so you can see how HTTP, www, and non-www funnel to one canonical HTTPS URL in a single hop. - **Full response headers** of the canonical homepage: `curl -sI https://www.example.com/`. Note `Strict-Transport-Security`, `Content-Security-Policy`, `X-Content-Type-Options`, `Referrer-Policy`, `Permissions-Policy`, `X-Frame-Options`, `Set-Cookie` flags (`Secure`/`HttpOnly`/`SameSite`), `Cache-Control`, `Content-Encoding` (gzip/br), and the HTTP version. - **HTML of the homepage and 2–3 inner pages.** `curl -s https://www.example.com/`. Extract ``, `<meta name="description">`, `<meta name="viewport">`, `<meta name="theme-color">`, `<link rel="canonical">`, `<link rel="icon">`/`apple-touch-icon`/`manifest`, `<html lang>`, Open Graph/Twitter tags, `hreflang` links, JSON-LD, headings, image tags (formats, `width`/`height`, `loading`, `alt`), form `<label>`/input types, inline vs external CSS/JS, and the list of third-party hosts assets load from. - **DNS over DoH** (no CLI `dig` needed). Query Cloudflare `https://cloudflare-dns.com/dns-query` or Google `https://dns.google/resolve`. Examples: ``` curl -s 'https://dns.google/resolve?name=example.com&type=A' curl -s 'https://dns.google/resolve?name=example.com&type=AAAA' curl -s 'https://dns.google/resolve?name=example.com&type=MX' curl -s 'https://dns.google/resolve?name=example.com&type=TXT' # SPF lives here curl -s 'https://dns.google/resolve?name=_dmarc.example.com&type=TXT' curl -s 'https://cloudflare-dns.com/dns-query?name=example.com&type=DS' -H 'accept: application/dns-json' # DNSSEC ``` For the DoH JSON APIs, the `Answer` array holds the records; an `AD: true` flag (or a present, valid `DS`/`RRSIG`) indicates DNSSEC. - **robots.txt and sitemap.** `curl -s https://www.example.com/robots.txt` (look for a stray `Disallow: /`, blocked CSS/JS, sensitive paths advertised as recon, and a `Sitemap:` line), then fetch the sitemap URL it names (or `/sitemap.xml`) and confirm it lists real URLs. Also note whether **AI crawlers** (`GPTBot`, `PerplexityBot`, `Google-Extended`, `ClaudeBot`) are blocked — that is a legitimate business choice, but it means no citations in AI answers; report it as a deliberate trade-off, not a defect. - **llms.txt (optional, growing convention).** `curl -s https://www.example.com/llms.txt` — a Markdown site map for AI assistants (llmstxt.org). Its absence is normal today (not a FIX); its presence is a positive GEO signal worth a mention. - **Core Web Vitals, measured (optional).** If you can fetch external URLs, the PageSpeed Insights API needs no key at low volume: `curl -s 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://www.example.com/&strategy=mobile'` — `loadingExperience` holds real-user CrUX field data (LCP/CLS/INP), `lighthouseResult` the lab numbers. Prefer these measured values over guessing from page weight when evaluating the performance checks. - **A deliberate 404.** Request a URL that can't exist (`/this-page-does-not-exist-xyz`) and check both the returned HTTP status (must be `404`) and whether the body is a friendly on-brand page. - **Leftover backups/secrets.** Probe a short list of common leaked paths and record the status code for each (only `GET`/`HEAD`, no downloads beyond the response): `/config.php.bak`, `/config.old`, `/.env`, `/backup.zip`, `/db.sql`, `/wp-config.php.bak`, `/.git/config`. Any `200` returning source or credentials is a serious leak (check 15). - **TLS + certificate expiry.** Note the certificate's expiry from the TLS handshake, and check TLS config with a public SSL test (feeds checks 07, 43, 44). 4. **Evaluate each of the 50 checks** below using that evidence. Mark **PASS**, **CHECK** (automated signal is ambiguous, the item is operational and can only be confirmed with the owner, or it's a human-judgment call), or **FIX** (clear problem). Record a one-line note and the fix for anything not passing. If a check genuinely doesn't apply (e.g. hreflang on a single-language site, checkout on a brochure site), mark it **N/A** and exclude it from the score. 5. **Output the report** in the format at the end. --- ## THE 50 CHECKS ### Domains & DNS **01. How do you choose a domain name people actually remember?** — `/tips/memorable-domain-name/` - *Check:* Judge the canonical domain for length, spelling traps (hyphens, doubled letters, digits that could be words in any customer language), brandability, and whether the TLD fits the audience (ccTLD for a local market, `.com` for international). Check where likely mistakes lead: look up the `.com`/local-ccTLD sibling, singular/plural forms and obvious misspellings — do they land on the owner, a parked page, or a stranger? - *Pass / Fix:* PASS = a short, pronounceable, brandable name on the extension the audience expects, with the confusion-critical variants either owned (and 301'd to the canonical domain) or verified harmless. FIX = register and redirect only the variants where confusion causes real harm; a rename is a last resort (301 everything). - *(Partly human judgment — memorability isn't fully automatable.)* **02. Is your domain protected against hijacking and expiry?** — `/tips/correct-whois-and-registrar/` - *Check:* Confirm DNSSEC is active — query the `DS` record at the registry (`type=DS` over DoH) and/or check the `AD` flag on a signed lookup. Ask the owner whether registrar lock (`clientTransferProhibited`) and MFA are on, whether nameserver control is with the business, and whether the registrant/renewal email is valid, monitored, and *not* hosted on the same domain. - *Pass / Fix:* PASS = DNSSEC validates end-to-end (DS at the registry matches the zone's DNSKEY; `AD` flag set on a signed lookup — a DS record alone isn't a pass), registrar lock + MFA on, renewal contact accurate and off-domain, auto-renew live. FIX = enable DNSSEC where the DNS provider manages key rollover reliably and verify the full chain, enable registrar lock and MFA (suggest a registry-level lock for a high-value domain), move renewal/recovery contact to an off-domain monitored mailbox, enable auto-renew, and set a yearly review reminder. **41. Who controls your domain, DNS, hosting and recovery accounts?** — `/tips/who-controls-your-accounts/` - *Check:* **Operational — confirm with the owner; cannot be fetched.** Is the *business* the registered domain holder (not an employee, freelancer or agency)? Is each service held in a company-controlled customer/organization account, with administrators on *named* logins rather than one shared credential? Is recovery/billing email a monitored business address on a *separate* domain? Is MFA on registrar, DNS, hosting, and email? Does any critical account depend on a single person — and is there an account inventory and an offboarding routine for departing staff or suppliers? - *Pass / Fix:* PASS = business is the registered holder and contract owner, named admins with MFA, no single-person dependency (second admin or tested recovery procedure), recovery/billing on a monitored off-domain inbox, account inventory current. FIX = transfer holder/ownership to the business, replace shared logins with named accounts, store recovery codes in a company password manager, point recovery/billing at an off-domain monitored mailbox, write the account inventory, and add offboarding (remove access, transfer ownership, revoke keys/sessions) to the leaver routine. - *(Operational — report as CHECK until confirmed.)* ### Hosting & Infrastructure **04. Do your links and file paths survive deployment?** — `/tips/case-insensitive-host-names/` - *Check:* Hostnames are case-insensitive but Linux paths are not, and environments differ between laptop and server. Grep the HTML for uppercase letters in `href`, `src`, and `url()` values, then request a couple of assets with altered case (e.g. `/Logo.PNG` vs `/logo.png`) and see whether one 404s. Spot-check a few internal links for rot after the last deploy. - *Pass / Fix:* PASS = all links/filenames lowercase and consistent; no case-mismatch or environment-path 404s. FIX = adopt an all-lowercase convention for files, folders, and slugs; use consistent path handling across environments; match every link to the exact on-disk name; test internal links after every deploy; 301 any indexed mixed-case URLs. **06. Can visitors reach your site reliably?** — `/tips/reachable-from-everywhere/` - *Check:* One homepage load in your own browser is not proof. Test every public entry point (apex, `www`, HTTP→HTTPS redirect, key subdomains) for the intended canonical URL without loops or certificate errors; verify expected status *and* a distinctive piece of content on key pages and assets, not just a response. Confirm the `A` record resolves; if an `AAAA` is published, test the IPv6 path independently (a broken AAAA is worse than none — a missing one just means IPv4-only, which DNS64/NAT64 networks can usually still reach). Check TTLs are sane and nameservers redundant (`NS`); test from several regions *and* several network providers, including mobile. - *Pass / Fix:* PASS = all entry points resolve, connect (valid TLS) and serve the expected content from several regions/networks; any published AAAA verified working. FIX = repair or remove a broken `AAAA` (add one only once the full IPv6 path is tested), fix redirect loops and certificate mismatches, investigate CDN/WAF/geo rules blocking legitimate networks (one failing probe may just be a blocked bot — verify before declaring an outage), use redundant DNS, and lower TTLs before any planned migration. (Ongoing monitoring is check 43.) **18. Could someone else safely update your website?** — `/tips/maintainable-with-templates-and-css/` - *Check:* Inspect the HTML for duplicated header/footer markup and repeated inline `style="..."` attributes (signs of copy-paste rather than shared templates/components), and whether repeated style values use custom-property tokens. Then the operational half (**ask the owner**): is there one authoritative copy under version control (no live-server hand edits)? A documented way to preview, deploy and roll back? A README and dependency list? Has the content export ever been tested? - *Pass / Fix:* PASS = shared elements and business facts exist once (templates/components/central fields — component-scoped styles are fine when reused), tokens for repeated values, a known authoritative source, documented deploy + rollback, dependencies recorded, export tested. FIX = de-duplicate layout and business facts into shared homes, introduce `:root` tokens, put code/config under version control with a documented deploy and rollback step, write the README (no secrets in it), list dependencies and remove unused ones, and test the export instead of trusting the export button. - *(Partly requires source access; operational half needs the owner.)* **42. Could you restore your website from a clean backup today?** — `/tips/tested-backups-and-restore/` - *Check:* **Operational — confirm with the owner; cannot be fetched.** Has the owner set an RPO/RTO (how much data loss and downtime is acceptable), and does backup frequency match it? Are backups automatic, covering files **and** a database-aware database export, uploads and configuration at compatible points in time? Is at least one copy held outside the production account under **separate credentials**, encrypted, with immutable/offline generations — and are the decryption keys recoverable without production? Are the jobs monitored (success, recency, size), and has a **complete** restore been tested into a protected environment recently, from written steps? - *Pass / Fix:* PASS = RPO/RTO defined and met, automatic independent backups of files + DB + uploads + config, multiple generations, monitored jobs, keys recoverable, a full restore tested within ~6 months (sooner for critical/fast-changing sites) with the steps documented. FIX = set RPO/RTO first, schedule automatic database-aware backups off the production account with separate credentials and immutable generations, alert on job failures and size anomalies, store secrets/keys outside the archive, and test a complete restore into a protected, non-indexed, no-outbound-mail environment — choosing a generation from before any suspected compromise (restorable ≠ clean). - *(Operational — report as CHECK until confirmed.)* **43. Would you know before your customers if something broke?** — `/tips/uptime-and-expiry-monitoring/` - *Check:* **Operational — confirm with the owner; partly signaled by the cert-expiry evidence.** Is there external monitoring at an interval matched to business impact (minutes for a shop, ~5 min for a brochure site) that verifies **status, final URL and stable real content** (not just a `200`), from **multiple locations with confirmation required** before an outage alert? Is **TLS renewal** alerted at several thresholds, and **domain status tracked alongside the registrar's actual billing deadline** (registry expiry ≠ registrar deletion date)? Is one important function checked **safely** (tagged test message / test account / payment test mode — never real transactions)? Internal health (errors, disk, database, cron) watched — or known to be the host's job? Do alerts reach a **named responder over two channels**, with maintenance suppression, recovery notices, and a periodically tested alert path? - *Pass / Fix:* PASS = content-verified multi-location checks with confirmation policy, TLS + domain-renewal monitors (billing deadline included), a safe synthetic check of a key function, internal health owned by someone, alerts to a named owner over two channels with a tested path. FIX = add content-aware external checks with a confirmation policy, alert on TLS renewal failure early (several thresholds), track registrar billing as well as registry expiry, build the synthetic check with test data/accounts and secure credentials (no secrets or personal data in monitor logs), assign internal-health ownership, route alerts over two channels to a named responder, and test the alert route with a controlled failure — reviewing monitors whenever URLs or providers change. - *(Operational — report as CHECK until confirmed.)* ### Security, Privacy & Compliance **07. Have you checked your site for security holes?** — `/tips/check-for-security-holes/` - *Check:* Assess the real attack surface — only on sites you're authorized to test, non-destructively. Confirm HTTP→HTTPS + HSTS (detailed in 44). Look for exposed software/config (versions leaking in source, headers, `/README`), exposed `.git`/`.env`/backups (15), account/permission hygiene (45), form/upload handling (30), and third-party dependency freshness. Check TLS with a public SSL test — noting that behind a reverse proxy it grades the edge, not the origin hop. Widen past the five basics: other hostnames/APIs, DNS control, deployment accounts and secrets. Confirm a recheck cadence exists that also fires on releases, advisories and incidents — not a one-off. - *Pass / Fix:* PASS = no exposed software/config/files, TLS clean, inputs and uploads handled safely, dependencies current, scheduled + event-driven rechecks. FIX = patch and remove exposed software/config, close leaked files, parameterize data values and allowlist dynamic identifiers, encode output contextually, restrict uploads (type/size, no trusted MIME, non-executable storage), keep dependencies current, and put a recurring review on the calendar with advisory monitoring between passes. Treat scanner findings as leads to verify, not proof. **12. Does your privacy notice describe what you really do?** — `/tips/publish-a-privacy-policy/` - *Check:* Fetch the site and confirm a linked privacy notice exists (usually footer) and reads as bespoke — naming the data actually collected, the third-party processors in use, retention periods, and how users exercise their rights — not boilerplate. Load the page and watch whether non-essential analytics/ad cookies fire *before* consent, and whether a real banner with a genuine "reject" appears. - *Pass / Fix:* PASS = clear, dated, plain-language notice matching real data flows, linked everywhere; non-essential cookies gated behind opt-in. FIX = rewrite the notice to match what you actually collect, the processors you use, retention, and rights; link it from every page and form; gate non-essential scripts behind consent. (Data minimization itself is check 46.) **15. Can strangers browse your folders?** — `/tips/block-directory-browsing/` - *Check:* Request a directory likely to lack an index file (`/uploads/`, `/images/`, `/assets/`). A file listing means autoindex is on. Then **probe for leftover backup/source files served in cleartext** — FAIL on any `200` returning source or credentials: ``` for p in config.php.bak config.old .env backup.zip db.sql wp-config.php.bak .git/config; do curl -s -o /dev/null -w "%{http_code} $p\n" "https://www.example.com/$p"; done ``` A `403`/`404` on each is fine; a `200` that returns a DB password or source is a leak. A folder that answers `403`/`404` on its index can still serve a file by direct URL, and an Apache `.htaccess` deny protects only requests that *reach* Apache — a proxy, CDN or static-file layer answering first bypasses it. Test the actual public URLs, don't assume. - *Pass / Fix:* PASS = no generated listing on index-less folders (`403`, `404` or a custom page all fine); no backup/source/dotfile reachable at any layer. FIX = `Options -Indexes` (where the host permits the override) / confirm `autoindex off` in the serving scope, index files as backup only, **physically delete** obsolete `.bak`/`.old`/`.sql` backups from the web root (move still-used include files out or deny + test), move credentials/exports above the docroot, deny dotfiles/backup suffixes matched to the site's actual names, and block `.git` directories with an anchored pattern like `RedirectMatch 404 "(?i)(?:^|/)\.git(?:/|$)"` (an unanchored `/\.git` also catches `.github`/`.gitignore`). **44. Is HTTPS enforced everywhere, with the right security headers?** — `/tips/https-everywhere-and-headers/` - *Check:* Confirm ordinary `http://` page requests permanently redirect to `https://` (all four host/scheme combinations) and that internal links/canonicals/sitemaps reference HTTPS directly (the first HTTP request is exposed before any redirect). Scan for **mixed content** across all resource types — scripts, styles, images, media, frames, API calls, form targets, downloads. Read response headers for `Strict-Transport-Security` (noting `includeSubDomains` needs a subdomain inventory — cached HSTS makes non-HTTPS subdomains unreachable), `X-Content-Type-Options: nosniff` (script/style MIME types must be correct first), `Referrer-Policy`, `X-Frame-Options`/*enforcing* CSP `frame-ancestors` (ignored in report-only and meta), and `Content-Security-Policy` (as a real header; report-only without a reporting endpoint teaches nothing). Check `Set-Cookie` for `Secure`, `HttpOnly`, and a flow-appropriate `SameSite` on session cookies — SameSite is defense in depth, not CSRF protection. Behind a proxy, confirm the origin hop is HTTPS-verified too. - *Pass / Fix:* PASS = direct HTTPS references + permanent redirects, no mixed content anywhere, cautious HSTS, nosniff on verified MIME types, Referrer-Policy + enforcing frame protection, a tuned real-header CSP (nonces/hashes over unsafe-inline), secured cookies. FIX = link HTTPS directly and redirect the rest (308 where methods matter), audit mixed content across all types, roll out HSTS short-first with a subdomain inventory, verify MIME types then add nosniff, mark cookies Secure/HttpOnly/SameSite with app-level CSRF checks, and build report-only CSP with monitored reporting up to enforcement. **45. Are your software and admin accounts patched and locked down?** — `/tips/patching-and-account-hygiene/` - *Check:* **Operational — confirm with the owner; source may hint at it.** Is there an inventory of every layer (CMS/plugins/themes plus OS, server, runtime, DB, deploy tooling) with a named maintainer, updated on exploitation-aware priorities (actively exploited/critical internet-facing ASAP, not a flat days rule) with backup+rollback ready? Any abandoned/EOL components still installed (they get no fixes — replace or remove)? Unused plugins/themes uninstalled (not deactivated — files stay reachable) and unneeded accounts disabled with sessions/tokens revoked at offboarding? Least privilege with individual accounts — including registrar/DNS/hosting/deploy accounts, not just the CMS? Unique passwords + MFA (phishing-resistant where supported) with a protected reset path? Login throttling designed against lockout abuse, and admin-activity logs with alerts, secrets excluded? (Version strings leaking in HTML/headers are a partial automated signal.) - *Pass / Fix:* PASS = maintained inventory patched by risk, no abandoned components, unused code/accounts removed with revocation, least privilege across the whole control plane, phishing-resistant MFA with protected recovery, abuse-safe throttling + monitored logs. FIX = build the layer inventory with owners, prioritize by exploitation/exposure, replace abandoned components, uninstall unused code and revoke offboarded access fully, extend individual least-privilege accounts to every control-plane system, enforce unique passwords + strong MFA with recovery hygiene, and add progressive-delay throttling plus alerting (renaming `admin` is minor noise reduction, not a control). - *(Operational — report as CHECK until confirmed.)* **46. Do you collect only the data you need — and ask before tracking?** — `/tips/data-minimization-and-consent/` - *Check:* Inspect forms for fields that aren't needed to complete the task (phone, DOB, company on a simple inquiry). Inventory third-party hosts that receive visitor data (analytics, embeds, maps, fonts, chat, ad pixels). Watch whether non-essential cookies/trackers load **before** consent, and whether withdrawing consent is as easy as giving it. Retention limits are operational — ask the owner. - *Pass / Fix:* PASS = lean forms, few third parties, non-essential trackers gated behind prior consent, easy withdrawal, retention limits set. FIX = remove unnecessary form fields, drop trackers/embeds without a clear purpose, set and enforce retention limits, disclose processors, and ensure non-essential cookies only load after consent with equally easy withdrawal. ### Email & Deliverability **08. Is your mail set up so it can't be spoofed?** — `/tips/secure-mail-server/` - *Check:* Resolve DNS. **SPF:** exactly one TXT starting `v=spf1`, ideally ending `-all`, with ≤10 DNS-query-causing terms counted across the full recursive evaluation (exceeding is `permerror`, not fail). **DKIM:** a public key at your selector (`selector._domainkey.example.com` — TXT, or a provider-managed CNAME pointing at one). **DMARC:** a TXT at `_dmarc.example.com` starting `v=DMARC1` with a policy and `rua=`. Where sample headers are available, verify **alignment**: the SPF `MAIL FROM` domain or DKIM `d=` domain must align with the visible From domain — a service passing with its own domain still fails DMARC. Confirm the mail host isn't an open relay. - *Pass / Fix:* PASS = one valid SPF (`-all`), DKIM published, DMARC enforced (`quarantine`/`reject`) with reporting, alignment verified on real mail. FIX = publish/repair SPF (full recursive lookup count, not just visible `include:`s), enable DKIM on every sender, add DMARC starting at `p=none` with a report parser, fix unaligned streams and check subdomain senders (the parent policy can apply to them) before enforcing; never run an open relay, and require TLS on authenticated submission. **09. Does your email reach the inbox — and resist abuse?** — `/tips/protect-email-from-harvesters/` - *Check:* Grep the HTML for plain `mailto:` links, raw addresses, and obfuscation theater (`[at]`/`[dot]`, address images — weak protection that costs accessibility). Note whether a contact form to a role alias is offered; if so, probe its hardening: fixed server-side recipient, no visitor-controlled recipients or headers, rate limiting, an accessible honeypot, HTTPS `POST`. Beyond authentication (08), deliverability rests on **sending reputation and filtering**: for consent-critical mail (confirmations, receipts, resets) flag open-tracking pixels, heavy nested HTML, and shortened links — patterns that can resemble abusive mail, though no single item decides placement. Ask the owner whether they can react to a bounce/blocklisting from rejection evidence. - *Pass / Fix:* PASS = contact via a hardened, accessible form to a role alias (or a readable published address accepted as harvestable), lean transactional mail, monitored bounces/complaints, a delisting plan. FIX = harden the form (fixed recipient, no header injection, honeypot + server-side validation, no echoed content in auto-replies), use role aliases for routing (they don't conceal — retiring one is a last resort), keep published addresses readable rather than encoded, monitor delivery telemetry (SMTP acceptance ≠ inbox), and identify the exact listing before acting on a blocklist — some expire on their own, shared-IP listings belong to the operator. **11. Are you still emailing from a free ISP address?** — `/tips/use-a-domain-email-address/` - *Check:* Look at the address in the footer/contact page and any `mailto:`. Is it `@yourdomain` or a free provider (`gmail.com`, `@telenet.be`, etc.)? Cross-reference with 08 — the point is control: with your own domain you choose and authenticate every sending service; a provider's domain is authenticated by the provider, on the provider's terms. - *Pass / Fix:* PASS = business mail sent from `you@yourdomain`. FIX = set up mailboxes/aliases on your own domain, use encrypted IMAP (993) / SMTP (465/587), inventory all senders and authenticate with one SPF record + per-service DKIM + monitored DMARC, and keep bulk marketing on a dedicated domain/subdomain you control at an ESP (with lawful lists and working unsubscribe). ### SEO & Findability **GEO / AEO (emerging — guidance, not a scored check).** Getting surfaced or cited in AI answers rests on the same fundamentals as good SEO plus extra clarity — there's no paid placement and no reliable trick. What helps: **answer first**, **question-shaped headings**, concise quotable summaries near the top (AI engines quote exactly these), an **FAQ with structured data** (JSON-LD), being **crawlable as plain HTML** — including for AI crawlers (see the robots.txt evidence step), and being a trustworthy, well-linked source (see E-E-A-T under checks 35/54). Optional extras worth noting when present: an `llms.txt` file, and `speakable` JSON-LD pointing at the page's answer block. Watch analytics for AI-referral traffic; treat it as a bonus, not a strategy you can force. **03. Have you chosen one canonical hostname and redirected the rest?** — `/tips/avoid-too-many-host-aliases/` - *Check:* Request all four combinations (`http`/`https` × `www`/non-`www`) plus any other hosts the site answers on (`web.`, `old.`, staging) and a few deep paths. Confirm each ends on the canonical `https` URL after **one** permanent redirect hop (301/308, not a chain), that the canonical URL itself returns `200` directly, that every HTTPS alias presents a valid certificate for its name, and that indexable pages carry an accurate absolute self-referential canonical tag. Confirm dev/staging hosts require authentication (not merely `noindex`), and look for dangling `CNAME` targets on unused subdomains. - *Pass / Fix:* PASS = one canonical host; aliases reach it in a single permanent hop with valid certificates; canonical tags consistent with redirects/sitemap; staging behind auth; no dangling DNS. FIX = pick one canonical host, combine HTTP→HTTPS and www redirects into one hop (edge-side when behind a CDN/proxy — origin scheme checks can loop), use 308 where POST endpoints must survive, add accurate canonical tags, put authentication on dev subdomains, and remove DNS records for abandoned services. **13. Can search engines discover and index the right pages?** — `/tips/add-a-robots-txt/` - *Check:* Fetch `/robots.txt`: it should exist, return plain text (not an HTML error or login page), **not** contain a site-wide `Disallow: /`, not block render-critical CSS/JS, and include a `Sitemap:` line — checked per public hostname, since rules apply only to the exact protocol/host/port serving the file. Fetch that sitemap and confirm it lists real canonical URLs (an empty sitemap is worse than none). Across sampled pages check `<meta name="robots">`/`X-Robots-Tag` for accidental `noindex`, confirm canonicals point where intended, and flag any URL that is *both* disallowed and carrying a `noindex`/canonical the crawler can therefore never read. robots.txt is **not** a security control — flag any `Disallow` that reads as recon. - *Pass / Fix:* PASS = robots.txt present with no accidental block, CSS/JS crawlable, non-empty sitemap referenced, no accidental `noindex` on wanted pages, sensible canonicals, no sensitive paths advertised. FIX = allow crawl and disallow only true junk, never block render-critical assets, add a `Sitemap:` line to a sitemap of real URLs, remove stray `noindex`, use `noindex` (not `Disallow`) to keep pages out of results, and protect private areas with real auth. **22. Are your URLs short, readable, and shallow?** — `/tips/url-structure-and-directory-depth/` - *Check:* Sample URLs from the sitemap/navigation. Are they lowercase, hyphen-separated, descriptive, and sensibly short? (Segment count is cosmetic — discovery depends on internal linking, so flag *poorly linked* pages, not slash counts.) Watch for session identifiers in URLs (a security issue, not just SEO), tracking-parameter duplicates, and mixed case creating variants. - *Pass / Fix:* PASS = clean, lowercase, hyphenated, stable slugs on new content; sessions in cookies, not URLs; parameter variants canonicalized only where content is equivalent. FIX = generate readable slugs from titles for new URLs (don't churn established working ones), move session state to secure cookies, keep tracking params out of internal links with canonicals on true duplicates only (never on pagination/filters that change content), and 301 genuinely moved URLs to their closest equivalent with internal links updated. - *Internal linking:* confirm each article links to two or three genuinely related pages with **descriptive anchor text** (not "click here"), that related pages form a **hub/cluster** (a pillar page linking to detail pages that link back), and that no important page is an orphan. Link where it helps the reader; don't stuff. **28. Does every page have a unique title and meta description?** — `/tips/unique-titles-and-meta-tags/` - *Check:* Extract `<title>` and `<meta name="description">` across sampled pages. Confirm each indexable page with a distinct purpose has a distinct, front-loaded, concise title (device truncation varies — judge by preview, not a fixed count) agreeing with the visible heading, and a genuinely useful page-specific description — **not** manufactured just to be technically unique (accurate templates are fine at scale; missing descriptions on low-value pages are acceptable). Check for a leftover `<meta name="keywords">` (dead), the core OG properties (`og:title`/`og:type`/`og:url`/`og:image` + description/image:alt), `twitter:card`, and canonicals on duplicate/similar URLs only. - *Pass / Fix:* PASS = distinct, useful titles/descriptions on important pages; core OG + twitter:card present; canonicals scoped to true duplicates; no keywords tag. FIX = write distinct front-loaded titles consistent with headings, useful descriptions for important pages (template accurately at scale), delete any keywords meta, add core OG properties + twitter:card with fetchable images, and canonicalize only genuine duplicates. - *Search intent & thin content:* name each key page's **intent** (informational/navigational/commercial/transactional) and confirm the page satisfies it. Flag **thin/overlapping pages** — **improve** a promising page, **merge** overlapping ones (301 the old URLs), or **prune** dead ones. Don't pad to a word count. **38. Is your multilingual site set up correctly with hreflang?** — `/tips/multilingual-and-hreflang/` *(conditional: if multilingual)* - *Check:* **Only if the site offers multiple languages** — otherwise N/A. Confirm each language has its own crawlable URL (subdir/subdomain/ccTLD), not cookie/JS switching on one URL, and that each localized page carries a *same-language* canonical (translations canonicalized to one master language defeat the setup). Check `hreflang` in the head with absolute URLs: reciprocal, self-referencing, valid language codes (never a bare country code), `x-default` only where a real fallback URL exists, and every target resolving to the intended indexable page. Confirm `<html lang>` per page and crawlable links between versions. - *Pass / Fix:* PASS = distinct URLs with same-language canonicals, reciprocal verified hreflang, correct `lang`, reviewed translation, crawlable version links. FIX = give each language a stable URL and its own canonical, repair reciprocity and dead targets, fix bare-country or invalid codes, set `lang` (incl. foreign passages), localize meaningful visible + meta text with fluent review, and link versions with ordinary links instead of forced IP redirects. - *(Mark N/A for single-language sites.)* **47. Will old URLs still work after a redesign or migration?** — `/tips/redirects-after-migration/` - *Check:* **Operational + partly automatable.** Ask whether there's been a recent redesign/migration or one planned. If a migration happened, test the *old* URL inventory directly: each changed URL should make one permanent hop (301/308) to its intended final HTTPS address — no loops, chains, or redirects into missing pages; unchanged URLs should serve content, not self-redirect; blanket homepage redirects may be treated as soft 404s. Crawl for 404 spikes (triaging bot probes from missed redirects), confirm internal links, canonicals, hreflang and the sitemap use final URLs, no leftover development noindex/crawl blocks, and the map retained long-term (for domain moves: old domain's registration, DNS and TLS still alive — a dead domain answers no redirects). - *Pass / Fix:* PASS = changed URLs redirect once to relevant equivalents, unchanged ones serve in place, honest 404/410 for the retired, signals updated, map (and old-domain infrastructure where applicable) kept for years. FIX = build the inventory from CMS + historical sitemaps + logs + analytics + backlink data (no single source is complete), map query-string variants too, implement precise tested permanent redirects, update all signals, lift dev blocks, and monitor old-inventory responses plus search-console reports for weeks. - *(If no migration has happened or is planned, mark CHECK/N/A as appropriate.)* **40. Promoting your site: why "guaranteed rankings" are a scam** — `/tips/promote-smart-no-ranking-guarantees/` *(the finale)* - *Check:* Mostly advisory. Review how the site is promoted: any reliance on links bought for ranking manipulation, "guaranteed #1" agencies, or manipulation tactics? Check that legitimately paid/sponsored links carry `rel="sponsored"`/`rel="nofollow"` and compensated mentions are disclosed. Confirm the durable fundamentals (useful content, crawlable/indexable pages with internal links, technical health, genuine mentions, UTM-tagged ads paired with cost/conversion data, Search Console for Google performance + analytics for behavior). - *Pass / Fix:* PASS = promotion rests on content, technical health, and genuine disclosed relationships; paid links qualified; no ranking-guarantee schemes. FIX = reject guaranteed-ranking pitches (a money-back offer changes nothing), stop buying ranking links and qualify legitimate ones, invest in useful content and crawlability, earn real mentions, and measure with Search Console (Google-only, average positions) plus analytics — maintaining continuously, since earned visibility isn't self-sustaining. - *(Human judgment.)* ### Performance **Core Web Vitals (applies across 25, 26, 48).** Measure the three field metrics on the homepage and top landing pages with a real-user (field) data source and the Search Console Core Web Vitals report — trust field data over one lab score: **LCP under 2.5 s** (loading), **CLS under 0.1** (visual stability), **INP under 200 ms** (responsiveness). They're a real but modest ranking signal — the bigger payoff is UX and conversion. Fix the "poor" group first, aim for "good" on all three. **25. Are your assets delivered efficiently?** — `/tips/minify-and-clean-your-code/` - *Check:* Are CSS/JS assets minified? Does the *public* response send `Content-Encoding: gzip` or `br` on text types (never on already-compressed formats)? Is HTTP/2 or HTTP/3 negotiated at the public URL (a proxy may differ from the origin)? Look for dead markup, heavy libraries pulled in for one feature, and render-blocking external scripts lacking `defer`. Check `Cache-Control`: long `public, immutable` lifetimes belong on content-versioned assets ONLY — flag them on HTML or personalized responses (shared-cache exposure risk). A CDN helps distributed audiences or loaded origins — weigh it (incl. privacy/origin-TLS), don't mandate it. - *Pass / Fix:* PASS = minified assets, compression verified publicly, modern HTTP at the edge, non-critical JS deferred, little dead code, aggressive caching restricted to versioned assets, HTML briefly cached/revalidated. FIX = remove unused code on coverage evidence (test after — dynamic references hide), add a minification step preserving license comments, enable negotiated Gzip/Brotli, `defer` suitable scripts and keep their execution light, adopt HTTP/2/3, scope long cache headers to versioned filenames, and evaluate a CDN against measured need with its privacy and origin-TLS homework done. - *CWV:* responsiveness (INP) problems trace to too much main-thread JavaScript — cut/defer heavy scripts and break up long tasks; edge delivery + HTTP/2/3 help time-to-first-byte (LCP). **26. Are your images optimized for the web?** — `/tips/optimize-your-images/` - *Check:* Inspect `<img>`/`<picture>` and asset sizes. Are photos served as modern formats (WebP/AVIF with a feature-preserving fallback) rather than large JPEG/PNG/GIF? Do images have correct `width`/`height`, `srcset` with candidates covering high-density screens (CSS slot width alone is too small), and a `sizes` value matching the real CSS layout? Is `loading="lazy"` on noncritical off-screen images — and absent from the likely LCP image? Any photos leaking EXIF/GPS metadata? - *Pass / Fix:* PASS = tested-smallest formats with proper fallbacks, density-aware srcset with accurate sizes, correct dimensions, lazy loading scoped to noncritical images, LCP image eager and discoverable in initial HTML. FIX = convert photos where testing shows a saving, generate multiple widths with accurate `sizes`, compress judged by eye (quality scales aren't portable), strip metadata, set real `width`/`height`, lazy-load only noncritical off-screen images, and verify which srcset candidate actually loads. - *CWV:* identify the actual LCP element (often, not always, the hero) — size, compress, keep it eager and discoverable, `preconnect` to any third-party host it loads from, `fetchpriority="high"` only with measurement. Reserving correct image dimensions prevents the classic image-driven CLS. **48. Have you tested on an ordinary phone and a slow connection?** — `/tips/test-on-real-devices/` - *Check:* **Partly operational.** You can gather field CWV data and run throttled lab tests, but the real test is a representative phone from the audience's actual device mix. Ask the owner whether they've tested on real hardware — cold *and* warm visits — and whether they *interacted* (menu, forms, checkout): INP needs interactions, so a reload-only test never measured responsiveness. Field data sets priorities, lab runs diagnose; compare like with like (device group, scope, percentile, period) rather than one flattering score. Any first-party RUM should be privacy-vetted (first-party ≠ exempt). - *Pass / Fix:* PASS = field CWV in "good", owner confirms representative-device testing with throttling and real interactions, both cache states. FIX = pick devices from audience data, throttle connection + CPU (presets are approximations — confirm big findings on hardware), test cold and warm visits, exercise the key controls so INP and task completion get measured, and use weak real networks for discovery with controlled throttling for verification. - *(Partly operational — report as CHECK for the device-testing part.)* **49. Are your third-party scripts worth their cost?** — `/tips/third-party-script-cost/` - *Check:* From the network view — after exercising consent choices, scroll, forms and embeds, across representative page types (tag managers fetch more after load) — list every third-party origin with its purpose, initiator, bytes, timing and failure behavior. For each, ask what it contributes (revenue, legal duty, security, a used function) and whether the page would suffer without it. Note whether heavy embeds load eagerly rather than on interaction, whether script scheduling is deliberate (`async` for independent, `defer` for compatible classic scripts — neither is lazy loading), and whether containment exists (CSP, sandboxed iframes, SRI on versioned files). Remember directly-included scripts run with page privileges — supply-chain risk. - *Pass / Fix:* PASS = a short, justified, measured list; heavy ones behind accessible interaction placeholders; deliberate scheduling and containment; fonts self-hosted where licensed and maintained. FIX = remove unjustified integrations (with regression checks), interaction-load nonessential widgets behind real buttons with loading states, choose async/defer per script and test order, add CSP/sandbox/SRI containment, self-host where licenses allow, and review each survivor's data, storage, legal basis and consent (see 46). ### Design & UX **10. Is your contact information easy to find?** — `/tips/contact-info-on-every-page/` - *Check:* Confirm there's an obvious, consistent route to reach the business — a clearly labeled Contact link in consistent navigation plus footer details, consistent across sampled pages. Check phone is a `tel:` link with readable/copyable text and email a readable `mailto:`/accessible form. If the business has a public customer-facing location, look for validated JSON-LD using the most specific applicable `LocalBusiness` subtype matching the visible page; a service-area business shouldn't present its address as a storefront. Check the legally required operator details (for Belgium: legal name, establishment address, email contact, enterprise number) are easily accessible. - *Pass / Fix:* PASS = consistently obvious contact route, substantive details identical across site/profile/directories, actionable-and-copyable links, appropriate schema (where a location exists), legal disclosures reachable. FIX = put a Contact link in the nav and shared footer details, align the substance (not punctuation) with the business profile and directories, make details tappable with visible fallbacks, add validated LocalBusiness JSON-LD only for a real public location, complete the legal details, and test every contact route on desktop and mobile. **14. What happens when a visitor hits a broken link?** — `/tips/custom-error-pages-and-link-checks/` - *Check:* Request a made-up URL: confirm it does **not** redirect and the final response is HTTP `404` (not a soft `200`), serving a clear on-brand page that states the page wasn't found, with navigation/search. Permanently-removed pages may return `404` or `410` — both are valid (Google treats them much the same); flag only a `301` to the homepage. If a maintenance page is up, confirm it returns **`503` + `Retry-After`**, not `200`, and that `/robots.txt` stays reachable. - *Pass / Fix:* PASS = real `404` status without redirect + clear error page; removed pages `404`/`410`; planned downtime `503`+`Retry-After` for short windows only; no obvious broken links. FIX = serve a custom 404 (clear message, nav, accessible search) returning the true `404`, add a minimal *static* 500 fallback that survives the failure and leaks no diagnostics, redirect moved pages to their closest equivalent (301/308) and update internal links, review error-response caching, and run a link checker on a schedule — triaging real 404s from server/CDN logs, not Search Console alone. **16. Can visitors find their way around your site?** — `/tips/consistent-navigation/` - *Check:* Review the main navigation across pages: consistent relative placement and order, plain task-focused labels, important pages within a sensible click depth with crawlable internal links? Check `<nav>` regions (distinctly named when multiple), the current page identified in markup (`aria-current`) not just color, breadcrumbs with matching `BreadcrumbList` schema on deep pages, a mobile menu whose toggle is a real `<button>` with `aria-expanded`, adequate touch-target sizes, and keyboard focus states with a skip link. - *Pass / Fix:* PASS = consistent, clearly labeled, reachable, accessible navigation with breadcrumbs on deeper pages. FIX = build nav from one shared include, keep the top level task-focused (test findability rather than enforcing an item count), add breadcrumbs + matching schema, fix the menu-toggle semantics and target sizes, add aria-current and named nav regions, and provide a secondary route sized to the site (footer links, sitemap, or search where warranted). - *(Partly human judgment.)* **17. Does your design fit the people you're trying to reach?** — `/tips/design-for-your-audience/` - *Check:* Mostly human. Assess whether tone, imagery, and clarity match the intended audience; whether a clear value proposition appears early on the page; whether type is legible and text contrast meets WCAG AA (4.5:1 ordinary, 3:1 large — thresholds, not targets); whether trust signals are genuine and specific (real reviews, current credentials, visible guarantee terms) rather than vague badges; and whether the site behaves responsively across screen sizes and inputs. - *Pass / Fix:* PASS = design matches audience goals/context, clear early value prop, AA contrast, responsive behavior, genuine trust signals. FIX = define primary audiences and their main action, prioritize clarity over decoration (keeping essential secondary tasks findable), place genuine trust signals where decisions happen, meet accessibility basics (contrast is one part, not proof), and run small qualitative tests with ~5 representative users per audience. - *(Human judgment.)* **19. Does your site work for everyone, everywhere?** — `/tips/cross-browser-and-progressive-enhancement/` - *Check:* Test core content/navigation with JavaScript disabled — usable where practical? Where a task genuinely requires JS, is that stated with a fallback route? Check responsive behavior across viewport sizes, keyboard-only operation, zoom/text resizing, and what happens when a script loads but fails (baseline content should stay visible). Look for feature detection (not browser sniffing) with runtime error handling, and respect for `prefers-reduced-motion` (any offered color scheme tested for contrast). - *Pass / Fix:* PASS = core content and forms usable without JS where practical (script-dependent tasks clearly stated with alternatives), responsive across the declared support matrix, keyboard/zoom clean, honors reduced-motion. FIX = build on semantic HTML with server-backed forms (server validates every submission regardless of JS), keep baseline content visible until enhancements succeed, define and test a support matrix incl. keyboard/zoom/screen reader/slow network, and use feature detection with fallbacks and error handling. **20. Is your HTML semantic and understandable?** — `/tips/write-valid-html/` - *Check:* Confirm `<!DOCTYPE html>`, `<html lang>` matching the page's actual language, UTF-8 charset, semantic elements chosen by meaning (landmarks — distinguishable when repeated; `<button>` for actions vs `<a href>` for navigation), heading ranks reflecting the content hierarchy (one `<h1>` as convention, no skipped ranks downward), accessible names on interactive controls, and *appropriate* `alt` (informative/functional described; decorative `alt=""`). Check deployed pages, not templates. Validity is a *technique*, not the goal. Test JSON-LD against the applicable feature's requirements — eligibility ≠ guaranteed rich result. - *Pass / Fix:* PASS = semantic, well-structured markup; hierarchy-true headings; named controls; purpose-appropriate alt; structured data matching visible content. FIX = declare doctype/lang/charset, choose elements by behavior and meaning (div is fine when nothing fits better), repair heading ranks, name every control (visible labels preferred), set alt by image purpose, nest correctly, and fix checker findings that reflect real structural problems — pairing the checker with keyboard and accessibility-tree passes, since none alone proves accessibility. **24. Is your site free of spelling and grammar mistakes?** — `/tips/spellcheck-and-proofread/` - *Check:* Read the copy on sampled *rendered* pages for spelling/grammar errors, including the often-missed text: titles, meta descriptions, alt text, button labels, form validation messages (trigger the states), and the 404 page. Confirm `<html lang>` matches the page's actual language (with per-passage lang where languages mix). - *Pass / Fix:* PASS = clean, proofread copy everywhere including meta/UI text. FIX = run a spellchecker with judgment (custom dictionary for brand terms; right-word-wrong-word slips through), read aloud and review sentences in reverse order, get a second reader, watch its/it's-type confusions — and give AI copy a fact check and translations a fluent-speaker review, since their failure mode is meaning, not grammar. - *(Human judgment.)* **30. Does your contact form confirm and protect submissions?** — `/tips/contact-forms-with-confirmation/` - *Check:* Inspect the form markup (do **not** submit it): minimal fields with real `<label>`s and correct input types? Client-side validation plus (per source/owner) server-side validation, a honeypot/time-trap instead of a CAPTCHA, an on-screen success state, and an acknowledgment email? - *Pass / Fix:* PASS = short labeled form, server-side validation, spam defense without CAPTCHA, on-screen + email confirmation. FIX = trim to name/email/message with labels and input types, validate server-side and strip CR/LF from header fields, add a honeypot + time trap, and confirm on screen and by email. **50. Can disabled visitors actually use your site?** — `/tips/web-accessibility-basics/` - *Check:* Test key journeys by **keyboard alone** — all active controls operable, no traps, a **visible focus indicator** (custom styles fine if equally obvious), and DOM/visual/focus order consistent where sequence carries meaning (no positive `tabindex` patches). Check `alt` text fits each image's *purpose* (informative/functional/complex/decorative each differ; empty `alt=""` for decoration), **contrast measured against AA thresholds** (4.5:1 normal text, 3:1 large-scale and non-text essentials), and color never the only signal — form errors identified and described *in text*. Confirm connected `<label>`s with programmatically tied errors, media handled by type (captions for video-with-audio, transcripts for audio-only, audio description where visuals go unspoken), 200% text zoom lossless, and 320px-viewport reflow without clipping or horizontal scroll (2D content excepted). Combine an automated checker with *proficient* keyboard + screen-reader testing across representative templates — automation catches a fraction and false-positives too. - *Pass / Fix:* PASS = keyboard-operable journeys with visible focus, purpose-fit alt, threshold-measured contrast, non-color signals with text errors, labeled forms, type-appropriate media alternatives, zoom/reflow safe. FIX = repair operability and focus, rewrite alt by purpose, fix measured contrast, describe errors in text, connect labels and errors, add captions/transcripts/audio description by media type, and test keyboard + screen reader + automation across journeys — reporting it as barrier removal, not conformance proof. **51. Is your site genuinely usable on phones and touch devices?** — `/tips/mobile-and-touch-usability/` - *Check:* Responsive ≠ usable-with-a-thumb. Confirm a `<meta name="viewport">` that does **not** disable zoom, adequately sized/spaced **tap targets** (24×24 AA floor, 44×44 better), body text readable by default with zoom intact, no **hover-dependent** menus/tooltips (tap/click + keyboard focus must work), and no page-level horizontal scrolling for ordinary content (genuinely 2D content contained in its own scrollable box). Check input types chosen honestly (`email`, `tel`; `number` only for real quantities — digit identifiers get text/tel + `inputmode`), no intrusive arrival interstitials, and any necessary dialog behaving accessibly (focus trapped in, obvious close, focus returned). Test a real phone in portrait and landscape (orientation unlocked), plus zoom, larger text, and the on-screen keyboard over forms. - *Pass / Fix:* PASS = spaced targets, readable text with zoom available, clean reflow with contained 2D content, honest input types, no hover-only controls, accessible-when-necessary dialogs. FIX = enlarge/space tap targets, fix page overflow, correct input-type misuse, make hover-dependent UI tap/keyboard-operable, repair or remove overlays (accessible modal behavior where required), re-enable zoom if disabled, and test real devices both ways up. **52. Does your site have a complete, recognizable icon set?** — `/tips/favicons-and-app-icons/` - *Check:* Inspect `<head>` for a **layered** icon set: an `<link rel="icon">` SVG (`type="image/svg+xml"`, `sizes="any"`), a size-declared PNG, a root `favicon.ico` fallback (a *valid* ICO, not a renamed PNG), a high-resolution square `apple-touch-icon` (Apple-specific — other platforms use manifest/page icons), and a `<meta name="theme-color">` (a suggestion browsers may ignore; light/dark via media queries is a plus). Fetch each icon URL to confirm it serves the intended image with a correct `Content-Type` — the HTML `type` attribute is only a hint. A web app **manifest** is optional — useful where an installed experience helps; if present, proportionate (name, sized icons incl. a maskable one, theme/background). - *Pass / Fix:* PASS = SVG favicon + sized PNG + valid `.ico` + apple-touch-icon + theme-color, all serving correctly; manifest present only where it earns its place. FIX = design one simple high-contrast square mark that reads at 16px (adapting padding/detail per context), provide SVG/sized-PNG/valid-`.ico` + a 180×180-class apple-touch-icon without baked corners, suggest a `theme-color`, fix broken icon responses, and add a manifest with maskable icons only if the installed experience genuinely helps. ### Marketing & Conversion **21. Are you measuring useful actions, not vanity traffic?** — `/tips/read-your-log-files-and-analytics/` - *Check:* Look in the footer/templates for any visible "visitor counter" widget (a red flag — replace with private analytics). Ask whether server logs and a privacy-conscious analytics *configuration* (minimal data, no ad identifiers, no nonessential device storage — verify the deployment, not the vendor label) are reviewed on a schedule, whether **confirmed conversions/inquiries** (not just hits or button clicks) are tracked, and whether top 404s/5xx are acted on. Behind a CDN, note origin logs miss edge-served requests. For a standard Combined format: `awk '$9 == 404 { split($7, u, "?"); print u[1] }' access.log | sort | uniq -c | sort -rn | head` (verify the format first). - *Pass / Fix:* PASS = privacy-conscious analytics measuring confirmed actions, logs reviewed with restricted access/retention, top errors triaged, no visible hit counter. FIX = remove any visible counter, verify the analytics configuration against its legal duties (cookieless ≠ automatically consent-free), track confirmed outcomes reconciled to reality, fix internal links and 301 only genuinely moved URLs (honest 404/410 otherwise), filter bots/staff traffic, treat logs as personal data, and read trends while investigating large single-day swings. - *(Process check — needs owner input.)* **29. Do you follow up on every inquiry?** — `/tips/follow-up-on-every-inquiry/` - *Check:* Human/process. Confirm each accepted inquiry triggers an automatic acknowledgment (generic — no echoed message content, sent from the business's authenticated domain, never with the visitor's address in From) stating a reply window the business actually keeps; submissions route to a shared monitored inbox/ticket tool with a primary owner *and backup*, status tracking and overdue alerts; and there's an internal response-time target. Verify delivery end-to-end with a test submission landing where staff actually look — analytics alone don't prove it. - *Pass / Fix:* PASS = safe acknowledgment after real acceptance, shared system with owner+backup and target, fast personal replies, end-to-end delivery tested. FIX = add a hardened acknowledgment (no echo, fixed From, rate-limited form), route to a shared system with owner/backup/overdue alerts, set and measure a response-time target, follow up once relevantly (no silent newsletter enrollment), and test the form-to-staff path on a schedule. - *(Human/process judgment.)* **31. Do you track your campaigns with UTM tags?** — `/tips/track-campaigns-with-utm/` - *Check:* Process + source check. Confirm campaign links placed outside the site carry consistent lowercase `utm_source/medium/campaign`, that internal links are **not** tagged (events/internal-promotion features instead), that **no personal or sensitive data** sits in UTM values, that manual tags don't fight ad platforms' auto-tagging, and that published links were tested end to end (redirects/shorteners can strip parameters before recording). - *Pass / Fix:* PASS = consistent documented UTM vocabulary on external campaign links only, no PII, auto-tagging respected, links verified to record. FIX = define a lowercase naming list with a campaign log, build links with a URL builder plus the shared vocabulary, keep UTMs off internal links and personal data out of URLs, follow the ad-integration's tagging guidance, and test each link through its full click path before judging channels on recorded visits *and* conversions with cost in mind. - *(Human/process judgment.)* **33. Do you make it easy to share your content?** — `/tips/make-sharing-easy/` - *Check:* Extract Open Graph/Twitter tags — the core properties `og:title`, `og:type`, `og:image` (+ `og:image:alt`, absolute HTTPS URL, landscape ~1200×630 as a common choice), `og:url`, plus description and `twitter:card` — and confirm the page and image are publicly fetchable with metadata in the initial HTML (a bare preview can mean blocked fetch or stale cache, not just missing tags). Check for **lightweight, accessible** share/copy-link controls (accessible names, announced copy result, canonical URL shared — not location.href with params) and feature-detected Web Share — and flag third-party social widgets, especially any contacting the platform before interaction (privacy/consent; see 49). - *Pass / Fix:* PASS = core OG properties + twitter:card with a good fetchable image; lightweight accessible share + copy-link sharing canonical URLs; no pre-interaction widget beacons. FIX = complete the OG set (og:type and image:alt are the usual gaps), verify fetchability and re-scrape cached previews, add plain encoded share links + an announcing copy-link button, feature-detect Web Share with an AbortError-aware fallback, and link to maintained profiles instead of embedding heavy widgets. **34. Do you run your newsletter the right way?** — `/tips/run-a-newsletter-properly/` - *Check:* Human/process. If a newsletter exists, confirm signup collects consent through a clear affirmative action (unticked checkbox is the common form) with distinguishable wording and double opt-in designed to signify agreement; consent evidence logged (wording/time/source/withdrawals); every send carries an accurate sender identity, required disclosures, and a free opt-out honored promptly — with RFC 8058 List-Unsubscribe headers (DKIM-signed) *plus* a visible link for bulk mail; the sending domain authenticates with at least one mechanism aligned to the visible From (see 08); and any soft-opt-in use meets its full conditions under the recipient's national law. Public archives must be stripped of personalized blocks and unsubscribe/tracking URLs. - *Pass / Fix:* PASS = valid recorded consent (or genuine soft opt-in), standards-based free unsubscribe, aligned authentication with monitored DMARC, accessible useful content, compliance owned even with an ESP. FIX = rebuild consent capture and evidence, implement RFC 8058 headers plus the visible link, verify alignment before DMARC enforcement, add processor agreement/privacy-notice coverage for the ESP, clean the archive, and sunset inactive addresses on documented multi-signal rules (not opens alone). - *(Human/process judgment; mark N/A if no newsletter.)* **35. Do you show the people and story behind your business?** — `/tips/show-behind-the-scenes/` - *Check:* Human judgment. Look for real team photos with names/roles where identity matters (licensed stock is fine for the genuinely illustrative — the flag is models posing as staff/customers), authentic workspace/process imagery or short *accessible* video (captions, click-to-play, audited embeds), and a named author/byline with a short bio on articles. Spot-check photo backgrounds for leaked personal/confidential details, and social proof for permissions, incentive disclosure, and dated/defined numbers. - *Pass / Fix:* PASS = real people/workspace shown lawfully, named authorship, credible disclosed social proof. FIX = replace misleading stock with authorized optimized photos, add faces/names/roles on About (with documented permission — staff can decline), make video accessible and performance-tested, link reviews to their source, disclose incentives, date the numbers, and put a real byline + bio on articles. - *E-E-A-T signals:* the same evidence builds Experience, Expertise, Authoritativeness and Trust — a named author with credentials, a clear About/Contact, consistent NAP, HTTPS sitewide, and genuine mentions. Higher bar for "Your Money or Your Life" topics. Treat E-E-A-T as **quality guidance, not a direct ranking dial**. (Verifiable proof itself is check 54.) - *(Human judgment.)* **36. Could your site become the go-to resource in your field?** — `/tips/become-a-reference-resource/` - *Check:* Human/strategy. Assess whether the site publishes genuinely useful content (guides, FAQs, explainers, original assets with stated sources/assumptions) written answer-first with descriptive headings, connected through a hub with crawlable descriptive links (a category label alone expresses nothing), technically discoverable (indexable, linked, in the sitemap), and updated on substance rather than date-bumped. For consequential topics, look for sources and stated limits, not just experience. - *Pass / Fix:* PASS = a maintained, well-organized, answer-first, discoverable content hub with real internal links and honest sourcing. FIX = turn distinct customer questions into solid pages (merging near-duplicates), write answer-first with descriptive headings, build the hub from crawlable contextual links, add original assets with methodology and accessibility, verify indexability, and refresh pages when facts change — never cosmetically. - *(Human/strategy judgment.)* **37. Does your checkout earn the customer's trust?** — `/tips/build-trust-in-checkout/` *(conditional: if you sell online)* - *Check:* **Only for sites that sell** — otherwise N/A. Confirm HTTPS across the whole site with no mixed content, card handling via a hosted/hosted-field integration where card data goes directly to a validated provider (the integration, not the brand, sets PCI scope), cost estimates early with the exact total and essential terms directly before the order, a final button that clearly means pay, guest checkout, accessible forms (labels, keyboard, announced errors), and checkout responses not shared-cacheable (`Cache-Control: private`/`no-store`). Do **not** complete a purchase. - *Pass / Fix:* PASS = whole-site HTTPS, properly scoped hosted payments, exact total before ordering with EU order-page disclosures, guest checkout, truthful reassurances, accessible forms, server-side payment verification before fulfillment. FIX = enforce site-wide HTTPS with private/no-store on checkout, integrate payments so card data bypasses your systems (validation confirmed with the acquirer), surface estimates early and exact totals pre-order with a pay-obligation button label, offer familiar/local payment + guest checkout, fix form accessibility, and confirm on screen + authenticated email only after server-side verification. - *(Mark N/A for non-transactional sites.)* **39. Do you have a real local presence online?** — `/tips/establish-local-presence/` - *Check:* Process + NAP consistency. Confirm a claimed, verified Business Profile with the *relevant* fields accurate (eligibility needs in-person customer contact; service-area businesses keep the address off the public profile — flag a published private home address), materially consistent NAP across site/profiles/directories (substance, not punctuation), `LocalBusiness` JSON-LD only where a genuine customer-facing location exists, neutral review collection (no incentives/filtering; replies leak no customer details), and an answered number with an appropriate area code used only for genuinely served areas. - *Pass / Fix:* PASS = verified accurate profile, materially consistent details with private addresses protected, appropriate schema, honest review practice, answered suitable number. FIX = claim/verify the profile and correct relevant fields, update hours on the profile itself (website edits don't reliably sync), protect private addresses with service-area setup, scope schema to real locations, fix review solicitation to neutral-and-honest, and align numbers with genuinely served areas (call recording lawful if used). - *(Mostly relevant to local businesses; mark N/A if genuinely non-local.)* **53. Does every important page offer one clear next action?** — `/tips/one-clear-next-action/` - *Check:* On each key page, identify the single most valuable action (call, book, buy, quote, subscribe). Confirm a clearly emphasized, contrast-verified, result-naming CTA — not "Click here", not many equal-weight buttons obscuring the intended step (hub/comparison pages may legitimately carry several prominent options). Check semantics: a link when it navigates, a button when it acts; visible focus state; accessible name matching the label. Confirm it appears early enough to find at common sizes and zoom (no fixed 'fold'), repeats low on long pages performing the same action, and that secondary options are quieter yet still legible. - *Pass / Fix:* PASS = one obvious, accessible primary action per key marketing page, secondary actions subordinate, early placement tested across viewports. FIX = pick one primary action per page, present it with clear emphasis and honest result-naming labels in the right element, verify contrast and focus states, place early and repeat low, demote (without dimming into illegibility) the rest, and strip forms to essential well-labeled fields with only keepable response promises. - *(Partly human judgment.)* **54. Can visitors verify your claims?** — `/tips/let-visitors-verify-claims/` - *Check:* Scan copy for generic, unverifiable adjectives ("quality service", "best value") and look for **traceable, checkable proof** instead: genuine named reviews (permissioned, incentives disclosed), case studies with baseline/scope/timeframe rather than bare numbers, *current* credentials scoped honestly and linked to the issuer's verification record (badges with accessible names), pricing with inclusions and what moves it (no lowball "from" figures), guarantee terms stated as voluntary extras distinct from statutory rights, current original photos, and the legally required identity details with registered-vs-customer addresses distinguished. Evidence placed **near decision points** with fuller archives findable. Fake/commissioned reviews and misrepresented feedback are prohibited practices in EU consumer marketing. - *Pass / Fix:* PASS = vague claims backed by traceable, current, lawfully published proof near decisions; genuine disclosed reviews only. FIX = replace generic adjectives with substantiated evidence (figure + method/baseline, permitted disclosed review, credential + verification link), fix stale or overscoped credentials, scope the pricing honestly, separate guarantees from statutory rights, handle names/photos as personal data, and move the strongest proof next to prices and CTAs. - *(Partly human judgment.)* --- ## Scoring & report format **Statuses** - **PASS** — verified in place and correct. - **CHECK** — needs review: the automated signal was ambiguous, the item is **operational** and can only be confirmed with the owner (backups, monitoring, patching, follow-up), source access is needed, or it's a human-judgment call. Flag it; don't guess. - **FIX** — a clear problem with a concrete remedy. - **N/A** — does not apply (e.g. hreflang on a single-language site, checkout on a brochure site). Excluded from the score. **Score** — count only *applicable* checks (exclude N/A). Treat CHECK items as not-yet-passing. ``` score = round(100 * PASS_count / applicable_checks) ``` Report the score with the counts, e.g. `Score: 74/100 (34 PASS, 6 FIX, 8 CHECK, 2 N/A)`. ### Report template ```markdown # Website audit — <domain> **Score: <n>/100** — <PASS> pass · <FIX> to fix · <CHECK> to review · <N/A> N/A Audited <date> against the 50 Site Advice checks. Evidence: homepage + <k> inner pages, response headers, DNS (DoH), robots.txt/sitemap, 404 test, favicon/manifest, form markup. ## Top 3 things to fix first 1. **<check no. + title>** — <why it matters most> → <the fix> 2. **<check no. + title>** — <why> → <the fix> 3. **<check no. + title>** — <why> → <the fix> ## Results by area ### Domains & DNS | # | Check | Status | Note | Fix | |---|-------|--------|------|-----| | 01 | Memorable domain name | PASS | short, brandable, variants secured | — | | 02 | Registrar security / renewal / DNSSEC | FIX | DNSSEC not signed (no DS record) | enable DNSSEC, confirm DS at registry | | 41 | Who controls your accounts | CHECK | operational — confirm ownership/MFA/recovery | verify business owns accounts; enable MFA | ### Hosting & Infrastructure _(rows for 04, 06, 18, 42, 43)_ ### Security, Privacy & Compliance _(rows for 07, 12, 15, 44, 45, 46)_ ### Email & Deliverability _(rows for 08, 09, 11)_ ### SEO & Findability _(rows for 03, 13, 22, 28, 38, 47, 40)_ ### Performance _(rows for 25, 26, 48, 49)_ ### Design & UX _(rows for 10, 14, 16, 17, 19, 20, 24, 30, 50, 51, 52)_ ### Marketing & Conversion _(rows for 21, 29, 31, 33, 34, 35, 36, 37, 39, 53, 54)_ ``` Prioritize the "Top 3" by impact and effort: security/deliverability/SEO regressions and anything that makes the site unreachable or untrustworthy come before cosmetic wins. Keep each note to one line and each fix actionable. Be explicit that operational checks (41, 42, 43, 45, and the device-testing part of 48) are reported as CHECK because they can't be proven by fetching — the owner must confirm them. --- ## Further reading - **All 50 tips, in full:** https://www.siteadvice.be/tips/ — the complete explanations behind every check above. - **The AI chapter:** https://www.siteadvice.be/category/ai/ — using AI on your site without hurting quality, accuracy, or trust (relevant to checks 24, 35, 36, 54). - **Glossary:** https://www.siteadvice.be/glossary/ — plain-language definitions of the terms used across these checks. - **E-E-A-T: why Google trusts some sites more** — https://www.siteadvice.be/articles/e-e-a-t-why-google-trusts-some-sites/ — Experience, Expertise, Authoritativeness, Trust as quality guidance (not a ranking dial), and the signals a small business can show (relevant to checks 07, 35, 36, 39, 54). - **How to get cited in AI answers** — https://www.siteadvice.be/articles/get-cited-in-ai-answers/ — GEO/AEO in plain terms: answer-first content, question-shaped headings, FAQ + structured data, being crawlable and trustworthy (relevant to the SEO section and checks 28, 36). - **Core Web Vitals explained** — https://www.siteadvice.be/articles/core-web-vitals-explained/ — LCP, CLS, and INP, their "good" thresholds, how to measure them, and the usual fixes (relevant to checks 25, 26, 48). - **Internal linking for topical authority** — https://www.siteadvice.be/articles/internal-linking-for-topical-authority/ — descriptive anchors, hubs and clusters, and avoiding orphans and over-linking (relevant to checks 22, 28, 36). - **Search intent and thin content** — https://www.siteadvice.be/articles/search-intent-and-thin-content/ — matching each page to intent, and pruning/merging/improving thin pages (relevant to checks 28, 36). - **Should you put your site behind Cloudflare?** — https://www.siteadvice.be/articles/should-you-use-cloudflare/ — what a CDN/proxy actually does for a small site, and the caching, visitor-IP, and firewall traps to avoid (relevant to checks 06, 07, 25, 44). - **404 error messages explained** — https://www.siteadvice.be/articles/404-error-messages-explained/ — soft 404s, 410 Gone, and handling removed pages after a migration (relevant to checks 14, 47). --- Full explanations for every check live at https://www.siteadvice.be/tips/ . Skill © EUREGIO.NET AG, based on the website optimization tips by Jochen Savelberg. Free to use.