Json Ld Laravel Package

Product Decisions This Supports

• Sequencing the rich-results roadmap. Structured data is one of the few organic-growth levers that ships without a content or design cycle. This package makes JSON-LD output for Article, Product, BreadcrumbList, Organization, Recipe, Book, and MediaObject a template-level task, so it directly informs which page types to make eligible next. Recommended order: Product/Offer and Article first (broadest coverage and clearest CTR upside), BreadcrumbList second (cheap, site-wide, low risk), vertical types (Recipe/Book/MediaObject) last and only where the catalog genuinely holds every required field.
• Build vs. buy — and the honest answer is "assemble, don't buy." The real alternative isn't a competitor package, it's hand-writing json_encode() arrays inside a Blade partial. This package wins on consistency and reviewability (a fluent, typed builder rather than nested arrays reinvented per view), not on capability. Justify it as a two-to-three-day convenience decision, not a strategic platform dependency.
• A content-model pressure test. Attempting to emit valid Recipe or Product markup immediately exposes missing data — no author, no image, no price/availability, no rating. That's a useful forcing function for deciding whether those become first-class fields on the content model, and it's a decision worth making deliberately rather than by accident.
• A measurable bet with a kill criterion. Rich-result eligibility is observable in Search Console enhancement reports and in impression/CTR deltas on affected templates. That makes this rare among small SEO tasks: a genuinely attributable experiment with a clear stop signal if pilot templates don't move within a quarter.
• Explicitly not supported: schema validation strategy, CMS-level structured-data governance, or automated schema generation across thousands of heterogeneous templates. This is a renderer, not a structured-data platform. Also note the Book/MediaObject/Recipe additions in 0.0.19 are schema.org output types, not application entities — resist letting this be scoped as a content-modeling initiative.

When to Consider This Package

Consider it when:

• The app is Laravel (auto-discovery service provider, Blade-friendly) and renders server-side pages you want eligible for rich results.
• You only need the common schema.org types it ships with, and "validated by Google's Rich Results Test" is the bar — not exhaustive schema coverage.
• You want one consistent, reviewable way to build nested schema objects across several templates instead of each developer inventing their own array shape.
• Engineering can own and wrap it: one SchemaPresenter per type, plus a feature test that decodes the rendered JSON-LD and asserts required keys and no empty values.

Look elsewhere or defer when:

• Maintenance risk is the headline. Last release March 2020, pre-1.0 (0.0.19), ~148 stars, zero dependents, weak opportunity signal. Before committing, Engineering must confirm composer.json constraints resolve against your current Laravel/PHP versions — a 2020 package may declare Laravel 6–7-era illuminate/support bounds. If it doesn't install cleanly, the honest answer is "vendor a ~200-line presenter"; BSD-2-Clause makes that legally trivial and the codebase is small enough to fork in an afternoon.
• You want a maintained default. spatie/schema-org is actively maintained, more widely adopted, and covers more types. The comparison costs roughly a day — worth spending once, before anyone commits to a plan.
• You need types beyond its coverage, first-class @graph composition, multi-language handling, or built-in validation.
• You need a vendor with a security policy and release cadence — this doesn't credibly offer one.
• You're on a non-Laravel stack, or output is generated client-side (SPA/headless), where a JS-side library fits better.

Guardrails to set as PM: pin the exact version (0.0.19), wrap the package behind an internal interface so replacement is a one-file change per type, keep it out of controllers and Eloquent models, and treat it as an implementation detail that never appears in architecture or vendor-risk discussions. Add a validation gate (Rich Results Test + Schema Markup Validator per template, recurring Search Console check) and a written convention doc — one presenter per type, one @graph per page, stable @ids, no empty values, never fabricated ratings or availability — so the next developer doesn't re-derive it. Budget a few hours per Laravel major upgrade to confirm it still installs.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost SEO experiment, not a platform investment. Structured data is what makes our pages eligible for rich results — review stars, product prices, breadcrumb trails in search. We can pilot it on two templates (product detail and article) for roughly half a day of engineering each, measure the impression and CTR impact in Search Console, and expand or stop based on that data. Total exposure is a few days of work and no vendor contract. The main caveat is that the underlying library hasn't been updated since 2020, so we treat it as internal code: version-pinned, wrapped behind our own interface, with a documented fallback to either a maintained alternative or a small in-house replacement. Neither path changes the plan or the timeline.

For engineering: The package gives fluent, schema.org-friendly builders and Laravel facade/helper integration; it does not give model-to-schema mapping, @graph composition, escaping, or validation — those are ours, and they're the parts that actually determine whether rich results appear. Confine usage to a presenter layer (ArticlePresenter, ProductPresenter, …) that returns a plain array; Blade renders that array once in the layout head with JSON_HEX_TAG (never {{ }}, which entity-encodes and invalidates the block). Compose multiple entities into a single @graph with stable @ids rather than stacking script tags — duplicated markup is the most common cause of silent non-appearance. Strip null/''/[] recursively before encoding, use ISO 8601 dates and absolute canonical URLs, and test the rendered HTML rather than the presenter. First milestone: one template, one type, validated, merged. Not breadcrumbs on twelve templates.

The one thing to say out loud: the highest-severity failure mode here isn't technical, it's governance. Never emit placeholder values — no invented aggregateRating, no InStock for out-of-stock items, no stale prices. Fabricated structured data is a manual-action risk against the domain. If a template lacks the fields a type requires, that's a content-modelling decision to escalate, not a default to fill in.