Put a website live properly.

The domain is registered in your (or your company’s) name with auto-renew. The bare domain and www both reach the site, and one permanently redirects to the other.

Verify: Open http://, https://, with and without www: everything lands on the same address in a single redirect.

Evidence: Domain holder, expiry date and the result of the four tests.

Common failure: Domain registered in the agency’s or freelancer’s name, lost when the collaboration ends.

Every page and resource is served over HTTPS, HTTP redirects to HTTPS, and the certificate renews itself. Add HSTS once HTTPS is confirmed on every subdomain concerned.

Verify: No mixed-content warning in the browser console; certificate expiry and auto-renewal checked.

Evidence: Screenshot of the certificate and of the HTTP → HTTPS redirect.

MDN — Strict-Transport-Security ↗ · reviewed 2026-10-23

Production has its own settings; previews or staging are not indexed and do not send real emails. You keep administrator access to the hosting account.

Verify: Open a preview URL: it carries noindex or is protected; you can log into the host yourself.

Evidence: List of environments and who can access them.

Forms, confirmations and newsletters are sent from an authenticated domain, otherwise they land in spam. Google’s sender guidelines require at least SPF or DKIM, and more for bulk senders.

Verify: Submit a form to Gmail and Outlook; in “Show original”, SPF and DKIM read “PASS”.

Evidence: Screenshot of the authentication headers.

Google Workspace Admin Help — Email sender guidelines ↗ · reviewed 2026-10-23

Private API keys, passwords and tokens stay server-side, in per-environment variables — never in the JavaScript sent to the browser or in Git history. An exposed key must be revoked, not just deleted.

Verify: Search for known key prefixes in the repository, its history and the source served to the browser.

Evidence: Search result and list of production environment variables.

OWASP — Secrets Management Cheat Sheet ↗ · reviewed 2026-10-23

Server-side validation, rate limiting, a honeypot field or captcha when needed: an open form quickly becomes a source of spam or email abuse.

Verify: Submit the form ten times in a minute and once with invalid data: the server refuses cleanly.

Evidence: Test result.

An outdated CMS or plugin is a frequent way in. Administrator accounts have unique passwords and two-factor authentication.

Verify: CMS dashboard: no pending security update; two-factor active on every admin account.

Evidence: Dashboard screenshot and list of admin accounts.

OWASP — Top 10 ↗ · reviewed 2026-10-23

Content-Security-Policy where realistic, X-Content-Type-Options, framing protection (frame-ancestors) and a referrer policy.

Verify: Inspect the home page response headers in the browser tools.

Evidence: Screenshot of the headers.

OWASP — Top 10 ↗ · reviewed 2026-10-23

Loading (LCP), responsiveness (INP) and visual stability (CLS) measured on mobile. Field data beats a one-off lab test when it exists.

Verify: Measure the main pages on mobile (PageSpeed Insights or Lighthouse) and record the results.

Evidence: Dated results per page.

Google Search Central — Core Web Vitals ↗ · reviewed 2026-10-23

Images at the right size and in modern formats, lazy-loaded below the fold, a limited set of fonts preloaded where needed.

Verify: Network tab: no multi-megabyte image on the main pages.

Evidence: Total weight of the main pages.

web.dev — Web Vitals ↗ · reviewed 2026-10-23

No horizontal scrolling, readable text, large enough tap targets, forms usable with the phone keyboard.

Verify: Go through the site on an iPhone and an Android phone, on a mobile network.

Evidence: Devices tested and issues found.

Full keyboard navigation with visible focus, sufficient contrast, meaningful alt text, labelled form fields, a heading hierarchy. WCAG 2.2 level AA is a good target.

Verify: Go through the site using only the keyboard; run an automated audit tool, then check by hand what it cannot see.

Evidence: Audit and keyboard test results.

W3C — Web Content Accessibility Guidelines (WCAG) 2.2 ↗ · reviewed 2026-10-23

The lang attribute matches each page’s language, and the language switch works with a keyboard and a screen reader.

Verify: Inspect <html lang> on one page per language.

Evidence: Values recorded.

W3C — Web Content Accessibility Guidelines (WCAG) 2.2 ↗ · reviewed 2026-10-23

Forms, analytics, newsletter, hosting: describe which data you process, why, with which providers, for how long, and how people can exercise their rights. Check what applies to you: the Swiss FADP, and the GDPR if you target people in the EU. This is not legal advice.

Verify: List every tool that receives data (forms, analytics, emailing) and check it appears in the notice.

