Seo Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for editor-facing SEO tooling. This bundle is best read as a requirements checklist, not a dependency. It enumerates the minimum viable metadata surface a content team expects from a CMS admin: per-entity title, meta description, keywords, OpenGraph fields (title, description, image, type), and a free-form "custom header" field for tags the product team can't anticipate (verification tags, pixels, regional analytics such as Metriweb).
• Scope definition for an "SEO fields" epic. The field list is a ready-made acceptance-criteria draft for whichever implementation you actually ship — a Filament/Nova panel, a translatable JSON column plus admin form, or a headless metadata endpoint. It saves a discovery cycle with the content/marketing stakeholder.
• Roadmap prioritization: metadata vs. technical SEO. The bundle covers only authoring and header injection. It does not cover sitemaps, canonical URLs, hreflang, structured data/JSON-LD, redirects, or robots directives. Deciding to adopt it implicitly defers all of those — which is usually the wrong trade for a modern product, since the authoring side is the cheap 20% and the technical side is where organic traffic actually moves.
• Tracking/analytics flexibility decision. The "free field for custom header information" is an explicit product decision worth copying: rather than shipping a hard-coded integration per analytics vendor, expose an escape hatch. Given the original target (Metriweb — a Belgian audience-measurement service), it's also a reminder that vendor-specific tag integrations age badly and should be configuration, not code.
• Vendor/legacy risk assessment. Last release 2014, 24 stars, zero dependents. This supports a "do not adopt" call and, if inherited in an existing codebase, a replace or delete decision on the roadmap rather than a maintain one.

When to Consider This Package

Consider it only in these narrow cases:

• You are maintaining a legacy Symfony 2.x + Kunstmaan CMS installation and need metadata editing without building it. Note the mismatch up front: this is a Symfony bundle with no Laravel service provider, config publishing, or Eloquent integration — it is not a drop-in for a Laravel app, despite the PHP ecosystem overlap.
• You want prior art on field naming, entity-level metadata modelling, and admin UX for SEO forms before writing your own.
• You need a documented example of a "custom header tags" escape hatch for a multi-vendor tag-management problem.

Look elsewhere — or build — when any of the following hold:

• Modern PHP or Laravel. No PHP 8 compatibility, no maintenance, no security patching. A framework-version-locked dependency from a decade ago is a liability, not a shortcut.
• You need technical SEO depth. No JSON-LD/schema.org, sitemaps, canonicalisation, hreflang, or redirect handling. Integrate a maintained SEO package (e.g. spatie/laravel-sitemap-class tooling for the technical layer) plus a small in-house metadata model.
• You need multi-language/cross-locale metadata. The bundle assumes a single set of values per entity; hreflang-aware authoring is out of scope.
• Compliance and consent matter. A free-form header-injection field is a straightforward way to ship third-party tags that bypass your consent management platform. That needs governance, not a raw textarea.
• Headless / API-first architecture. The value here is coupled to server-rendered Symfony templates; in a decoupled front end the metadata must be a first-class API payload.

How to Pitch It (Stakeholders)

Executive summary: We evaluated kunstmaan/seo-bundle for SEO and social-sharing metadata in our content platform and recommend not adopting it as a dependency. It is an unmaintained Symfony bundle — last release April 2014, 24 GitHub stars, zero dependent projects — and it targets a CMS stack we don't run. Adopting it would add legacy framework lock-in, no security patching, and would still leave sitemaps, canonical URLs, structured data, and multi-language metadata unaddressed.

What it's still worth: it gives us a validated, field-level specification for the editor experience — titles, meta descriptions, keywords, OpenGraph fields, and a custom-tag escape hatch — which we would otherwise spend a discovery cycle deriving from marketing. The custom-header field in particular reflects a useful product principle: vendor-specific tag integrations should be configuration, not code.

Ask: treat this as competitive/prior-art research rather than engineering work. Approve a small in-house metadata model (entity fields + admin form + API/serializer output) and a separate decision on the technical SEO layer. If any existing service still depends on this bundle, that is a remediation item for the roadmap, not a maintenance commitment.

Engineering caveat to flag: the package is Symfony, not Laravel — any assumption that it "just installs" is wrong, and the 2014 vintage means PHP 8 incompatibility is expected rather than incidental.