Start here because technical visibility is not useful when sensitive data handling is unknown or important pages are inaccessible. Treat every item as a documented control, not as evidence that a product, vendor, or SEO tactic is compliant or ranking-positive.
Tracking, form, and vendor data flow
Evidence required: a current inventory of scripts and tags, every public form and field, consent behavior, call-tracking configuration, analytics destinations, vendor recipients, relevant contracts or BAAs where applicable, retention notes, and the approval record for the actual implementation.
Pass/fail condition: Pass when the team can trace what is collected, where it is sent, why each destination is used, and who determined the applicable privacy requirements. Fail when health-related inquiry information, identifiers, or sensitive context can reach an unreviewed recipient, when an unnecessary field is collected, or when the data path cannot be reproduced.
Severity: Critical. Owner: Privacy or compliance lead, supported by the analytics engineer and site owner. Corrective action: Remove unnecessary collection, reduce form fields and transmitted parameters, disable unsupported destinations, correct vendor configuration, and document the approved flow.
Server-side routing can change implementation architecture, but it does not establish HIPAA compliance by itself. Existing stacks may include Google Tag Manager Server-Side, Segment, or Freshpaint; evaluate the deployed configuration rather than the product label.
Validation step: Send controlled test submissions, inspect browser and server requests, compare observed recipients with the approved inventory, and retain the responsible review record.
Entity and medical structured data
Evidence required: the rendered page, current JSON-LD, business and practitioner source records, visible profile facts, and the relationship between the organization, real clinic locations, and clinicians.
Pass/fail condition: Pass when markup mirrors supportable facts that users can verify and uses Schema.org types and properties that truthfully describe the entity. Fail when markup invents a specialty, practitioner role, acceptance status, address, service, or relationship that is absent from the visible page or source records.
Severity: High. Owner: Technical SEO and developer, with the business or clinical owner confirming factual accuracy. Corrective action: Delete unsupported properties, correct entity relationships, and align templates with the facts shown to users.
Structured data may help systems interpret entities, but it should not be presented as a guaranteed ranking mechanism. Validation step: Inspect the rendered markup, compare material properties with the source-of-truth records, and repeat the check whenever practitioner, organization, or location data changes.
Mobile performance and Core Web Vitals
Evidence required: representative mobile templates, field data where available, Search Console reports, PageSpeed Insights diagnostics, performance traces, and an inventory of heavy media and scripts.
Pass/fail condition: Use 2.5 seconds as the source checklist's LCP review threshold, then interpret the result with current tool guidance and real-user evidence. Pass when essential content and inquiry controls remain usable on mobile and material performance defects are assigned to an owner.
Fail when rendering delays, instability, blocked interaction, or heavy scripts materially interfere with reading or form completion. Severity: High. Owner: Developer or performance engineer with technical SEO.
Corrective action: Resize and compress media, remove unnecessary scripts, improve caching and delivery, reduce blocking work, and prioritize the content needed for the initial view. Do not convert a performance threshold into a promise about rankings, bounce behavior, or inquiries.
Validation step: Retest the same templates after deployment and compare like-for-like lab diagnostics with available field data.
HTTPS and transport security
Evidence required: certificate state, redirect behavior, mixed-content checks, HSTS configuration where appropriate, form submission behavior, and any authenticated or administrative pathways exposed through the public site.
Pass/fail condition: Pass when public pages and inquiry flows use secure transport, insecure variants resolve correctly, and material mixed-content errors are absent. Fail when users can submit information over an insecure path, certificates fail, redirects create unsafe variants, or security behavior is undocumented.
Severity: Critical. Owner: Developer or security owner. Corrective action: Repair certificate and redirect defects, remove insecure asset calls, review HSTS deployment before changing it, and document the production state.
Tools may include Let's Encrypt and Qualys SSL Labs, but validation should focus on observed behavior. Validation step: Test representative pages and forms from a clean session, confirm certificates and redirects, and retain the final security check with the release record.