Guides

Professional website technical checklist for 2026: what really needs testing

A website is not ready merely because its homepage opens and the layout looks right. It is ready when server, URLs, content, functions, email, security and measurement still tell the same story outside the preview.

The short answer

Professional verification covers the whole journey: HTTP responses and redirects, indexing, metadata, images, semantic HTML, keyboard use, JavaScript, forms, email delivery, security, analytics and checks on the published website. One score or isolated tool cannot prove that the complete system works.

Gian Luca Partengo
Web developer since 1995 · Updated 23 September 2026

When is a website genuinely ready from a technical perspective?

The answer is not the absence of visible errors. Four conditions must remain true together.

Availability

The correct resource responds in the correct way

Pages, assets and endpoints return the intended status, use HTTPS and do not depend on redirect chains or fragile configuration.

Understanding

Content and relationships can be read

Headings, links, metadata, canonical URLs and structured data describe the same page without late or contradictory signals.

Use

Functions withstand real conditions

Menus, forms, media and interactions work with keyboard, touch, zoom, different viewports, errors and less-than-ideal connections.

Observability

The project can be checked over time

Errors, visits, search, email, renewals and changes have tools, ownership and baselines that make change verifiable.

Which HTTP responses, server settings and TLS checks matter?

Browsers, crawlers and integrations receive a network response first. If it is wrong, what appears on screen can be misleading.

01

200 only for genuinely available resources

A valid page returns 200. Missing content that shows an error message while remaining 200 creates a soft 404 and communicates a false state.

02

301 or 308 for permanent moves

The redirect leads directly to the canonical destination. Chains, loops and unnecessary hops add latency and ambiguity.

03

404 or 410 for missing resources

An error page can help visitors continue, but it must preserve the correct status rather than turning every missing URL into the homepage.

04

Observable and diagnosable 5xx errors

A server error should not be disguised as success. Technical logs, request identifiers and recovery procedures should reconstruct the incident without exposing personal data.

05

Consistent HTTPS throughout the journey

Certificate, renewal, HTTP redirect, mixed resources and alternative hostnames must be checked together: the padlock does not certify the rest of the site.

06

Headers aligned with content and risk

Content-Type, caching, compression and security headers should describe and protect the response without breaking legitimate functions.

Repeat the check on final resources, not only the homepage: pages, images, files, endpoints and language variants can behave differently.

How can URLs, redirects and error pages preserve the right signals?

A stable address connects navigation, campaigns, search engines, analytics and sharing. Changing it requires one editorial and technical decision.

Version

One representative destination

Protocol, host, trailing slash, case and parameters should converge consistently on the chosen version without creating accidental duplicates.

Move

Every old URL reaches a real equivalent

A redirect preserves intent. Sending every removed page to the homepage confuses people and crawlers and does not replace a migration map.

Variants

Filters and parameters do not multiply content

Sorting, tracking and query strings need governance so they do not create infinite paths, contradictory canonicals or unmanageable reports.

Useful error

A 404 provides direction without pretending the page exists

A message, search or relevant links help the visitor, while the HTTP status preserves the technical truth that the resource is missing.

The practical rule

Every public URL needs a documented outcome: it remains, moves, is replaced or ends with an accurate missing-resource status.

How can pages be discoverable without confusing crawling and indexing?

robots.txt, sitemaps and canonical tags provide different signals. None of them alone guarantees that a page will be indexed.

01

Real HTML links and internal paths

Important pages should be reachable through links with href, meaningful text and context, not only through JavaScript events or a sitemap.

02

A sitemap containing canonical URLs only

The sitemap lists public, indexable and current pages. Redirects, 404s, internal results and duplicate variants do not belong there.

03

robots.txt governs access, not removal

Blocking crawling is not the same as requesting deindexing. Directives, robots metadata and page accessibility must be designed consciously.

04

Canonical present in the initial HTML

One absolute and consistent canonical consolidates variants. Changing it late with JavaScript or declaring several creates avoidable signals.

05

Reciprocal languages and genuinely translated URLs

Each language version points to correct alternatives, including x-default where useful, while keeping self-referencing canonicals and localised content.

06

Indexing checked with official tools

