Short answer: JavaScript is the real problem when critical local information, opening hours, services, contact details, or links to locations disappear without correct rendering. It is only a convenient explanation when the real issue is duplicate local pages, noindex, a wrong canonical, or contradictory first-party data. Google documents crawling, rendering, and indexing for JavaScript and recommends crawlable links.

Failure mode 1: contact details appear only after an API call

The initial HTML does not contain phone number, address, or service-area information, and the client-side request may fail.

Failure mode 2: the locator is the only path

Locations exist only in an interactive widget without stable URLs or crawlable links.

Failure mode 3: opening hours depend on an external script

If the vendor fails, the page displays empty or stale hours.

Failure mode 4: service availability is client-only

The user and crawler cannot see which services are available at a location without executing the application.

Failure mode 5: canonical changes after selecting the city

Client state can create inconsistent URLs and canonicals.

Failure mode 6: the SPA returns 200 for nonexistent locations

This can create soft 404s.

Navigation between services and locations depends only on event handlers.

Failure mode 8: the consent manager blocks basic content

Third-party scripts should not remove essential public information.

Failure mode 9: the reviews widget breaks hydration

An external vendor should not make the page unusable.

Failure mode 10: local pages are clones

If every location has identical copy, JavaScript is not the main problem. Information gain is missing.

Failure mode 11: first-party data contradicts itself

Opening hours differ between the location page, footer, and booking flow. Correct rendering only exposes the conflict.

Failure mode 12: an AI crawlability score replaces testing

A score does not demonstrate which content or link is missing.

Reproducible decision tree

  1. Is the HTTP status correct?
  2. Is the canonical stable?
  3. Are address/hours present in HTML or robust rendering?
  4. Are local services available without a fragile widget?
  5. Are location URLs stable?
  6. Are links crawlable?
  7. Does the SPA handle nonexistent routes correctly?
  8. Do third-party failures have fallbacks?
  9. Is first-party data coherent?
  10. Does the local page have information gain?
  11. Are robots/indexability intentional?
  12. Does the failure reproduce across multiple templates?

If 9 or 10 fails, do not start with "AI crawlability."

Technical benchmark

For several locations, save status, canonical, HTML text, rendered text, critical content, links, errors, and timestamp.

Critical-content contract

Define the minimum: name, address or service area, opening hours, primary services, contact, and a link to the next step. Not every interactive element must be server-rendered, but the meaning of the page should remain.

How to handle the locator

The locator can be interactive, but every important location should have a stable URL and a robust discovery path.

How to handle booking widgets

Booking can be a separate application. The public page should explain the service and preserve a real link to the flow.

How to handle reviews and maps

These are third-party enhancements. If they do not load, contact information and services should not disappear.

How to handle service-area businesses

Do not force a physical address where the real model is a service area. Critical content should reflect operational reality.

How to measure

Critical-content parity, crawlable-link coverage, soft-404 rate, third-party failure resilience, and template coverage.

Search indexation and AI citations are external outcomes.

When JavaScript really is the problem

You have reproducible evidence that HTML/rendering or event-only navigation removes critical content or paths.

When it is a convenient explanation

The technical layer is healthy, but pages are duplicates, data is stale, or ownership is unclear.

Stopping criterion

The audit moves into monitoring when priority templates have a baseline, P0/P1 findings are closed, and new releases pass regression checks.

How to handle locations with third-party booking

If the booking flow is hosted by a vendor, separate the public page from the appointment application. Check that the link to the flow is stable and that critical information remains first-party when the vendor fails.

How to handle opening-hours changes

Opening hours may come from a central system. Keep an owner and timestamp and verify that every local surface receives the update. Correct rendering does not fix a stale data source.

How to handle mobile and slow networks

Consent, maps, and locator widgets may behave differently on mobile. Keep a device/network profile in the regression pack and verify critical content before and after hydration.

How to handle relocation

After moving a location, check route, canonical, address content, internal links, and critical external profiles. A correct redirect does not automatically update body copy or widget data.

Maturity criterion

The program moves into monitoring when local templates have a critical-content contract, P0/P1 findings are rare, and releases do not reintroduce event-only navigation or content loss.

Claim ledger

  • FACT/EVIDENCE: Google documents crawling, rendering, and indexing for JavaScript.
  • FACT/EVIDENCE: Google recommends crawlable HTML links and treats dynamic rendering as a workaround.
  • PRACTITIONER GUIDANCE: local-service audits should separate rendering failure from content/ownership failure.
  • NOT PROVEN: that robust rendering guarantees rankings or AI citations.

Conclusion

In local services, JavaScript should be diagnosed through concrete failures, not scores. If the address, opening hours, and path to the service are robust, the problem may be elsewhere. If they disappear without rendering, you have a real and verifiable technical defect.

Sources reviewed

Related insights