WordPress product · Headless infrastructure
Seo & Social
Reliable metadata contracts for headless WordPress
A public plugin that gives editors controlled SEO, social, schema, FAQ, Open Graph image, and LLMs source-data workflows, then exposes a predictable REST contract to a separate frontend.
The problem
In a traditional WordPress site, an SEO plugin can print tags directly into the document head. In a headless build, WordPress and the public frontend are separate systems. Editors still need familiar controls, but the consuming application needs stable, resolved data rather than assumptions about WordPress rendering.
The product challenge was to define that boundary clearly: what editors save, how global defaults and local overrides resolve, which data is public, and what the frontend must render. That contract also had to survive permissions, malformed input, compatibility changes, packaging, and real editorial use.
The data workflow
A small, explicit contract connects editor-owned WordPress data to a separately owned public frontend.
site-wide settingspage-level valuespredictable payloadmetadata + public routesProduct decisions
The implementation keeps editorial control, resolved output, frontend ownership, and generated assets within clear boundaries.
Separate stored values from resolved output
The plugin keeps editor-entered values distinct from the final fallback-resolved payload, so REST consumers receive predictable data without hiding what was actually saved.
Keep rendering with the URL owner
WordPress provides structured source data while the separate frontend remains responsible for canonical URLs, metadata tags, schema markup, FAQ presentation, and public routes.
Control editorial and public access
Settings, content overrides, REST output, generated files, and operational actions use explicit capability and visibility rules instead of sharing one broad access model.
Constrain generated media and cleanup
OG image generation, public files, caches, uninstall behaviour, and compatibility checks are treated as lifecycle concerns rather than incidental implementation details.
The editor workflow
Editors manage global defaults and page-level overrides in WordPress while the consuming frontend renders the final result.
Quality evidence
Risk-based coverage follows the product from stored values and REST resolution through editor workflows and the downloadable ZIP.
The manual foundation established 24 risk scenarios and recorded findings separately from passes. Automation then covered the REST contract, admin workflows, regressions, and packaged release, rather than only isolated implementation units.
Testing changed the product
Dynamic FAQ rows reused a placeholder editor ID. The first rich text editor initialized correctly, while later answers could fail to initialize independently. Foundation testing exposed the defect before it could be treated as acceptable editor friction.
I documented the behaviour in issue #1, implemented the fix in pull request #3, and added focused regression coverage. The FAQ checks passed 3/3, the full Playwright suite passed 18/18, and PHPUnit passed 66 tests with 262 assertions before the change shipped in v1.1.0.
Release confidence
The downloadable ZIP is the product under test. Publication depends on the complete verification workflow, not only source checks.
- Composer and npm dependency audits
- PHP syntax and WordPress Coding Standards
- WordPress PHPUnit integration suite
- Romanian translation validation
- Deterministic ZIP and manifest verification
- WordPress Plugin Check
- Clean packaged-plugin activation and version check
- Eighteen Playwright admin tests
- WordPress and PHP compatibility matrix
Release confidence comes from validating the same deterministic archive a user downloads: its manifest, dependencies, activation, version, admin workflows, coding standards, and compatibility.
View release workflowsOutcome
Seo & Social is a public, downloadable WordPress plugin with a documented editor workflow, a predictable headless REST contract, reproducible packaging, and automated regression coverage.
More importantly, the repository shows how the product was made trustworthy: risks are named, defects become regression tests, and the release artifact passes explicit gates before publication.