Building a Hebrew-First SEO Plugin (“Project Spark”) — Part 10 of 20

My client runs several physical locations, each with its own Google Business Profile — and their local SEO lived or died on data consistency between the website, Google, and structured data. Project Spark’s GEO layer manages all of it with one non-negotiable constraint: the plugin can read from Google Business Profile, but is architecturally incapable of writing to it.

Key takeaway: For local SEO tooling, the highest-trust feature is the write you can’t perform. A read-only Google Business Profile integration eliminates the worst failure mode — software silently editing a business’s public listing — while still powering schema, maps, and consistency monitoring.

Why multi-location changes everything

Single-location local SEO is mostly a completeness exercise: one address, one phone number, one listing, one schema block. Multi-location businesses face a different mathematics. Every fact now exists in N copies across at least three systems — the website, Google’s listing for each branch, and the structured data describing each branch — and every copy is editable by different people with different permissions on different schedules. A receptionist updates a branch phone number in Google. A developer edits the contact page. A marketing hire rewrites a location description. None of them tells the others.

Search engines notice. Local ranking is substantially a trust calculation, and conflicting facts across systems lower confidence in all of them. For voice queries the stakes are sharper still: an assistant returning one answer to “call the nearest branch” either dials the right number or the wrong one (Part 12). So the engineering brief for Project Spark’s GEO layer was really a data-consistency brief: one authoritative record per location, machine-verified against Google, with humans alerted the moment the copies disagree.

Locations as first-class content

Each location is a structured record: name, address, city, phone, coordinates, website, description, opening hours, business category. In WordPress terms, locations are a dedicated content type with their own admin screens, list columns (city, phone, sync status), and role-based access — a location manager role can be granted access to assigned branches only, so a franchise or branch manager edits their own record and nobody else’s. One location is flagged primary — with uniqueness enforced at save time, because two “primary” locations would emit conflicting LocalBusiness schema. From these records the plugin generates:

• LocalBusiness structured data — with the correct schema.org business type chosen from a 153-type registry (there’s a meaningful difference between a generic LocalBusiness and, say, an Optician or MedicalBusiness for rich-result eligibility).
• A parent-organization schema when multiple locations exist: one Organization with each branch as a sub-organization — the pattern Google’s knowledge graph expects from chains. Per-branch details (address, telephone, coordinates) attach to the branch, not the parent, and a branch missing its coordinates emits no geo block at all rather than a zero-filled one (Part 11 explains why that guard exists).
• Geographic meta tags (geo.position, ICBM, ISO region codes, placename) for geo-targeting crawlers — small, old-fashioned signals that cost nothing to emit correctly.
• Google Maps embeds with accessible fallbacks for no-JS visitors, loaded only on pages that actually use them.

The record is the single source of truth. Schema, meta tags, and maps are all projections of it — which means fixing a fact once fixes it everywhere the site expresses that fact.

Google Business Profile sync — one direction only

Connecting to Google uses OAuth 2.0 with PKCE (Part 13). After that, sync pulls listing data — address, phone, hours, categories — and normalizes it into the location records, so the website’s structured data always mirrors what Google displays.

Normalization is unglamorous and essential. Google’s API expresses opening hours, address components, and categories in its own formats; schema.org expects different enumerations and shapes. The sync layer translates between them — hours into valid opening-hours specifications, address components into postal-address fields, Google’s category into the closest schema.org business type — so that what Google displays and what the site’s structured data claims are generated from the same underlying facts rather than maintained by hand in two dialects.

The read-only guarantee is enforced at three layers: the API client refuses write verbs, the write methods simply don’t exist in the codebase (removed, not just disabled), and automated tests assert their absence — so a future developer can’t quietly reintroduce them. Blocked attempts would be logged to an audit trail.

That third layer deserves emphasis because it is the unusual one. Plenty of software has features that are switched off. Almost none has tests that fail the build if a forbidden capability reappears. The distinction matters over a product’s lifetime: a switched-off feature is one confused pull request away from being switched on; a capability whose absence is pinned by tests requires someone to deliberately delete the guardrail in plain sight, which is exactly the kind of change code review exists to catch.

Why so paranoid? Because a business’s Google listing is often worth more than its website. It is frequently the first — sometimes the only — surface a local customer sees: the map result, the phone number, the hours, the reviews. No plugin bug, compromised admin account, or overeager AI feature should ever be able to change it. Write access that does not exist cannot be exploited, cannot be misused by a rushed intern, and cannot be triggered by a defect. Restraint, engineered properly, is a security control.

NAP drift: the silent local-SEO killer

