A 50-location healthcare practice has a structurally different accessibility problem than a single-location one. The same template-level issue replicates across every microsite, every location page, every booking flow. Auditing each one individually is impractical. Auditing none of them is risky.

This post is about how multi-location practices accumulate accessibility risk and the realistic strategy for managing it.

The structural problem

Most multi-location healthcare practices have one of three architectural patterns:

  1. Subdirectory model: practice.com/locations/atlanta, practice.com/locations/birmingham. One CMS, shared templates, location-specific content.
  2. Subdomain model: atlanta.practice.com, birmingham.practice.com. Separate CMS instances, often with template variations.
  3. Microsite model: practiceatlanta.com, practicebirmingham.com. Fully separate sites, often built or maintained by different agencies over time.

Subdirectory is best for accessibility (one fix, all locations); microsite is worst (every fix is per-site).

How issues accumulate

Three accumulation patterns:

1. Template-level issues replicate everywhere

A focus-indicator-removed CSS rule in the shared template is on every location page, every provider page, every booking page. One mistake, hundreds of failures.

2. Per-location customization drifts

Each location often has some local customization — a custom hero image, a location-specific banner, a unique provider list layout. These customizations rarely receive accessibility review. The base template might be clean; the customizations introduce issues.

3. Local marketing teams add inaccessible content

Each location's marketing person uploads new content, edits provider bios, adds new images, replaces hero photos. Without an accessibility workflow, every edit potentially introduces issues. Multiplied by 50 locations and 12 months, the issue volume compounds rapidly.

What plaintiff firms exploit

Multi-location practices are particularly exposed to ADA complaints because:

  1. The plaintiff doesn't have to choose a single page — they can scan all locations' pages and compile a comprehensive issue list.
  2. Settlement math improves — more locations mean more pages, more issues, larger demands.
  3. Discovery is straightforward — public-facing pages are openly accessible; the plaintiff's scanner does the work.

A demand letter against a 50-location practice typically cites issues across at least 5–10 locations, demonstrating the systemic nature of the problem.

The realistic audit strategy

Auditing every page on every location individually is impractical. The right pattern:

Layer 1: Continuous template scanning

Scan a representative sample of pages (homepage of 3–5 locations, one provider page from each, one booking flow from each) continuously. Template-level issues will surface immediately, and you fix them once.

Layer 2: Periodic full-site sweeps

Once a quarter, run a comprehensive scan of every page on every location. This catches local customizations and content-drift issues that template scanning misses.

Layer 3: Per-location spot checks

Once or twice a year, manual review of a randomly selected sample of locations. Catches contextual issues automated tools miss.

SEO Score API's healthcare vertical supports layers 1 and 2 directly via the /audit/batch endpoint, which audits multiple URLs in one call. A 50-location practice can sweep all locations in a single scheduled job.

Implementation: a working batch scan

For a practice with 50 locations using a subdirectory model, a typical nightly job:

  1. Fetch the list of location URLs from a CMS-maintained list or a sitemap.
  2. Send to /audit/batch in groups of 10 (the per-request limit).
  3. Aggregate results, flag any URL that dropped below a threshold.
  4. Email the digital marketing director if any flags fire.

In Python:

from seoscoreapi import batch_audit
import os

LOCATIONS = [...]  # your 50 location URLs
API_KEY = os.environ["SEOSCORE_API_KEY"]
THRESHOLD = 80

flagged = []
for chunk in chunks(LOCATIONS, 10):
    result = batch_audit(chunk, api_key=API_KEY)
    for r in result["results"]:
        if r.get("score", 100) < THRESHOLD:
            flagged.append(r)

if flagged:
    notify_team(flagged)

This runs in a few minutes and fits comfortably in the Pro plan's 5,000 audits/month allowance for a 50-location practice scanning daily plus weekly full sweeps.

Comparing locations to find template vs. local issues

The key insight in multi-location auditing is comparing: if the same issue appears at 40 of 50 locations, it's a template issue (one fix everywhere). If it appears at 5 of 50, it's per-location customization (5 separate fixes).

Most teams don't do this comparison and end up fixing the same issue 50 times. The right audit workflow groups issues by failure pattern and identifies template-level fixes first.

What about provider directory pages?

Provider directory pages (one per provider, often hundreds total) follow the same logic. Most issues are template-level. Scan a sample of provider pages; if all show the same aria-label problem on the "View Profile" button, that's a template fix.

What about EHR-integrated patient portals?

Out of scope for public-site scanning. EHR-integrated portals are behind authentication and require a separate audit approach, typically manual. Most multi-location practices use the same EHR vendor across all locations, so portal accessibility is largely the EHR vendor's responsibility — though the practice is still legally responsible for the patient experience.

How does this interact with vendor relationships?

Most multi-location healthcare practices use third-party widgets (booking, insurance verification, symptom checkers). When a scan flags an inaccessible widget at one location, it's flagging it everywhere that uses the widget. Bring the issue to the vendor; pressure for remediation; document the request. The same widget breaking on 50 sites is the kind of issue vendors prioritize when raised.

What's the realistic timeline?

For a 50-location practice starting from scratch:

  • Month 1: stand up continuous monitoring. Initial template-level fix backlog.
  • Months 2–4: work the template backlog. Most template-level issues fixed.
  • Months 4–6: per-location customization audit. Local issues fixed.
  • Month 6: first manual external audit on a sample of locations.
  • Ongoing: continuous monitoring catches regressions; quarterly full sweeps catch drift.

End state: defensible accessibility posture, documented audit logs, manageable ongoing maintenance.

What if locations have completely separate microsites?

Harder problem. Each microsite needs its own monitoring setup. The good news: our healthcare vertical scanner can scan any URL regardless of who hosts it. The harder news: you need governance — who owns each microsite, who fixes issues, what happens if a location's agency goes out of business.

Many multi-location practices in this state are best served by consolidating to a subdirectory model. It's a meaningful project but pays back in both accessibility and SEO.

What's the highest-leverage thing to do today?

Three steps:

  1. List your locations' URLs.
  2. Run a free scan of one location to see typical issue patterns.
  3. Compare scores across 5 locations of the same template. If they all look similar, you have template-level issues to fix once. If they vary widely, you have customization-drift to address per-location.

Either answer tells you what your remediation strategy should be.

Run a free scan of one of your locations →