Seo Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the SEO metadata layer. The recurring PM question — "do we hand-roll titles, descriptions, canonicals, Open Graph and sitemaps, or take a dependency?" — is exactly what this package lets you frame. The domain logic it covers (fluent metadata API, OG/Twitter cards, canonical URLs, sitemap and robots helpers, per-page overrides, Blade-friendly rendering) is low-differentiation, well-understood work. That argues for a solution rather than bespoke novelty — but not for this one. Use it as the benchmark the eventual choice has to beat.

• Scoping the SEO epic and writing the spec. The highest-value use is as a requirements enumeration: what fields do editors set per content type, do we need per-locale metadata, pagination-aware canonicals, hreflang, structured data/JSON-LD, sitemap pagination and refresh cadence. Walk its feature surface once, convert it to acceptance criteria, then disregard the code. This is a few hours of reading that can compress a week of design debate.

• Prioritization against the acquisition strategy. Whether metadata is MVP or post-launch is decided by channel mix, not by this package. If organic search is a stated growth channel, correct canonicals, unique titles and sitemap coverage are table stakes and ship early. If traffic is paid or referral-led, defer — and say so explicitly rather than letting an "SEO bundle exists" artifact imply commitment.

• Dependency-risk and tech-debt triage. Archived, 0 stars, 0 dependents, score 0.015, no maintainer, no security channel. If it appears anywhere in composer.lock (including transitively), it belongs on the roadmap as an unscheduled-work / exit item, budgeted with the SEO epic — not as a feature line.

• Framework strategy decision. It is a Symfony bundle mis-catalogued as a Laravel package: no service provider, no compiler passes, no Blade directives — Symfony bundles.php, an Extension/Configuration pair, Twig extensions and event-dispatcher wiring. The decision it actually informs is "our SEO layer should be Laravel-native or framework-agnostic behind an internal contract," which is a durable architectural call worth making once.

• Interface contract as the real deliverable. The portable value is the shape of the API: setTitle, setDescription, setCanonical, addStructuredData, render(). Committing to that interface, with explicit metadata in the database so editors can change SEO without a deploy, decouples the roadmap from whichever library or hand-rolled code ends up underneath.

When to Consider This Package

Consider it as a reference implementation only — read, don't require:

• You are drafting an SEO requirements doc and want a concrete, opinionated checklist of metadata fields and sitemap behaviors to argue over with engineering.
• You need to build a credible case for declining a "just use a bundle" suggestion from a stakeholder or a search result.
• You inherited it (on Symfony, not Laravel), in which case the work item is assessed for removal, not adoption.
• You want a cheap sanity check on edge cases — URL normalisation, duplicate canonicals, attribute escaping, pagination — before your team rediscovers them in production.

Look elsewhere — decisively — when any of these hold:

• You intend to ship it. Archived means no security patches, no CVE triage, no compatibility work for PHP 8.3/8.4 or new Laravel majors. Zero dependents is the strongest signal: nobody has validated it in production, so you would be first, on an unmaintained base.
• You are on Laravel. Wrong artifact, not a rough fit. Bridging requires a Symfony kernel; forking and porting is 2–3 weeks of work that ends with you owning a package.
• SEO is revenue-relevant. Rankings are directly observable and SEO regressions are silent — crawlers de-index over weeks rather than throwing errors. That demands a maintained dependency with an active tracker, or a thin layer you control.
• You face a security review or compliance questionnaire. License terms, test coverage, last-commit date and outbound-HTTP behavior are all unestablished; an archived repo cannot be patched upstream.
• Maintained alternatives exist. For Laravel: framework-native metadata plus a maintained SEO package. Compare on last release date, issue responsiveness, framework version support and test coverage — not on feature lists, which are commoditized.

Adoption gate, if pushed: require a written answer to "who fixes a CVE here in 18 months?" If the answer is "us," you are budgeting a permanent fork with no upstream to rebase against — and the honest comparison will favor roughly a few hundred lines of metadata handling against your own models.

How to Pitch It (Stakeholders)

For executives. This is a small, abandoned SEO add-on: no maintainers, no users, no updates. I am not recommending adoption. I am flagging two things. First, SEO metadata — page titles, descriptions, canonical URLs, social cards, sitemaps — is real product work we will need regardless of channel mix, and this package is a useful checklist so we don't miss fields. Second, the build is genuinely small: days, not a quarter, provided we scope it before the content model is frozen. If it turns out to be somewhere in our stack, I will come back with a removal plan and a date.

For engineering. Treat rz/seo-bundle as read-only reference material. It is archived, 0★, 0 dependents, and it is a Symfony bundle — the wrong artifact for a Laravel codebase; there is no provider, middleware or Blade integration to reuse. Concrete asks: (1) confirm via composer.lock whether it is transitively present anywhere, and if so fold removal into the SEO epic rather than treating it as standalone work; (2) when we build, commit to an internal SeoManager-style contract with the metadata model explicit in the database, so the implementation is swappable and editor changes don't need a deploy; (3) target framework-native mechanisms — Eloquent attributes/accessors, route middleware, a queue-driven chunked sitemap generator with a cached index and scheduled refresh, since naive synchronous sitemap builds are the piece most likely to page someone at catalog scale. Design against the known failure modes: silent metadata regression, stale caches after content changes, unescaped attribute interpolation, sitemap endpoint 500s, and PHP-upgrade breakage with no upstream fix. Success criteria are measurable, not architectural: valid canonical tags sitewide, zero duplicate titles in Search Console, sitemap coverage matching the indexable URL set, and metadata editable by content editors without an engineer. Ship behind a config flag, enable per route, and diff rendered HTML against production before cutting over — no big-bang migration.

One line: Not a dependency — a spec. Read it to enumerate the SEO metadata we need, then build that thin layer ourselves or on something maintained.