Begin with failures that can prevent a family from reaching the nursing home website, create an insecure browsing experience, or leave sensitive data handling unclear. These are technical and operational checks.
They do not determine legal or regulatory status; the responsible organizational reviewers make those determinations from the evidence.
Check: Verify secure delivery for intended public pages and required assets. Evidence required: a current crawl, certificate inspection, browser security results, redirect behavior, and representative facility, care, contact, and form URLs.
Pass condition: intended public pages load over HTTPS, certificate checks are current, and sampled templates do not expose unresolved insecure resources or unintended HTTP versions. Fail condition: a user can encounter a certificate warning, an important resource is loaded insecurely, or an intended redirect leaves a public HTTP version available.
Severity: High when the problem affects a contact or sensitive-data path; otherwise Medium according to scope. Owner: web engineering or site operations, with security participation when the organization's process requires it.
Corrective action: repair certificate configuration, redirect rules, mixed-resource references, or shared template code, and address the root cause when the defect repeats across templates. Validation step: recrawl the affected templates, repeat browser and certificate checks, and save the post-release evidence before closure.
Check: Trace every public form and lead-capture path that can receive information from a resident, prospective resident, family member, caregiver, or referral contact. Evidence required: field inventory, page location, submission destination, storage location, integrations, access roles, retention settings, tracking behavior, vendor records, security settings, and the responsible privacy or legal review record.
Pass condition: the team can show what is collected, why each field is needed, where submissions travel, where they are stored, who can access them, and which internal review has been completed. Fail condition: the data route is unknown, unnecessary sensitive fields remain, an unreviewed integration receives submissions, permissions exceed the intended audience, or a known control is misconfigured.
Severity: High. Owner: privacy, legal, security, and web operations jointly under the organization's governance process. Corrective action: remove unnecessary collection, restrict permissions, correct configuration, revise or review integrations, and document the approved handling path.
Validation step: submit synthetic information containing no real resident data and verify routing, storage, access, notifications, and deletion behavior against the approved design.
Check: Compare facility and organization structured data with the visible page and the implementation documentation the team is relying on. Evidence required: rendered markup, the visible facility facts described by that markup, applicable Schema.org definitions, validation output, and documentation for any Google search feature being evaluated.
Pass condition: the markup describes the same real entity and visible facts, uses an appropriate type, and contains no unresolved validation issue that makes the representation materially inaccurate.
Fail condition: the markup introduces unsupported services, amenities, pricing, capacity, awards, availability, or other facts; uses a type that does not fit the entity; or relies on hidden claims created only to seek a search presentation.
Severity: Medium, raised to High when inaccurate markup could materially misrepresent the facility. Owner: SEO lead with engineering and the relevant content owner. Corrective action: remove unsupported properties, align values with approved facility facts, and change the type only when the revised implementation is a better factual match.
Validation step: inspect the rendered markup after release, rerun the relevant validator, and compare the output line by line with what readers can see. Structured data can support machine-readable understanding or feature eligibility where documentation allows, but it is not a guaranteed ranking mechanism or display outcome.
Check: Review Core Web Vitals and loading behavior on representative nursing home templates, using LCP under 2.5 seconds as the existing target carried by this checklist rather than as a guarantee of search performance.
Evidence required: saved field or lab reports for the same representative URLs, notes identifying major measured bottlenecks, and comparable before-and-after records. Pass condition: the sampled templates meet the stated operating target or have an owned remediation task that identifies the measured cause, affected user task, and validation method.
Fail condition: repeated tests show material loading delays with no assigned corrective work, or essential care content and contact controls remain blocked, unstable, or unusable while the page loads.
Severity: Medium, raised when page behavior prevents a family from completing an important contact or information task. Owner: web performance or engineering owner. Corrective action: address measured causes such as oversized media, unnecessary scripts, caching gaps, or template rendering defects without claiming that one metric alone determines visibility.
Validation step: retest the same URLs with comparable settings and verify both the metric and the intended user task after deployment.
Check: Verify the XML sitemap as an inventory of canonical pages the site intends search engines to discover. Evidence required: the live sitemap, crawl results for listed URLs, canonical and indexability status, robots controls where relevant, and the current submission state in Google Search Console.
Pass condition: the sitemap is reachable, lists intended canonical and indexable pages, excludes obvious blocked or noncanonical variants, and has no unresolved format issue that prevents processing.
Fail condition: important facility or care pages are missing, retired or blocked URLs remain listed at scale, the file cannot be fetched, or the submitted location is stale. Severity: Medium. Owner: technical SEO or web engineering.
Corrective action: rebuild sitemap rules from the approved canonical set, remove unintended entries, restore missing eligible pages, and submit the current file through the normal search-console workflow.
Validation step: fetch the live sitemap, sample entries for canonical and indexability state, and confirm that the submitted file can be processed.