Advanced Seo Laravel Package

Product Decisions This Supports

Build vs. buy for the SEO control layer. The package supplies the whole vertical slice an SEO feature normally requires: a per-context configuration object (SeoSet per collection, taxonomy, and site), per-site localizations, and a rendering cascade that merges site defaults → collection/taxonomy defaults → entry/term overrides. That merge order is the product decision, already made: editors set brand-wide rules once, then deviate deliberately at the page level. Building this in-house reliably is a multi-sprint effort once you account for the UI, inheritance, and multi-site — so the realistic alternatives are "buy this" or "ship a half-feature."

Editor-facing SEO without developer tickets. The pitch in the description — "the addon editors love and developers won't outgrown" — maps to a concrete roadmap goal: move title/meta/social/schema authoring out of the developer backlog and into the publishing workflow. The value is measured in tickets deflected, not features shipped.

Multi-site and localization roadmap. SeoSetLocalization per site means hreflang-style, per-market SEO metadata is a configuration exercise rather than a schema migration. If the roadmap includes new locales or regional sites, this package makes that incremental instead of a project.

Structured data as a product surface. The spatie/schema-org dependency means rich-result eligibility (Article, Product, FAQ, Organization, etc.) is available without inventing a schema layer. That is directly tied to measurable search outcomes — review stars, breadcrumbs, article cards — and is far easier to justify to stakeholders than meta-tag plumbing.

Social preview generation. spatie/browsershot implies server-side image rendering for Open Graph / share cards. This is a visible, demoable differentiator, and it's the kind of feature that otherwise gets dropped for lack of an owner.

Data architecture and scale decisions. The dual-driver design (file/Stache by default, Eloquent optional) is a genuine PM-relevant fork: it defers the "do we need a database for content?" decision and lets the same SEO feature survive that migration. If content volume or query complexity is on the roadmap, this package won't block the move.

Caching and performance budgeting. Blink caching with namespaced keys (advanced-seo::{type}::{handle}::{suffix}) and prefix-based flush means SEO rendering is not a per-request tax. That removes "SEO will slow the site down" as an objection in planning.

A design principle worth adopting internally. SEO output is computed state, never stored on entries. That's a defensible architectural stance to adopt for any adjacent metadata work — it keeps content records clean and makes defaults actually changeable retroactively.

When to Consider This Package

Consider it when:

• You are on Statamic 6 with Laravel 12 and PHP 8.4, and are prepared to stay on that edge. The version matrix is not forgiving; this is a package that expects a modern stack.
• SEO metadata needs to be editor-owned and inherited — many collections, taxonomies, or sites where per-entry hand-authoring doesn't scale and consistency matters more than page-level freedom.
• You are running or planning multi-site / multi-locale content and need per-site SEO variants from one control surface.
• Structured data and social previews are on the roadmap and you'd rather compose existing primitives (schema-org, Browsershot) than build them.
• You have Statamic-competent engineering capacity to read the facade, the cascade, and the contracts — and to review upgrades.
• A small dependency surface with a clear domain model is worth more to you than a large ecosystem of integrations.

Look elsewhere when:

• You are not on Statamic. This is a first-class Statamic addon, not a generic Laravel SEO package; on a plain Laravel or other-CMS stack it is not applicable, and forcing it is a category error.
• You need vendor SLAs, security review sign-off, or enterprise support. At ~18 stars this is a single-maintainer-scale project. The bus factor is the headline risk, not code quality.
• Your stack is behind PHP 8.4 / Laravel 12 / Statamic 6, or you have a conservative upgrade cadence. Pin and evaluate, or defer.
• You need SEO beyond on-page metadata — keyword research, rank tracking, backlink monitoring, content audits, or a redirect-management suite. None of that is here; that's a separate tooling decision.
• You require deep CMS-agnostic portability or expect to leave Statamic. The domain model is Statamic-shaped by design.
• You need breadth of third-party integrations (analytics vendors, marketing suites, translation platforms). You'll be writing those adapters yourself.

Adoption guardrails I'd set: pin the version, run a spike on a representative multi-site collection set to validate the cascade behaves as the docs claim, confirm the Eloquent path only if you actually need it, and write a two-page internal runbook for the facade and SeoSet model so the team isn't dependent on the upstream maintainer's availability.

How to Pitch It (Stakeholders)

For executives — one paragraph. This is a small, focused add-on that gives our editors direct control over how our pages appear in search and on social, with brand-wide defaults they can override per page, per section, and per market. It replaces work we would otherwise commission from engineering, it's the layer that makes us eligible for rich search results (review stars, article cards, breadcrumbs), and it generates share images automatically rather than through design requests. The trade-off is honest: it's an early-adopter dependency with a low public profile and a demanding version baseline, so we should adopt it deliberately — pinned, spiked, and documented — rather than assume it's a commodity.

For engineering — the technical case. It's a proper Statamic package, not a wrapper: a real domain layer (SeoSet / SeoSetConfig / SeoSetLocalization), a documented merge cascade, an explicit Seo facade, contracts with both Stache and Eloquent implementations, Blink caching with prefix-based invalidation, and Pest-based tests. It composes spatie/schema-org and spatie/browsershot instead of reinventing them. The opinion that matters most: SEO is computed state, never stored on the entry — we should steal that stance regardless of whether we adopt the package.

For the product team — what it changes day to day. Editors stop filing "please update the meta description" tickets. Defaults mean new pages are never accidentally blank in search results. Multi-site means launching a new locale no longer means a metadata migration.

The risk to state plainly, and the mitigation. ~18 stars and a single-maintainer profile means we are buying a design, not a support contract. Mitigation: pin the version, keep the integration behind our own thin boundary so the package is replaceable, validate the cascade in a spike before committing to it in a launch plan, and treat any upgrade as a scheduled task rather than a routine composer update. If those three conditions are acceptable, the build-vs-buy math favors buying decisively.

Recommendation: Adopt for a bounded pilot on one multi-site collection set with real editors, with a go/no-go gate on cascade correctness, editor comprehension, and upgrade effort. Proceed to full rollout only if the pilot shows editors shipping SEO changes unaided — that is the outcome the whole purchase is justified by.