Start with critical journeys, not a giant scan
Choose five to ten URLs and define the expected result for each: a confirmation page, receipt, CRM record, or provider handoff. Include public pages and actions that create revenue, trust, support demand, or a legal obligation. Test as a visitor in a signed-out window and on a phone.
If a third party owns a critical step, map the handoff and support contact. You can test your transition, but cannot certify that provider. Classify findings as blocker, material degradation, or improvement so cosmetic work does not bury a broken journey.
Cover routes that create revenue, trust, support demand, or legal obligations.
Every material finding needs a named owner and a target date.
Check accessible use as well as appearance
Accessibility means people can perceive and operate the site with different input methods and assistive technology. On selected pages, use Tab through navigation, menus, controls, and forms. Check visible keyboard focus, mouse-free operation of essential controls, and a route to main content. W3C’s Easy Checks identifies keyboard focus and a skip link as useful first-review items.
Inspect meaningful image text, page titles, headings, contrast, zoom behaviour, media alternatives where needed, form labels, required fields, and understandable errors. Send a non-sensitive test submission. This is not a compliance audit: W3C cautions that pages can pass quick checks while still containing significant barriers. Use qualified evaluation for higher-risk work, redesigns, or known issues.
Test labels, instructions, errors, and the actual path to confirmation.
Alternative text should communicate an image’s purpose; headings should organize the page.
Review findability without promising rankings
SEO helps search engines understand content and helps people decide whether to visit from search. For each priority page, read the title, main heading, opening copy, URL, and internal links as a newcomer. They should state purpose and lead to useful next steps. Google recommends descriptive URLs, useful content, and descriptive link text.
If you use Google Search Console, inspect key URLs after a material release. Google says URL Inspection can help check how its crawler sees a page and whether it can access important resources. Correct accidental blocking, broken internal links, or unclear paths, then allow recrawling time. Google does not guarantee indexing or ranking.
Open internal links while signed out and log 404 pages, loops, and irrelevant destinations.
Observe delivery where visitors feel it
Delivery includes server response, images, fonts, scripts, caching, and third parties. Run a browser performance check on priority pages, then repeat the core task on a real phone. Note late primary content, slow controls, layout jumps, failed resources, or banners that block a task. Core Web Vitals are a web.dev user-experience framework; use measurements to focus investigation, not replace journey testing.
Review new tags, widgets, embeds, fonts, and image changes with the implementer. HTTP caches reuse prior responses. MDN explains that Cache-Control communicates caching instructions and cached responses can be fresh or stale. After a release, compare ordinary and fresh browser sessions, then have the technical owner examine headers and CDN rules. Avoid blanket cache changes without understanding privacy and release effects.
Record whether primary content appears, the page stays stable, and essential controls respond.
MDN notes that a cookie alone does not make a response private; ask a technical owner to review personalized caching.
Confirm the security baseline and protect payment changes
An owner check can find visible gaps; it is not a penetration test. Open the public site over HTTPS and try HTTP. OWASP recommends TLS for all pages and describes redirecting public HTTP traffic to HTTPS as a common approach. Escalate certificate or mixed-content warnings, unexpected domains, and HTTP pages that serve content instead of safely redirecting.
Confirm current ownership of publishing, domain, DNS, payment, plugin, and backup access. A qualified security professional or provider should review TLS configuration, patching, authentication, server configuration, and logs. For payment, use only a provider-approved test method or safe non-production environment. Never put real card data or credentials in an informal test or claim a visual review proves PCI compliance.
Treat a certificate warning, insecure-content warning, or unexpected redirect as a release-stopping issue until investigated.
Route suspected compromise, security requirements, and payment compliance questions to qualified reviewers.
Prove recovery and close the loop
List what reconstructs the priority journey: application version, database, uploaded media, configuration locations, DNS and domain access, integration settings, and vendor contacts. CISA advises identifying critical data, protecting website and operational databases, securing backups, and testing recovery. Ask when a restore was tested, what it restored, how long it took, and who can authorize it. Rehearse safely where practical.
Before a release, identify the prior version, reversal trigger, approver, and handling for DNS, cache, database schema, and third-party changes. A backup is not an instant fix, and rollback may not reverse external data or payment events. Keep a register of finding, evidence, owner, date, and retest result.
A record of scope, date, result, and gaps is stronger than “backups run.”
Verify the original failing path after a fix in the relevant environment.