Short answer: in local services, Core Web Vitals are relevant if location pages have poor experience, slow interactions or layout instability, but do not automatically explain the lack of discovery. The audit must first check location identity, crawlability, rendering, program, contact, service scope and local lifecycle. CWV is a layer of the diagnosis, not an AI visibility score.

Failure mode 1: location is wrong, but performance is optimized

A page can have great metrics and an old address. For a local business, factual correctness takes priority.

Compare location registry with visible page and structured data.

Failure mode 2: the program is dynamic and becomes stale

Opening hours, holiday hours and emergency schedules may vary. If the update pipeline fails, the user receives the wrong information regardless of the LCP.

Keep effective dates and owner.

Failure mode 3: contact path depends on fragile script

Call, booking or directions can be hidden in JavaScript components. If the script does not run, the main task becomes impossible.

Test fallback and raw HTML.

Failure mode 4: CLS comes from maps or promo widgets

Embeds can move the layout and create instability. Measure contribution and reserve space accordingly.

Do not remove functionality without checking user task.

Failure mode 5: INP is affected by booking integration

A third-party widget may delay the interaction. Profile before rewriting the entire page.

Separate first-party and vendor contribution.

Failure mode 6: LCP is a large image, but the discovery problem comes from linking

A heavy hero asset can affect the LCP, while the location page remains almost an orphan in the site.

The audit must include internal paths and sitemap.

Failure mode 7: multiple locations are cannibalized by duplicate copy

Almost identical pages may have few distinct local signals. The problem is content identity and service-area clarity, not CWV.

Keep location-specific real facts.

Failure mode 8: service area is vague

``We serve the whole city'' without zones, eligibility or limitations can create ambiguity. For some services, coverage depends on distance or availability.

Define scope where verifiable.

Failure mode 9: closed location remains indexable as active

Poor lifecycle governance produces stale pages. The redirect to the homepage may be inappropriate if there is no equivalent.

Keep closed, relocated and merged states.

Failure mode 10: mobile overlay blocks content

A consent, chat or promo popup can make the task difficult on mobile. This is real flawed UX.

Test under normal conditions, not just lab without third-party scripts.

Failure mode 11: structured data does not correspond to the page

Local business markup may have a different phone number or address than visible content. This is a data inconsistency.

CWV does not repair semantic mismatch.

Failure mode 12: AI discovery is evaluated by a single query

A screenshot does not represent visibility. Create query set on brand, service, location and problem intent and repeat observations.

Stores source URLs and timestamps.

Reproducible diagnostic checklist

  1. Is the Location ID correct and unique?
  2. Are the address, phone and hours current?
  3. Does Page respond 200 and is it indexable?
  4. Is Canonical pointing to the right URL?
  5. Are important links crawlable?
  6. Does raw HTML contain location and service identity?
  7. Does the final DOM keep the same facts?
  8. Does Field CWV evidence exist for the relevant template?
  9. LCP element is identified?
  10. Is INP path related to a real task?
  11. Is the CLS source known?
  12. Do external discovery observations use a fixed window?

How to measure CWV without pseudo-scores

Report LCP, INP and CLS according to available documentation and device/population segment. Do not combine them in an `AI readiness score'.

Keep field and lab data separate.

How to measure local task completion

Test call, directions, booking, quote request and service detail access on a sample of locations. A fast page that does not allow the main task is not a success.

You can use pass rates on defined scenarios.

How do you measure discovery

Search Console can show impressions, clicks and queries within its limits. For AI observations, use query set and evidence capture.

Do not combine the two into a single denominator.

Prioritization

P0: wrong address, wrong phone, closed-location confusion, indexability defect. P1: broken contact/booking task and severe rendering issues. P2: degraded CWV, weak internal linking, service-area ambiguity. P3: cosmetic tuning.

This order protects local operations.

When CWV is the real cause

If field data consistently shows a problem on the template, profiling identifies the source, and user-task metrics confirm friction, remediation is warranted.

Example: severe interaction delay after inserting a widget on all location pages.

When it's just the convenient explanation

If locations are stale, pages are orphan, canonical is wrong or contact path does not exist, performance tuning does not attack the main defect.

First close the failure more directly.

Stop criterion

Stop the rollout if the optimization changes local facts, removes a booking fallback, breaks analytics, or produces differences between mobile and desktop that affect the task.

Keep component version for rollback.

Acceptance criteria

The diagnosis is complete when:

  1. location registry is verified;
  2. technical access is healthy;
  3. raw and rendered content are compared;
  4. field and lab CWV are separated;
  5. user tasks are tested;
  6. third-party contribution is measured;
  7. local lifecycle is included;
  8. external observations are versioned;
  9. findings have priority and owner;
  10. the verdict can be `NOT_PROVEN'.

Claim ledger

  • FACT/EVIDENCE: web.dev documents Core Web Vitals and LCP, INP and CLS metrics.
  • FACT/EVIDENCE: Google documents JavaScript SEO and crawlable links relevant to delivery and technical discovery.
  • PRACTITIONER GUIDANCE: local services diagnostics must prioritize location truth and user tasks before vanity scoring.
  • INFERENCE: better performance can reduce friction, but external discovery depends on several layers.
  • NOT PROVEN: that hitting a CWV threshold directly produces AI citations or local positions.

Conclusion

Core Web Vitals are worth tracking for local services as part of user experience, not as a universal explanation for discovery. Location truth, technical access, rendering and task completion provide a more complete diagnosis. When these layers are healthy, CWV can be optimized and measured without inventing a score that mixes different things.

Sources reviewed

Related insights