Project context
A Technical Case Study — CodingBeings
Client: Benchmark Email | System: Benchmark Hreflang Audit & Output (network WordPress plugin, v1.7.2)
2. Executive Summary
This case study documents a real, production WordPress Multisite hreflang and translation-relationship system built for Benchmark Email — a company running one English-language site plus regional/language subsites inside a single WordPress network, with a ninth regional variant hosted as a fully separate installation outside that network.
The underlying engineering problem was not “how do we translate WordPress pages.” It was: how do we reliably know which page on each regional site is the equivalent of which page on the English site, keep that relationship trustworthy as content changes over time, and expose it correctly to search engines. The delivered system is a custom, network-activated WordPress plugin (documented here as “Benchmark Hreflang Audit & Output,” currently at version 1.7.2) that scans and auto-matches Pages across sites, gives a human a review-and-correction interface, and — only once relationships are trusted — outputs reciprocal hreflang tags and localizes the site’s language-switcher navigation.
This document separates what was actually built and observed (drawn from the plugin’s own documentation and its full version history) from architecture CodingBeings recommends as a future step. It does not report SEO outcome metrics — traffic, rankings, indexing counts — because none were supplied as part of this engagement’s documentation; where a claim isn’t backed by the source material, this document says so directly rather than filling the gap.
3. Client / Environment Context
Client: Benchmark Email
Environment: A WordPress Multisite network using subdirectory-style regional URLs (e.g. /es/, /fr/), consisting of one English site acting as the primary/anchor content source, plus seven regional subsites inside the same network.
Outside the network: One additional regional variant (Simplified Chinese) is hosted as a completely separate WordPress installation, intentionally kept off the main network’s CDN to avoid the site being blocked inside China.
Confirmed site count: Nine language/region variants in total — see Regional Site Model below.
Content scope: This system covers Pages only. Blog post translation relationships already existed through the site’s separate, pre-existing translation plugin and were explicitly out of scope here — see Blog vs Page Relationship Handling.
4. The Technical Challenge
The central technical problem was not simply “how do we translate WordPress pages.” The larger problem was:
“How do we reliably maintain relationships between equivalent pages across multiple independent WordPress subsites, and expose those relationships correctly to search engines?”
This chains together several systems that are each simple in isolation and fragile once connected:
Content → Regional version → Translation relationship → Canonical URL → hreflang → Search engine discovery / indexing
A break at any single link in that chain — a missing relationship, a stale URL, an unpublished target, a wrong language code — produces a hreflang problem, even when every individual page is perfectly fine on its own. The engineering work here is therefore mostly about the links between pages, not the pages themselves.
5. Existing WordPress Multisite Architecture
The environment is a WordPress Multisite network using a subdirectory URL structure for its member sites. The English site is the anchor / primary content source: for each configured language, the system looks for a matching Page on every other configured site.
Eight of the nine configured language/region variants are members of this same multisite network (each resolving to a blog ID inside it). The ninth — Simplified Chinese — is deliberately not part of the network: it is a separate WordPress installation on its own domain, and is handled as an external relationship (manual entry plus a live URL check) rather than an internal multisite relationship.
WordPress Multisite and translation relationships
Eight sites belong to the network. Simplified Chinese is external; it is not the Traditional Chinese subsite.
View original diagram at full resolution
Scroll within the figure to inspect its original labels and connections.
Figure: the documented multisite architecture — eight sites inside one network, anchored on English, plus one externally-hosted site handled as a manual relationship.
An implementation of this kind, scanning Pages across every site in the network from a single network-activated plugin, would typically rely on WordPress Multisite’s site-switching functions (switch_to_blog() / restore_current_blog()) to read content from each site in turn during an audit run. The supplied documentation confirms the network-wide scanning behavior itself — “scans every published page on every site that resolves to a blog ID in this network” — but does not name the specific internal functions used, so that detail is noted here as typical implementation rather than a confirmed fact.
6. Regional Site Model
The nine configured sites, as documented:
| Code | Language / Region | URL structure | Part of network? |
|---|---|---|---|
| en | English | Primary domain (root) | Yes |
| es | Spanish | /es/ | Yes |
| fr | French | /fr/ | Yes |
| de | German | /de/ | Yes |
| it | Italian | /it/ | Yes |
| ja | Japanese | /jp/ (URL path differs from the ja language code) | Yes |
| zh-TW | Traditional Chinese | /tw/ | Yes |
| zh-CN | Simplified Chinese | Separate domain, own WP install | No — external, kept off the network CDN to avoid blocking in China |
| pt-BR | Portuguese (Brazil) | /br/ | Yes |
This list is the authoritative source for this document. It is worth flagging explicitly: this project’s documentation does not describe an India / Hindi (“IN”) site — the ninth variant is Japanese, not Indian. Any assumption that this network includes an IN site would be an invention not supported by the source material, so it is intentionally not included here.
Language codes vs. language-region combinations
The codes above are not interchangeable in kind. “ja” is a plain language code; “pt-BR” and “zh-TW” / “zh-CN” are language-region combinations, and the distinction matters for hreflang correctness. zh-TW and zh-CN are both Chinese but differ by script and region (Traditional vs. Simplified) — treating them as one “Chinese” language would be incorrect. pt-BR represents Portuguese as localized for Brazil specifically, not Portuguese generically. And ja’s URL path (“/jp/”, a country-style code) does not match its language code (“ja”) — a reminder that a site’s URL slug and its correct hreflang value are two different things that must not be assumed identical. Per the same logic, “BR” in this project’s URL path denotes the pt-BR regional variant of Portuguese, not a standalone language — it should never be treated as if “BR” itself were a language code.
7. The Hreflang Problem
From an engineering perspective, the problem is not adding a <link rel="alternate" hreflang="..."> tag — that is a few lines of template code. The real problem is maintaining a valid relationship graph: for a given English page, its equivalents across up to eight other sites need to be accurate, reciprocal where required, complete where translations actually exist, consistent, free of incorrect or broken URLs, free of non-indexable or redirected targets, free of canonical mismatches, and free of stale relationships left behind after a page is renamed, moved or removed.
What can go wrong, categorically: missing hreflang, incorrect hreflang, a wrong URL, a broken URL, a non-indexable URL, a redirected URL, a canonical mismatch, a language mismatch, a region mismatch, a missing reciprocal relationship, an orphaned regional page, a translation that exists but has no relationship recorded, or a relationship that points at a page that no longer exists.
This project’s own version history contains real, confirmed instances of several of these categories — not hypothetical ones. Version 1.3.4 fixed a false-negative URL-validation pattern specifically on multisite subdirectory regional URLs (a broken-URL-detection bug in the audit tool itself). Versions before 1.4.0 anchored every scanned page in every language as its own group, producing large numbers of duplicate relationship rows — a structural version of “missing reciprocal relationship” bookkeeping. And version 1.6.4 fixed a case where rejecting a wrong hierarchy-match guess didn’t actually stick: the same wrong guess kept reappearing on reload instead of staying marked as “no translation,” a direct real-world instance of a relationship that looks resolved but silently reverts to being wrong.
8. Why Manual Hreflang Management Breaks Down
With nine language variants and a large, growing set of Pages, hand-writing hreflang tags requires a person to correctly enumerate, for every English page, up to eight other URLs — and keep all of them current as pages are renamed, moved or unpublished, while keeping every site’s tag set reciprocal with every other site’s. That consistency burden grows with both content volume and language count; it does not stay flat.
This project’s own starting conditions illustrate exactly why: “a significant portion of the pages already existed across regional sites … some pages existed in all regions, other pages existed only in some.” The relationship map was already irregular and incomplete before any tooling existed — precisely the condition under which hand-maintained tags drift silently out of correctness. This is what motivates treating relationships as structured, auditable data rather than static tags typed once into each page’s HTML and never revisited.
9. Translation Relationship Data Model
Observed / documented data model
The actual system stores relationship data as a small set of WordPress network (site) options, plus a generated filesystem cache:
bme_hreflang_last_audit — the last audit run’s results: a summary plus one row per English-page group.
bme_hreflang_relationship_overrides — manual corrections and additions, keyed by anchor_key and then language, stored independently of audit runs so they survive re-auditing.
bme_hreflang_output_enabled — the on/off switch for frontend output.
bme_hreflang_output_index — a flat lookup (groups / by_post / by_url) used for frontend output and the external REST endpoint; rebuilt automatically on every audit run, save, remove or toggle.
cache/bme-hreflang-index.php — a generated, opcache-backed PHP array file mirroring the index, used as a fast read path so frontend page loads avoid a database query; the system falls back to the database option automatically if this file is ever missing or unwritable.
Each relationship group is anchored on the English page via a stable anchor_key (lang:blog_id:post_id) plus a group_id — functionally the same idea as a normalized “translation group” table, implemented through WordPress options and composite keys rather than custom database tables.
Recommended relationship model (conceptual — not confirmed as implemented)
For a system built from scratch today, or as a generalization of what this system already does, a more explicit relational structure is worth considering:
relationship_id
source_site, source_post_id, source_language
target_site, target_post_id, target_language
status (e.g. confident / needs review / manually confirmed / confirmed no translation)
last_verified
This schema is a conceptual reference, not a claim about what was actually built. The observed system achieves an equivalent function through anchor keys and network options rather than a formal relational table — that distinction is intentional and should stay visible to anyone evaluating this architecture.
10. Page-Level Relationship Management
Conceptually, an English page needs to know which page on every other site is its equivalent:
EN Page → FR equivalent · DE equivalent · ES equivalent · IT equivalent …
The observed system implements this through its anchor_key / group_id pairing: each English page anchors a group, and every other configured language is a column within that group, holding a status badge (EN / exact match / needs-review match / manual override / missing) and, where applicable, a validated URL. The system therefore knows, for every relationship: whether a translation exists (the badge), which page it maps to (the stored URL/post reference), which language it belongs to (the column), whether the target URL is valid (checked via a URL-resolution fallback chain for network sites, or a live HTTP check for the external Chinese site), and whether it is confident enough to include in hreflang output (see confidence gating, below).
This is more reliable than hand-writing tags because the relationship can be re-derived and re-validated programmatically on demand, instead of depending on a person remembering to update every regional page’s tag block whenever any one page in the group changes.
11. Blog vs Page Relationship Handling
An important scoping decision in this project: “Blog post translation relationships already exist in the site’s existing translation plugin, so this plugin does not scan or touch blog posts — Pages only.”
The architectural lesson generalizes beyond this one project: different content types may already have different synchronization mechanisms, built at different times by different tools. A multilingual architecture should treat posts, pages and custom post types as potentially separate relationship domains, rather than assuming one system covers everything. In practice, that means inventorying what already exists per content type before building new relationship tooling — in this case, Posts already had a working mechanism, so the engineering effort went specifically where a gap existed: Pages.
12. Hreflang Audit Architecture
The audit tool has two documented entry points. A full “Run Page Audit” scans every published Page on every site that resolves to a blog ID in the network, auto-matches each English page against every other language using exact-slug, hierarchy or title-similarity matching, and excludes noindexed pages (via Yoast) and pages whose slug or title contains “thank you,” “coming soon” or “trackdesk.” A scoped “Add / Refresh a Single Page” path (added in version 1.7.0) runs the identical matching logic against just one English URL, for when only one new page needs relationships rather than a full network rescan — documented explicitly as sharing the same matching function, “not a lower-quality shortcut.”
Hreflang audit and correction workflow
Unresolved items return in the next audit. Frontend output is enabled separately after review.
View original diagram at full resolution
Scroll within the figure to inspect its original labels and connections.
Figure: the observed audit-and-correction cycle, drawn from the plugin’s own Run Page Audit / Page Relationships / Edit workflow.
Both paths feed the same human review step, and nothing reaches the public site automatically: frontend hreflang output is a separate, explicitly-enabled switch (off by default), so a full audit cycle can run — scan, match, review, correct — without any risk of publishing an unreviewed relationship.
13. Audit Checks
What an audit of this kind should check, and which of these are confirmed as implemented in this specific system versus not documented:
| Check | Status in this project | Example failure | Severity |
|---|---|---|---|
| Source page exists | Confirmed — only published, non-excluded Pages are scanned | Deleted page still referenced elsewhere | High |
| Target translation exists | Confirmed — exact_slug / hierarchy / title / missing matching | No French page found for an English page | High |
| Target URL resolves | Confirmed — resolution fallback chain (network sites); live HTTP check (external CN site) | URL returns 404 or never resolves | High |
| Target page is published | Not documented as a distinct check beyond URL resolution | Draft page treated as live | Medium |
| Correct language/region assigned | Confirmed — fixed per-language columns; domain check for zh-CN | pt-BR URL saved under the wrong column | High |
| hreflang relationship exists | Confirmed — this is what Phase 1 builds | No relationship recorded despite a live translation | High |
| Relationship is reciprocal | Partially — relationships are represented from the English anchor; independent reciprocal checks from each non-English site are not documented | FR page doesn’t point back to EN | Medium |
| Canonical is valid | Not documented — canonical tag handling is not part of this plugin’s described scope | hreflang and canonical disagree | Medium |
| No unnecessary redirect | Not documented as an explicit check | hreflang target is a redirect, not the final URL | Medium |
| No broken relationship exists | Confirmed indirectly — URL validation before save, plus the 2+ confident-language output gate | Relationship points at a non-existent page | High |
14. Admin / Operational Workflow
A technical SEO system like this needs an operational interface — a developer should not have to inspect database records by hand every time a relationship needs checking or fixing. The confirmed features of this system’s admin interface:
A “Configured Sites” status table showing, per language, whether its blog ID currently resolves (a row shows “CHECK URL” if not — always true by design for zh-CN, since it can never resolve to a local blog ID).
A Page Relationships table, one row per English page group, with a compact status badge per language: EN (anchor), a check mark (exact-slug match), a warning mark (hierarchy/title match needing review), M (manual override), or a red “+ Add” (no match found).
Filters: All / Missing relationships / Needs review / Manual relationships / CN missing, plus search across title, URL or group ID, with pagination (25/50/100 per page).
An Edit panel: a per-language URL editor with a Confirm checkbox on needs-review rows, so a correct hierarchy/title guess can be approved for output without deleting and retyping an identical URL.
CSV export of the full current relationship map — one row per group, with URL, match type and score per language, plus missing and needs-review language lists.
15. SEO Architecture
hreflang, canonical, redirects, indexability, sitemaps and internal links are related but distinct systems, and it is worth being precise about the boundaries: hreflang does not replace a canonical tag, does not force a page to be indexed, and does not create a translation by itself. It only tells search engines about alternate language/region versions of a URL that must already exist, already be valid, and already be intended for indexing.
One piece of this is confirmed in the system’s output: it emits an hreflang="x-default" tag pointing at the group’s English URL, alongside the tag for each configured language.
The supplied documentation for this project does not describe canonical tag handling, XML sitemap integration, or internal-link auditing as part of this plugin’s scope. Those are adjacent SEO concerns that would need separate validation — they are flagged here as not documented / out of scope rather than assumed to be handled.
16. Common Failure Scenarios
| Scenario | What goes wrong | Detection | Recommended handling |
|---|---|---|---|
| English page exists, regional page doesn’t | No translation to link to | Confirmed: red “+ Add” badge in Page Relationships | Flag for translation or explicitly mark as intentionally untranslated |
| Regional page exists, relationship missing | hreflang undercounts real translations | Requires an audit run (full, or the single-page path) to discover | Run “Add / Refresh a Single Page” as new pages go live, full audit periodically |
| Relationship points to a deleted page | hreflang references dead content | General risk — not a specific documented incident in this project | Re-validate URLs on a schedule, not only at initial save |
| URL returns 404 | Broken hreflang target | Confirmed — addressed by the 1.3.4 URL-resolution fallback fix | Validate before save; re-check periodically |
| URL redirects | hreflang points at a redirect instead of the final URL | Not documented as an explicit check | Recommended addition: follow-and-flag redirect targets |
| Canonical points elsewhere | hreflang / canonical disagreement confuses search engines | Not documented — out of scope for this plugin | Recommended: validate canonical and hreflang together |
| Wrong language code | Content served to the wrong audience | Mitigated structurally — fixed per-language columns rather than free text | Keep language selection as a constrained list, not free text |
| Wrong region code | Same class of risk as above, region-specific | Mitigated by explicit domain check for zh-CN (must be cn.benchmarkemail.com) | Validate region-specific domains/paths explicitly |
| Regional page is noindexed | Shouldn’t be offered as an hreflang target | Confirmed — Yoast-noindexed pages are excluded from scanning entirely | Exclude at the input stage, as this system does |
| Relationship not reciprocal | One-way hreflang relationships confuse crawlers | Not documented as an independent check | Recommended: validate reciprocity from each non-English site’s own perspective |
| Duplicate relationships | Redundant or conflicting groups for the same content | Confirmed real bug, fixed pre-1.4.0 (every scanned page was becoming its own group) | Anchor exclusively on one canonical source (English), as this system now does |
| Relationship goes stale after a URL change | hreflang keeps pointing at an outdated URL | Confirmed real bug, fixed in 1.6.4 (a rejected wrong guess could silently reappear) | Store explicit “confirmed no translation” state, not just an absence of data |
17. Technical Example
A hypothetical example, using a clearly fictional domain:
English: https://example.com/features/
French: https://example.com/fr/features/
German: https://example.com/de/features/
Spanish: https://example.com/es/features/
In this example, the English page is the anchor for a relationship group. Suppose the French and German pages match on exact_slug (both are literally “/features/” under their language prefix) — high confidence, included in output automatically. The Spanish equivalent, by contrast, might live at a differently-worded slug like /es/funcionalidades/ — the system would only find it via hierarchy or title similarity, flag it as needing review, and withhold it from hreflang output until a human confirms the match. Once confirmed, the group would emit:
hreflang="en" → https://example.com/features/
hreflang="fr" → https://example.com/fr/features/
hreflang="de" → https://example.com/de/features/
hreflang="es" → https://example.com/es/funcionalidades/
hreflang="x-default" → https://example.com/features/
This is a fictional illustration only — no real client URL is referenced in this example.
18. Recommended Modern Architecture
CodingBeings Reference Architecture
This section is a forward-looking generalization of the pattern the Benchmark Email plugin already partially implements. It is clearly distinguished from the historical implementation above and is not confirmed as deployed.
Recommended reference architectureRecommended, not deployed
Forward-looking reference pattern from the supplied document; not confirmed as deployed.
View original diagram at full resolution
Scroll within the figure to inspect its original labels and connections.
Figure: a recommended reference architecture — a translation registry and relationship registry feeding a hreflang generator, an SEO validation agent, and monitoring/alerts.
Each stage maps conceptually to a capability the current system already has some version of: a translation registry generalizes the anchor_key/group_id relationship model; per-language sites map directly to the network’s regional subsites plus the external site; a relationship registry generalizes the current options-based storage; a hreflang generator is the confirmed Phase 2 output; and an SEO validation agent and monitoring/alerts layer would extend the current manual “Run Page Audit” workflow toward continuous, automatic revalidation. That last extension is a recommendation, not a confirmed capability — the documented workflow today is triggered manually.
19. Agentic SEO Opportunity
AI can be added to a system like this without replacing the deterministic validation that already makes it trustworthy. The pattern: a deterministic crawler/validator detects a problem, an AI diagnosis agent explains it and recommends a correction, a human approves the change, the change is applied, and deterministic revalidation checks the result — closing the loop.
Recommended AI-assisted SEO workflowRecommended, not deployed
Continuous monitoring returns to validation. AI recommendations do not bypass human approval.
View original diagram at full resolution
Scroll within the figure to inspect its original labels and connections.
Figure: recommended pattern for adding AI-assisted diagnosis without displacing deterministic validation or human approval of risky changes.
Concretely, an AI layer could help with: identifying likely translation relationships (this system already does a deterministic version of this via title-similarity scoring at a 0.62 threshold — an embedding-based matcher could plausibly improve recall on exactly this step); detecting suspicious language mismatches; explaining hreflang errors in plain language for non-technical stakeholders; prioritizing which problems to fix first; summarizing audit results; generating correction recommendations; and identifying pages missing regional equivalents.
The important constraint: AI should recommend, deterministic code should validate, and human approval should control risky or irreversible changes. This is not a new discipline for this system — it already requires a human to review matches and an explicit opt-in switch before anything reaches the public site. An AI layer would need to inherit that same discipline, not loosen it.
20. Security Considerations
General principles for a system that can alter what search engines see: avoid automatically changing SEO relationships without validation; log changes; keep audit history; provide rollback where possible; validate URLs before publishing; avoid infinite redirect loops; avoid generating hreflang for non-existent pages; restrict admin capabilities; sanitize inputs; escape output; and use capability checks for administrative operations.
What is confirmed in this project specifically:
Frontend output requires an explicit opt-in switch, off by default — nothing reaches the public site or search engines until a human turns it on.
hreflang is never generated for a page group with fewer than two confident languages, avoiding output built on unvalidated or unmatched content.
Manual overrides are stored independently of audit runs and survive re-auditing — a limited, real form of durability, though not a full change log with timestamps and authorship (not documented).
Clearing an override reverts a relationship to the last audit’s auto-detected state — a limited, real form of rollback.
CSV export was explicitly hardened against formula/CSV injection (CWE-1236) in version 1.5.0: any exported cell that starts with =, +, - or @ is prefixed so spreadsheet applications treat it as literal text rather than evaluating it as a formula.
What is not documented, and should be confirmed rather than assumed: whether administrative capability checks, input sanitization and output escaping, or CSRF protection follow standard WordPress plugin conventions throughout. These are standard requirements for any WordPress admin-facing plugin, but the supplied README does not describe them explicitly, so they are noted here as to be confirmed rather than claimed.
21. Performance Considerations
A large multisite network can contain a great many pages, so the general principle is: don’t run expensive full-network validation on every page request. Recommended approaches in general include scheduled audits, background processing, caching, incremental validation, batch processing, database indexes, and targeted revalidation after content changes.
What is confirmed in this project specifically:
A two-layer cache: a network site option as the source of truth, plus a generated PHP array file that PHP’s opcache keeps compiled in memory — avoiding a database query on every frontend page load across all eight network sites plus every REST call from the external Chinese site’s companion plugin. If the file ever becomes unwritable or goes missing, the system automatically falls back to the database option.
The output index is rebuilt only when the audit runs or a relationship is saved, removed or toggled — not on every page load.
Targeted, incremental revalidation: the “Add / Refresh a Single Page” path (added in 1.7.0) exists specifically to avoid a full network-wide rescan when only one new page needs relationships.
What is not documented: whether audits run on a schedule or purely on manual trigger. The documented end-to-end usage flow describes clicking “Run Page Audit” by hand, with no mention of a cron schedule — so scheduled/background auditing is noted below as a recommended future addition, not a confirmed feature.
22. Actual Project Outcome
The work shifted hreflang management from a largely manual, easy-to-drift SEO concern into a structured, auditable relationship-management system: every English page’s regional equivalents are tracked as reviewable data with a defined confidence level, rather than as hand-written tags scattered across nine sites.
Frontend hreflang output and the mega-menu language-switcher localization are both explicitly gated behind human review and an opt-in enable switch, so nothing reaches search engines or site visitors until the underlying relationship data has been checked.
The system’s own version history — 1.2.1 through 1.7.2 — documents an unusually well-instrumented engineering process: each release fixes a specific, named defect (a false-negative URL-validation pattern, a stale override that didn’t persist correctly, diagnostic output leaking into unrelated generated files like llms.txt) rather than relying on broad, unverifiable claims of improvement.
No SEO traffic, ranking, or indexing figures are reported in this section, because none were supplied as part of this project’s documentation.
23. Lessons Learned
International SEO is an architecture problem, not a tagging problem — most of this system’s real engineering effort went into relationship matching, storage and caching, not into the <link> tag output itself, which is a handful of lines once the underlying data is trustworthy.
hreflang depends on accurate content relationships — the confidence-gating rule (excluding needs-review matches from output until confirmed) is a direct engineering acknowledgment of this.
Translation and SEO cannot be treated as fully separate systems — this project had to explicitly define its boundary with the site’s existing translation plugin for Posts, rather than duplicating or ignoring it.
WordPress Multisite requires careful cross-site relationship management — most of this plugin’s internal complexity (anchor keys, group IDs, per-site URL resolution fallbacks) exists specifically because Pages live as independent objects on independent sites within the network.
Missing translations must be distinguishable from broken translations — the badge system and the “confirmed no translation” override (fixed in 1.6.4) directly encode this distinction rather than collapsing both into “no data.”
URL validation is essential — the 1.3.4 URL-resolution fallback fix and the external site’s live-URL check both exist because naive validation produced false negatives on real, valid multisite URLs.
Canonical and hreflang must be considered together — noted here as a recommendation, since canonical handling is not documented as part of this system’s scope.
Automated auditing is more reliable than manual inspection — illustrated by the shift from “every scanned page becomes its own group” (a pre-1.4.0 bug) to anchored, deduplicated groups.
AI can assist diagnosis, but deterministic validation should remain authoritative — consistent with how this system already treats human review as mandatory before anything ships.
International SEO systems should be treated as continuously changing data, not a one-time configuration — evidenced by how long the real changelog is: new edge cases (a footer language switcher built as hardcoded markup, a Posts page rendering in a different WordPress context than a normal Page, global query state getting clobbered by unrelated code later in a page render) kept surfacing in production long after the initial build.
24. CodingBeings Methodology
The general approach CodingBeings applies to international WordPress / hreflang engagements:
CodingBeings methodology
General methodology from the document, including recommended extensions; not a list of capabilities confirmed in the historical plugin.
View original diagram at full resolution
Scroll within the figure to inspect its original labels and connections.
Figure: map, inventory, identify, validate, build, automate, augment, revalidate.
25. Technology Stack
Only technologies confirmed by the project documentation are listed below.
| Layer | Technology | Purpose |
|---|---|---|
| Platform | WordPress Multisite | Hosts the English site and seven regional subsites in one network |
| Platform (external) | Separate WordPress installation | Hosts the Simplified Chinese site outside the main network |
| Language | PHP | Plugin logic, matching, validation, caching |
| Extension | Custom network-activated WordPress plugin | Audit, relationship storage, hreflang output, menu localization |
| Extension (companion) | Custom WordPress plugin (external site) | Fetches and renders tags/menu rewrites on the Chinese site via REST |
| Interop | WordPress REST API | Public read-only endpoint serving hreflang tag data to the external site |
| SEO | Yoast SEO (integration point) | Source of the noindex signal used to exclude pages from scanning |
| Caching | PHP opcache + generated PHP array file | Fast, database-free reads of relationship data on every frontend page load |
| Core hooks | wp_nav_menu_objects, language_attributes, template_redirect | Menu-switcher localization, per-site language attribute, early state capture |
| Data export | CSV | Full relationship map export, hardened against formula injection |