NAP (Name, Address, Phone) consistency across the web is a foundational local ranking factor. The plugin snapshots each location’s NAP baseline and compares on every sync. If someone changes the phone number in Google — or in WordPress — a drift alert appears in the dashboard with a field-by-field diff, and stays until a human acknowledges it and resets the baseline. Drift history is kept per location.

Three design decisions shaped the monitor:

• Alerts persist until acknowledged. A drift notice that disappears on page reload is a drift notice nobody actions. The alert remains until an authorized person explicitly accepts the new values as the baseline — turning “someone changed something” into a recorded human decision.
• Diffs are field-level. “This location drifted” invites guessing. “Phone changed from X to Y on this date” invites a two-minute fix. The history log (capped per location so it cannot grow without bound) answers the inevitable later question: when did this change, and in which system?
• Detection runs on every sync, not on a special audit. Consistency checking that requires remembering to run it fails exactly when staff turnover or busy seasons make people forget. Bundling it into the routine sync makes monitoring the default state.

This caught real drift within weeks of launch: a phone number updated in one system and not the other. Before, that mismatch could have sat unnoticed for months, quietly eroding local rankings — and misdialling every voice-assistant caller in the meantime.

Who may edit what: access control for branch data

Multi-location data has a governance problem that single-location sites never meet: the people best placed to keep a branch’s facts current are usually the people who should have the least access to everything else. A branch manager knows the moment opening hours change; giving that manager full administrative access to the website so they can record it is how security incidents start.

Project Spark’s answer is a dedicated location-manager role with deliberately minimal capabilities. A location manager can edit the location records assigned to them — and nothing else: no site settings, no other branches, no user management, no plugin configuration. Assignment is per-location and enforced on every operation, including the background ones; automated tests exercise the full permission matrix (administrator, assigned manager, unassigned manager, ordinary user) so the isolation between branches cannot quietly regress in a future release.

Two design details are worth copying. First, the role’s capability set is minimum by construction — tests assert not only what the role can do but what it can never do, pinning the absence of administrative capabilities the same way the write methods’ absence is pinned. Second, everything consequential is logged: connection events, sync runs, drift acknowledgements. When a phone number changes, the question “who accepted this and when?” has a recorded answer rather than a shrug.

The payoff is organizational, not just technical: the client can delegate data freshness to the people closest to it without expanding the circle of people who can break the site. Fresh data and least privilege stop being a trade-off.

Applying this to your own multi-location business

A practical sequence, no custom software required to start:

1. Inventory the copies. For every branch, list where its name, address, phone, and hours currently live: website pages, Google listing, directories, schema. Most businesses discover copies they forgot existed.
2. Choose one source of truth and make every other surface a projection of it — even if “projection” initially means a manual checklist rather than code.
3. Check NAP consistency today, by hand: read each branch’s phone number on the website and on Google, side by side. If any pair disagrees, you have found live ranking damage.
4. Use the most specific schema type available for each branch, under a parent Organization, rather than one generic block for the whole company.
5. Interrogate any tool that connects to your Google Business Profile: does it request write scopes? Under what conditions does it write? Prefer read-only integrations unless writing is the explicit, supervised point — and ask the vendor what prevents an accidental write. “We just don’t call that API” is a policy; deleted code with tests asserting its absence is a guarantee.

FAQ

How do I manage SEO for multiple business locations?

Model each location as structured data (address, phone, hours, coordinates), emit per-location LocalBusiness schema under a parent Organization, keep Google Business Profile and website data synchronized, and monitor NAP consistency continuously.

What is NAP consistency in local SEO?

NAP is Name, Address, Phone. Search engines cross-reference these across your website, Google listing, and directories; mismatches undermine trust and local rankings. Automated drift detection catches changes early.

Can a WordPress plugin edit my Google Business Profile?

With write scopes, yes — which is exactly why our integration is certified read-only: write methods don’t exist in the code, and tests verify their absence.

Which schema type should a multi-location business use?

A parent Organization with each branch as a sub-organization carrying its own LocalBusiness data — and use the most specific schema.org business type that fits each location.

How often should I check my business listings for changes?

Continuously, through automated drift detection on every sync — or at minimum monthly by hand. Phone numbers and hours change through staff edits more often than most owners expect.

Why does my business show the wrong phone number in voice search?

Your website, Google listing, or structured data disagree with each other. Voice assistants return one answer, so a stale copy in any system can become the number that gets dialled.

Previous: Part 9: AEO in Practice: llms.txt, FAQ Schema, AI Crawlers
Next: Part 11: JSON-LD at Scale on a Hebrew WordPress Site