Search absence is not diagnosed by checking a results page once. It requires URL inspection, sitemap, status, selected canonical and processing time.

To separate discovery, crawling, rendering and indexing, read the guide to why a website does not appear on Google.

How should titles, descriptions, headings and structured data be checked?

Metadata cannot repair a weak page. It should accurately summarise visible content that matches the URL’s intent.

Identity

A unique, descriptive and specific title

The title distinguishes the page and anticipates its subject without keyword piles, repeated formulas or promises absent from the content.

Summary

A description aligned with the page

The description helps explain the result but may be rewritten by the search engine. Treat it as a useful summary, not a guaranteed ranking lever.

Structure

Headings that organise rather than decorate

A clear H1 and ordered sections expose hierarchy. The level follows content structure, not the desired visual size.

Data

Schema aligned with what is visible

Types, properties, URLs, dates, authors and offers must be real, connected and present on the page. Fabricated or duplicated data reduces trust.

What should be checked for images, formats and social previews?

The same image can play different roles in content, cards and sharing. Every role needs suitable dimensions, crop and metadata.

01

Sources suited to the viewport

srcset, sizes or picture allow the browser to select the right resource instead of always downloading the largest original.

02

Format chosen for the content

AVIF, WebP, JPEG, PNG and SVG have different strengths. The choice considers support, transparency, detail, compression and destination.

03

Compression judged on the result

There is no universal weight: inspect perceived quality, rendered size and transfer cost, avoiding originals disproportionate to their use.

04

Space reserved before loading

Width, height or aspect-ratio keep text and controls from shifting while the image arrives.

05

Useful alternative text or intentionally empty alt

Informative images need contextual descriptions; decorative images need empty alt. A filename is not a description.

06

Open Graph checked on the real page

Title, description, URL, image and social alt must be absolute and coherent. A missing or wrong cover damages preview and recognition.

For delivery, priority and resource cost, read why a website becomes slow.

Why are semantic HTML and accessibility technical checks?

Native structure communicates roles and relationships to browsers, keyboards, assistive technology and crawlers. Rebuilding it with divs and scripts adds risk.

Structure

Native elements for content and actions

Heading, nav, main, button, a, label and form expose expected meaning and behaviour. ARIA supplements correct HTML; it does not replace it.

Keyboard

Every function remains reachable and visible

Focus order, opening, closing, menus, dialogs and actions must work without a pointer and without traps.

Understanding

Names, instructions and errors are associated

Controls, fields and icons have accessible names; errors explain what to correct and focus moves to the relevant summary.

States

Hover is not the only feedback

Focus, selection, loading, error, success and disabled states remain perceivable without relying solely on colour, animation or mouse.

For duties, scope and WCAG testing, read the website accessibility guide.

How can JavaScript, responsive behaviour and performance be tested beyond a demo?

The site needs to be exercised with real content, errors and devices. Working in the developer’s browser does not prove robustness.

01

Essential content in the initial HTML

Titles, body copy, links and key signals should be available without delegating all understanding to later rendering.

02

A clean console on tested journeys

Exceptions, missing resources and rejected promises can reveal broken functions even when the visual surface looks intact.

03

Failures handled without making the page unusable

If a script or external service fails, essential content and actions should remain available or show a comprehensible error.

04

Layout tested between breakpoints

Phone and desktop are not enough: intermediate widths, zoom, orientation and long content expose overflow and incomplete rows.

05

Motion can be controlled and reduced

Autoplay, reveals and transitions should not hide information, block interaction or ignore reduced-motion preferences.

06

Performance read as a journey

Server, cache, fonts, images, scripts and third parties contribute together. Synthetic measurement helps, but it must connect to causes and real experience.

How should forms and email be tested from input to receipt?

A visual confirmation is not enough: separate validation, abuse protection, transport acceptance and mailbox delivery.

Input

Validation in both browser and server

The client helps the user; the server enforces real limits, formats and rules. The server does not trust hidden fields or JavaScript.

Abuse

Spam and repeated submissions are limited

Honeypots, timing, tokens, rate limits and contextual controls combine without turning the form into a permanent obstacle.

Transport

