Start with controls that determine whether patients can access the site reliably and whether inquiry data moves only through reviewed systems. A pass requires current evidence plus a successful live validation. It does not certify the clinic's broader legal or regulatory status.
Patient inquiry forms and privacy-sensitive data flows
Evidence required: a current inventory of inquiry forms, chat services, call-tracking tools, analytics tags, booking widgets, destination systems, vendors, user roles, and every field that may collect or transmit patient or prospective-patient information.
Pass/fail condition: pass only when the responsible privacy, legal, security, or compliance owner has documented the applicable requirements, the implemented data flow matches the approved design, required safeguards and agreements are present, and the live form sends information only where that design permits.
Fail when the clinic cannot identify a data destination, sensitive fields reach an unreviewed system, access is broader than approved, or the live workflow differs from the reviewed configuration. Severity: critical.
Owner: privacy or compliance lead working with the web owner and the team responsible for intake systems. Corrective action: remove unnecessary collection, move data only through approved systems, correct vendor or tag configuration, update notices when required by the responsible reviewer, and document the final approved workflow before restoring the affected path.
Validation step: send controlled inquiries using non-sensitive test data, inspect browser requests and destination behavior, confirm permissions and retention settings with the responsible owner, and retain evidence of the tested implementation. Tools: JotForm HIPAA, Formstack, WPForms
Physician and MedicalBusiness structured data accuracy
Evidence required: the rendered JSON-LD, visible clinic and practitioner details, current internal provider and location records, and the exact page content described by the markup.
Pass/fail condition: pass when Physician and MedicalBusiness markup is syntactically valid, represents the real entity shown on the page, and does not introduce unsupported credentials, specialties, locations, or treatment statements.
Fail when markup conflicts with visible content, points to stale identities, or is used to supply facts that the page itself does not support. Severity: high. Owner: technical SEO or developer with practice operations and the responsible clinical reviewer for medical facts.
Corrective action: delete unsupported properties, reconcile names and identifiers with the clinic's source of truth, and limit the markup to the entity actually represented by the page. Validation step: inspect rendered source, test syntax with Schema.org and Google Rich Results Test where applicable, and compare material fields against the current visible page.
Treat structured data as a clarity mechanism, not as an E-E-A-T score, ranking guarantee, or special requirement for Google AI Overviews. Tools: Schema.org, Google Rich Results Test
Mobile usability and Core Web Vitals on priority templates
Evidence required: Search Console reporting, field or lab performance evidence, real-device checks for important treatment, location, gallery, practitioner, and contact templates, and a reproducible defect log.
Pass/fail condition: pass when priority mobile pages remain readable and operable, key controls do not become unusable through layout movement or delayed interaction, and known Core Web Vitals problems have a documented disposition.
Fail when recurring instability, rendering failure, script blocking, or broken controls prevent a prospective patient from reading key information or contacting the clinic. Severity: high. Owner: web developer or platform owner with UX and analytics support.
Corrective action: improve image delivery, remove or defer unnecessary scripts, reserve layout space, address server or rendering bottlenecks, and repair the affected template instead of optimizing only a favorable test URL.
Validation step: rerun PageSpeed Insights, review Search Console when sufficient field data exists, and manually test representative mobile devices and page states. Performance work can improve usability without promising a ranking change. Tools: PageSpeed Insights, Search Console
Third-party booking security and governance
Evidence required: the current list of embedded or linked booking services, active fields, data recipients, access roles, vendor documentation, and the clinic-approved intake design.
Pass/fail condition: pass when the booking flow sends only approved information to approved destinations, the clinic can identify who has access, and implemented privacy and security controls match the reviewed workflow.
Fail when the service adds unreviewed tracking, transfers unexpected information, exposes records too broadly, or bypasses the approved intake path. Severity: critical. Owner: operations or intake-system owner with privacy, security, and web stakeholders.
Corrective action: reconfigure or replace unsupported integrations, minimize requested information, restrict access, and document the production configuration before reopening the workflow. Validation step: complete a controlled end-to-end booking using test information, inspect browser behavior and destination systems, verify permissions, and retain the reviewed vendor and configuration record. Tools: Nextech, Mindbody, Symplast