Evidence: Notice URL and list of providers.

Fedlex — Swiss Federal Act on Data Protection (FADP) ↗ · reviewed 2026-10-23

If you target the EU, non-essential trackers usually require prior consent. A banner only makes sense if scripts actually wait for the answer. Cookieless analytics can simplify things. Check what applies to you.

Verify: In a private window, before answering the banner, the Network tab shows no call to a tracking tool.

Evidence: Screenshot of the Network tab before consent.

EUR-Lex — General Data Protection Regulation (GDPR) ↗ · reviewed 2026-10-23

A legal notice or “Impressum” page with the operator’s name and a contact address. Obligations vary by country and activity (online commerce in particular): check what applies to you.

Verify: The page is linked from the footer of every page.

Evidence: Page URL.

FDPIC — Federal Data Protection and Information Commissioner ↗ · reviewed 2026-10-23

robots.txt blocks no important page, no noindex left over from staging remains on public pages, the sitemap lists canonical URLs, and each page declares the right canonical URL. Private, test or result pages carry noindex. None of this guarantees rankings.

Verify: Read /robots.txt and /sitemap.xml in production; inspect the source of each page template (robots, canonical); use Search Console URL Inspection on key pages.

Evidence: robots.txt content, sitemap URL and URL Inspection result.

Common failure: The staging noindex ships to production: the site disappears from results.

Google Search Central — Block indexing with noindex ↗ · reviewed 2026-10-23

Each page has a title that describes its content, a useful meta description, a single main heading (H1) and a share image.

Verify: Record the title and description of each main page: no duplicates.

Evidence: Table of titles and descriptions.

Google Search Central — Title links ↗ · reviewed 2026-10-23

The property is verified, the sitemap submitted, and the indexing report checked a few days after launch.

Verify: Search Console → Sitemaps: status “Success”.

Evidence: Screenshot of the sitemap status.

Search Console Help — Add a website property ↗ · reviewed 2026-10-23

Every old URL that receives traffic or links redirects (301/308) to its equivalent, without redirect chains; internal links point directly to the new URLs.

Verify: Test the list of old URLs (Search Console export or old sitemap): each answers with a single redirect to a 200 page.

Evidence: Table of old URL → new URL → response code.

Common failure: Old pages returning 404 after the redesign: organic traffic lost.

Google Search Central — Site moves with URL changes ↗ · reviewed 2026-10-23

Each language has its own URLs, and versions reference each other with hreflang, without announcing a language that does not exist.

Verify: Inspect a page’s hreflang tags and check each listed URL answers 200.

Evidence: Tags recorded.

Google Search Central — Localized versions of your pages ↗ · reviewed 2026-10-23

Organization, breadcrumbs, articles, FAQs actually on the page… only what the page shows, validated without errors.

Verify: Run the page templates through the Rich Results Test.

Evidence: Test result.

Google — Rich Results Test ↗ · reviewed 2026-10-23

No placeholder text or public test page, no broken internal link, and a 404 page that helps people find their way.

Verify: Run a link checker on the production site; open a non-existent URL.

Evidence: Link report and screenshot of the 404 page.

A contact path is visible from every page. The form actually delivers the message, the person gets a confirmation, and someone reads the inbox.

Verify: Send a real message from a phone and check delivery and the confirmation.

Evidence: Message received, with the date.

Navigation, main call to action, forms, language switch, booking or ordering: tested on Safari, Chrome and Firefox, on mobile and desktop, on the real domain.

Verify: Repeat each journey on the production domain after the last deployment.

Evidence: Dated list of journeys and browsers tested.

Payment goes through a recognised provider, a real production transaction succeeds (then is refunded), the confirmation arrives, and terms of sale and refund are published.

Verify: Real purchase with your card, confirmation received, refund.

Evidence: Transaction and refund reference.

The CMS content, its database and files are backed up automatically, and you know how to restore. A static site versioned in Git already is.

Verify: Restore a backup to a test environment.

Evidence: Date of the last successful restore.

You know how to put the previous version back online if a deployment breaks something.

Verify: Roll back on a preview, or write down your host’s exact procedure.

Evidence: Procedure written down.

Monitoring alerts you if the site goes down; form delivery failures are visible.

Verify: Take a test page down: the alert arrives.

Evidence: Chosen tool and person alerted.

Define the action that matters (message sent, booking) and measure it, without sending email, name or free text to the analytics tool.

Verify: Complete the action: the event appears in the tool, without personal data.

Evidence: Event name and screenshot.