Success only after the main notification

The page confirms submission when transport accepts the main message. The autoreply follows, and its failure does not cancel an accepted notification.

Receipt

Inbox, spam, Reply-To and authentication are tested

SPF, DKIM, DMARC, original headers and an external mailbox help verify the journey that code alone cannot certify.

Accepted does not mean delivered

A successful send function means the transport accepted the message; it does not guarantee that the message reached the mailbox or inbox.

For the complete journey, read the guide to forms, spam, security and email.

Which security and maintenance checks are essential?

No website is automatically secure. The work reduces surface area, privileges and consequences while maintaining update and recovery procedures.

Browser

Security headers calibrated to the site

CSP, HSTS, framing, referrer and feature policies must fit actual behaviour rather than being copied in ways that break resources or create false confidence.

Application

Inputs, outputs and privileges are controlled

Validation, escaping, tokens, authorisation, separated secrets and least privilege protect boundaries where data enters or actions begin.

Components

Every dependency has a purpose and owner

Libraries, plugins, APIs and third-party services need inventory, updates, licences, access control and a plan for change or failure.

Continuity

Backups and recovery are tested

An untested backup is a hope. Copies, frequency, retention, access and recovery testing must match the project’s risk.

For attack surface, updates and recovery, read the website security guide.

How can a website be monitored without collecting unnecessary data?

Measurement does not mean installing every available tag. It means defining questions, events, ownership and limits consistent with privacy and goals.

Use

Analytics tied to real decisions

Landing pages, sources and conversions help only when naming, filters and goals remain stable and understandable.

Search

Search Console separates presence from traffic

Sitemaps, indexing, impressions, queries and pages are read over time without treating a lack of data as a technical error.

Functions

Errors and critical journeys have useful signals

Minimised logs, periodic checks and proportionate alerts should reveal failures, expiries and regressions without recording unnecessary personal data.

Comparison

A baseline comes before judgment

URL, date, environment, device and result create a comparable baseline. Without context, one number cannot explain what changed.

Which checklist should be used before launching a website?

Pre-launch work removes known errors before cache, DNS, crawlers, campaigns and visitors make them more expensive to correct.

01
Map pages, URLs and redirects
Confirm new, old and removed pages, languages, HTTP status and the destination of every affected URL.
02
Review content and metadata together
Title, description, H1, links, facts, prices, contacts, schema and social preview must describe the approved version.
03
Exercise viewports with real content
Check phone, tablet, desktop, zoom, orientation, longer languages, missing images and realistic amounts of text.
04
Complete journeys with the keyboard
Menus, dialogs, forms and calls to action need visible focus, logical order, closing controls and clear feedback.
05
Simulate form success and failure
Check validation, safe field retention, limits, notification, autoreply, Reply-To and behaviour when transport refuses a message.
06
Validate canonical, hreflang and schema
URLs should be absolute, reciprocal and consistent with language, breadcrumb, visible content and sitemap.
07
Remove exposed debugging, access and secrets
Disable temporary tools, limit permissions, check headers and ensure configurations and backups cannot be reached publicly.
08
Record a local or staging baseline
Keep tests, viewports, pages and conditions so public verification can distinguish regression from an environmental difference.

Which checks need repeating after launch?

Hosting, cache, DNS, server rules and external services belong to the real result. Verification finishes on the public site, not the uploaded file.

01
Check public status and destinations
Test representative pages, redirects, 404s, HTTPS and language variants from outside the hosting environment.
02
Check cache and assets actually served
HTML, CSS, JavaScript, fonts and images should match the published version without mixtures of old and new files.
03
Send a real test to an external mailbox
Check notification, autoreply, Reply-To, destination folder and original headers without turning the test into a commercial event.
04
Read robots, sitemap and canonical again
Make sure the public domain, final URLs and reachable resources match what was intended locally.
05
Confirm analytics without personal data
Page views and authorised events should arrive once, with correct names and no properties that expose field content.
06
Repeat journeys and console checks publicly
CSP, CORS, cache and external origins can create errors absent from the local environment.
07
Confirm backup and rollback ability
The recovery point should precede the change and the procedure must work without improvisation during an incident.
08
Record outcome, date and owner
A traceable closure shows what was verified, what still needs observation and who acts if something changes.

