Seo Bundle Laravel Package

Product Decisions This Supports

• Framework fit is the first decision, and this package fails it. Despite the "PHP package" framing, norsys/seo-bundle is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config/seo.php, no artisan publish tags. In a Laravel context, "adopting" it means either pulling in Symfony components or hand-porting its logic — so the real decision is build vs. buy a maintained Laravel equivalent, not adopt vs. skip.
• Build vs. buy for SEO metadata plumbing. The package's actual scope — centralized titles, meta descriptions, canonical URLs, robots directives, extensible per-page definitions — is a small, well-understood, non-differentiating concern. A PM can confidently rule it a build or commodity-buy decision, not a strategic bet. Expect 1–3 engineering days to implement an internal config-driven meta resolver (config defaults → per-route overrides → Blade component), which likely beats integrating a port of this package.
• Where SEO metadata lives architecturally. The underlying pattern — keep SEO out of controllers and templates, drive it from configuration — is a decision worth making regardless of vendor. This package is useful as a reference for the pattern, not as a dependency.
• Canonical and robots policy as product policy, not code. Canonicals for paginated listings, filtered/faceted URLs, and robots noindex on staging, search results, and thin pages are product+SEO decisions. Any tooling choice should be evaluated on how cleanly it expresses those rules — this package's config-first model does, but so does a 100-line internal implementation.
• Roadmap gaps to plan for explicitly. No structured data (JSON-LD/schema.org), no Open Graph/Twitter card management, no sitemap generation, no hreflang/i18n handling, no SEO regression testing in CI. If any of these are on the roadmap, this package does not shorten the path.
• Dependency governance decisions. Approving a dependency last released in July 2018, with 1 star, 0 dependents, MIT license, and no evidence of PHP 8 support should trigger a "no" under any reasonable third-party policy. The decision it supports is a dependency-policy precedent: set a maintainability bar (recent release, active issues, PHP version support) and apply it consistently.

When to Consider This Package

• Only if you are maintaining a legacy Symfony application (Symfony 3/4 era) that already depends on it, migration risk is high, and you have a concrete reason not to replace a working, isolated meta-tag layer. Even then, treat it as frozen: pin the version, isolate it behind your own service, and plan an exit.
• As a design reference, not a dependency: read the config schema for title/meta/canonical/robots to inform your own Laravel implementation. Cost is zero, risk is zero.
• Look elsewhere if any of the following are true — which covers essentially every current project:
  • You are on Laravel (this package provides no Laravel integration; the accompanying "getting started" notes are generic Vendor\Package boilerplate, not real documentation).
  • You need maintained dependencies: no release in ~7 years, no community, no security patch path, unverified PHP 8+ and modern framework compatibility.
  • You need structured data, OG/Twitter cards, sitemaps, or hreflang — out of scope.
  • You need support SLAs or a vendor to escalate to — single-maintainer, zero-adoption projects cannot supply this.
  • You are building anything multi-tenant or localization-heavy requiring per-tenant/per-locale metadata; there is no evidence of that support.
• Selection criteria to apply to the alternative you pick instead: Laravel-native package or internal module; a release within ~12 months; declared support for your PHP and framework version; test suite and CI; published config and documented extension points; per-route/controller overrides; and the ability to write SEO assertions into your own test suite.

How to Pitch It (Stakeholders)

Executives: SEO metadata (titles, descriptions, canonicals, robots) is undifferentiated plumbing — it should be cheap, correct, and stable, not a strategic bet. The candidate package is a Symfony library that hasn't shipped since 2018, has effectively no user base, and doesn't plug into our Laravel stack. I'm recommending we not adopt it: the cost of a small internal implementation or a maintained Laravel package is measured in days, and it removes an abandoned-dependency risk that would otherwise surface in security and compliance reviews. Either path is inexpensive; the only wrong answer is taking on a seven-year-stale dependency to save a day of work.

Engineering: The package's pattern is sound — centralize SEO in configuration, keep it out of controllers and Blade templates, expose per-route overrides and an extension point for custom tags. Its delivery isn't: Symfony-only, no Laravel service provider or publishable config, no PHP 8 verification, no tests we can trust, no maintainer to escalate to. Proposal: build a thin internal resolver (config defaults → route/controller overrides → a Blade component, with canonical and robots rules as config) and cover it with SEO assertions in our existing test suite. That gives us the same ergonomics, full ownership, and roughly 1–3 days of work — and it leaves the door open to swap in a vetted Laravel package later without touching templates.

Decision requested: approve the small build (or a short spike to evaluate maintained Laravel alternatives) and formally record that norsys/seo-bundle is out of policy for new dependencies.