Seo Bundle Laravel Package

Product Decisions This Supports

• Structured-data coverage as a roadmap item. v1.6.0 adds faqPage, so the package now covers four schema types (blogPosting, service, breadcrumbList, faqPage). This lets you plan SEO surface area (article rich results, breadcrumbs in SERPs, FAQ blocks, service/entity markup) as a single track rather than a per-page bespoke effort.
• Build vs. buy on SEO plumbing. The package is a thin renderer, not an SEO platform: you still own content modelling, markdown rendering, sanitisation, and URL/canonical strategy. Buy-in cost is low; the value is consistency of output shape across every template.
• Fail-fast as a product-quality decision. Malformed data now throws an InvalidArgumentException naming the expected shape instead of silently rendering nothing. This converts "invisible SEO regression discovered at next audit" into a build-time/CI-time failure — a defensible engineering investment, and a decision to make explicitly: do you want schema errors to break the page in production, or fail loudly in tests only?
• Guardrails against low-value markup. Empty breadcrumbList/faqPage lists render nothing (Google rejects entries-less blocks), and a Service with no description no longer emits "description": "". This reduces junk markup that dilutes crawl budget and can trigger validation warnings in Search Console — fewer false "we shipped schema" claims in reporting.
• Prioritising which types to wire up next. Unknown types throw with the valid list, which makes the supported surface discoverable and gives you a clean, low-risk path to sequence adoption: breadcrumbs (broad, low effort) → blogPosting (content team) → faqPage (support/marketing) → service (commercial pages).
• Test and QA leverage. Because invalid input throws with a descriptive message, QA can assert schema presence/absence per page template in automated tests instead of manual Rich Results checks — a measurable reduction in manual SEO QA per release.

When to Consider This Package

Adopt when:

• Your Laravel app renders server-side pages where structured data is a standing requirement, and you want one consistent call signature (schema_org_json_ld('type', data)) rather than hand-written JSON-LD in Blade templates.
• You have (or are building) a test suite and can place schema assertions in CI — the new exception behaviour is only a benefit if failures surface before production.
• Your content pipeline already validates or models the required shapes (blogPosting behind a BlogPostingSeoInterface, service with a string title, faqPage/breadcrumbList items with the expected keys), so the strictness is a safety net rather than a constant source of exceptions.
• You need only the four supported types and are content to own everything around them (markdown → HTML, sanitisation, escaping, canonical URLs, @id linking).

Look elsewhere or hold when:

• You need schema types beyond these four (Product/Offer, Organization, Event, Recipe, VideoObject, HowTo, LocalBusiness) — you'll be writing raw JSON-LD anyway, so a generic JSON-LD helper or a fuller schema library is a better fit.
• You cannot tolerate runtime exceptions on user-facing pages and have no middleware/try-catch strategy; the strict-throw behaviour is a genuine availability risk if data is user-generated or CMS-authored by non-engineers.
• You rely on a framework-integrated SEO suite (meta tags, sitemaps, redirects, canonical management) and would rather not stitch together multiple packages.
• FAQ rich results are a primary goal: eligibility for FAQ snippets is narrow (Google has restricted them largely to authoritative government and health sites), so validate the SEO payoff before committing roadmap effort. The markup is still useful for entity clarity, but don't promise snippet wins.
• Your stack is not Laravel/PHP, or you'd be pulling in a framework dependency for a few dozen lines of JSON encoding.

How to Pitch It (Stakeholders)

For executives: This release makes our structured data trustworthy. Previously, a malformed SEO block rendered nothing and we only found out at the next audit — a silent loss of search visibility. Now bad data fails loudly and early, and the new FAQ block lets us mark up question-and-answer content we already publish. Net effect: fewer invisible SEO regressions, more consistent rich-result coverage, and less manual QA per release. Cost is contained — it's a small, focused library, not a platform commitment.

For engineering: v1.6.0 adds schema_org_json_ld('faqPage', items) for {question, answer} pairs, with answer passed through as HTML — markdown rendering and sanitisation stay in the application, so XSS responsibility is unchanged and explicitly ours. All types now validate: wrong shapes throw InvalidArgumentException with the expected structure, unknown types throw with the valid list, empty breadcrumbList/faqPage render nothing, and Service omits description when absent instead of emitting an empty string. Practical implications: wrap calls at trust boundaries (CMS input, user-generated content) or validate upstream, add per-template schema assertions to the test suite, and treat the exception messages as the contract when authoring data. No breaking API changes to existing valid call sites, but any code currently relying on silent no-op behaviour for bad data will now throw — audit those call sites before upgrading.