Who maintains the checklist after launch?

A technical review is not a document to archive. Every change to content, dependencies, server or services can alter the result.

Working method

Every check needs an owner and a moment

In my method, development, content and infrastructure are verified as one system. Responsibility is not delegated to a plugin or an automated score.

Maintenance follows actual risk and change: it does not mean repeating every audit every day, but knowing which checks to repeat and why.

Before every significant publication
After deployments, cache and server changes
When forms, email or third parties change
After dependency or browser updates
When data reveals a regression
At defined renewal dates for domains, certificates and backups

Which primary sources support this checklist?

The guide summarises requirements and practices from official documentation. Every project needs to adapt them to its architecture, risk and applicable law.

Google Search Central — Technical requirements
Minimum requirements for a page to be eligible for Google Search, including the HTTP 200 response.

Open source
Google Search Central — Redirects and Search
Permanent and temporary redirects and the role of server-side redirects in canonicalisation.

Open source
Google Search Central — Canonicalisation
Signals used to select a representative URL and the relationship between canonical tags, redirects and sitemaps.

Open source
Google Search Central — JavaScript SEO
Crawling, rendering, links, HTTP status, titles, descriptions and canonical tags on JavaScript websites.

Open source
Google Search Central — Developer guide
Crawlable links, sitemaps, unique URLs and basic checks that make a website understandable to Search.

Open source
W3C — Web Content Accessibility Guidelines 2.2
Testable criteria for perceivable content, operable interfaces, understanding and robustness.

Open source
W3C WAI — Forms Tutorial
Labels, groups, instructions, errors and practices for understandable, accessible forms.

Open source
OWASP — Secure Headers Project
Official documentation and tools for HTTP headers that reduce avoidable browser vulnerabilities.

Open source
PHP Manual — mail()
A true return value means acceptance for delivery, not actual arrival in the recipient’s mailbox.

Open source
W3C WAI — Easy Checks
Preliminary checks for headings, images, contrast, zoom, keyboard use, forms and structure.

Open source

Sources checked on 23 September 2026. Specifications, browsers, tools and laws may change: professional verification always uses current documentation.

What are the most common questions about a technical checklist?

Direct answers for using the checklist without turning it into an automatic quality promise.

Is there one tool that checks the whole website?

No. HTTP responses, rendering, accessibility, email, security, analytics and content require different tools and tests. An automated report is useful within its scope but cannot replace end-to-end testing.

If the homepage works, is the website technically sound?

No. Internal pages, 404s, redirects, languages, forms, images, files and conversion journeys can follow different rules. Test a representative sample and complete all critical journeys.

Can robots.txt remove a page from Google?

robots.txt limits crawling; it is not an index-removal tool. A blocked URL may still be known. Deindexing, access and crawling are separate decisions.

Does a sitemap guarantee indexing?

No. A sitemap suggests URLs and updates, while the engine assesses accessibility, HTTP status, canonical, content and other signals. It should contain only canonical URLs intended for indexing.

Does a successful email send function guarantee receipt?

No. At most, it proves transport accepted the message. Delivery, authentication, filtering and destination folder require a real send and, where possible, inspection of original headers.

How many pages should be checked?

It depends on the architecture. Test every distinct template and journey, plus the homepage, main content, forms, 404s, redirects, multilingual pages and error states. Dynamic sites require real-data samples.

Does this checklist replace a WCAG assessment?

No. It includes useful structural checks, but a conformance assessment requires a scope, applicable criteria, manual and assistive-technology testing, documentation and maintenance processes.

When should the checks be repeated?

After material changes to code, content, dependencies, server, DNS, cache, forms, email or third-party services, and on a schedule proportionate to project risk and expiry dates.

Is the free Analyzer a complete audit?

No. It gives an initial view of mobile performance, a possible WordPress footprint, indicative page weight and selected security headers. It does not test the complete checklist in this guide.

Who owns problems after launch?

It depends on contract, ownership and management. Responsibility for hosting, code, content, domains, email, accounts, backups and third-party services should be assigned before launch, not during an incident.