Seo Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for SEO admin tooling. This package is best treated as a requirements reference, not a dependency. It shows the shape of an admin-managed SEO layer: per-entity meta/title/description overrides, canonical URLs, sitemap generation, robots directives, and redirect management surfaced through an admin UI. That artifact is useful when scoping an in-house SEO module even if you never install the code.
• Stack fit — the decisive filter. Despite the framing, this is a Symfony bundle built around SonataAdminBundle, not a Laravel package. Any Laravel roadmap item should immediately disqualify it. For a Laravel codebase the practical equivalents to evaluate are artesaos/seotools, spatie/laravel-sitemap, and a custom Nova/Filament admin panel.
• Roadmap sizing for a Symfony/Sonata legacy estate. If you maintain a Sonata-based admin, this can inform an estimate for "editors can manage SEO without a deploy" — the highest-value slice is usually meta overrides plus sitemap automation, not the full bundle.
• Risk-weighted adoption scoring. With 1 star, 0 dependents, and an opportunity score of ~21.7, this fails a standard dependency health gate (maintenance, community, security patch cadence). That is itself a decision output: deprioritize, do not standardize, do not let it into a shared platform baseline.
• Content/SEO ownership decisions. The underlying capability — letting marketing own metadata rather than filing engineering tickets — is a workflow decision worth making regardless of package. This bundle is evidence that the pattern is common enough to build once.

When to Consider This Package

Consider it only when all of the following hold:

• You are on Symfony, not Laravel (hard requirement).
• You already run SonataAdminBundle and want SEO editing inside the existing admin rather than a new surface.
• The project is internal, low-traffic, or legacy, where a small unmaintained dependency is tolerable.
• You are prepared to fork and own it — assume no upstream fixes, no security patches, no answers to issues.

Look elsewhere when:

• You are on Laravel. Not adaptable without a rewrite; the Sonata coupling is structural, not cosmetic. Use the Laravel ecosystem packages named above.
• You are on Symfony without Sonata. The admin integration is the bundle's main value; without it you are pulling in a dependency for logic you'd rewrite in an afternoon.
• Dependency health is a gate. 0 dependents and 1 star mean effectively no community validation and no CVE response path — a blocker for anything customer-facing, regulated, or long-lived.
• You need sitemap/redirect edge cases at scale (multi-domain, hreflang matrices, large sitemap sharding). Scope-creep here exceeds the bundle's footprint.
• You need vendor support or SLAs. None exist.

How to Pitch It (Stakeholders)

To executives: We evaluated this as an SEO capability for our admin tooling and are recommending against adoption. It targets a different framework (Symfony/Sonata, not Laravel), has essentially no user base, and no maintenance signal — meaning we would inherit full ownership and security responsibility on day one. The useful output is a feature checklist for the SEO admin work already on our roadmap, which lets us scope that build with more confidence at near-zero cost.

To engineering: Treat it as a design reference, not a dependency. Two concrete takeaways: (1) the valuable primitive is an entity-scoped SEO override record editable from the admin, with sitemap and canonical generation derived from it; (2) the Sonata coupling makes it non-portable, so we should implement the same model natively against our stack — Filament or Nova on Laravel, plain Symfony forms if we stay there. Proposed next step is a one-day spike to size the meta-override + sitemap slice; no integration work and no fork unless a Sonata project specifically requests it.