Laravel Meta Laravel Package

Product Decisions This Supports

• SEO/metadata architecture: build vs. buy. f9webltd/laravel-meta is a small, single-purpose package for rendering page metadata (title, description, canonical, Open Graph/Twitter cards). Adopting it is a "buy" decision that avoids hand-rolling a meta-tag manager — low cost, low lock-in, and reversible in an afternoon.
• Roadmap sequencing for SEO/discoverability work. Because metadata rendering is a dependency for shareable links, social previews, and crawlability, this package unblocks SEO epics without requiring a dedicated build sprint. It lets you ship metadata support in the same release as the pages that need it.
• Multi-page/multi-tenant content surfaces. Relevant when many views, CMS-driven pages, or tenant-specific branding need consistent, overridable metadata — the "every page sets its own tags" problem rather than a one-off landing page.
• Platform support planning (new in 4.0.0). The package now requires PHP ^8.2 and Laravel ^11.0 / ^12.0 / ^13.0, and commits to tracking Laravel's official support policy going forward. This turns an infrastructure question into a roadmap input: it is now only viable for products on Laravel 11+, and the maintenance signal is stronger than before (an actively tracked support window rather than ad-hoc updates).
• Upgrade cost assessment. If you are on Laravel 10 or PHP 8.0/8.1, 4.0.0 is a hard break — the adoption decision becomes coupled to a framework upgrade, which is a platform decision, not a package decision.

When to Consider This Package

Adopt when:

• The application runs Laravel 11, 12, or 13 on PHP 8.2+ — the entire supported matrix as of 4.0.0.
• You need per-view or per-model metadata with sane defaults and per-page overrides, and you would otherwise be duplicating <meta> boilerplate across Blade templates.
• SEO/social preview output is product-visible and lightly customized — titles, descriptions, canonical URLs, OG/Twitter tags — rather than a deeply bespoke structured-data pipeline.
• You want a low-commitment dependency with a maintainer who has now formalized version-tracking against Laravel's support policy, which reduces the risk of being stranded on an unsupported framework.

Look elsewhere when:

• You are on Laravel 10 or below, or PHP < 8.2. 4.0.0 drops legacy support outright; there is no compatibility shim. Either stay pinned to 3.x (accepting an unsupported branch) or do not adopt.
• You need schema.org/JSON-LD generation, sitemap generation, hreflang matrices, or CMS-level metadata governance. This package handles tag rendering, not SEO strategy or content operations.
• Your metadata is fully static across the app — a handful of tags in a layout template is cheaper than a dependency.
• You require long-term vendor support or an SLA. This is a single-maintainer open-source package; the new support-policy commitment is a good signal but not a contract.

How to Pitch It (Stakeholders)

To executives: Metadata is what search engines and social platforms show about our pages — it drives click-through and how links look when shared. This package lets us implement that consistently in days rather than weeks, at effectively zero licensing cost. The 4.0.0 release confirms the maintainer is keeping pace with current Laravel versions, so the dependency is unlikely to become a maintenance liability. The one caveat: it requires us to be on Laravel 11 or newer, so if we are behind on framework upgrades, that work comes first.

To engineering: 4.0.0 is a breaking release — it drops legacy support and raises the floor to PHP ^8.2 and Laravel ^11 / ^12 / ^13. There is no functional API change called out in the release notes; the impact is entirely in the support matrix. Two consequences: (1) the upgrade is a version-constraint bump plus a CI matrix update, gated on our framework version; (2) the maintainer has committed to tracking Laravel's official support policy going forward, which means future majors will arrive in step with framework majors — plan for a recurring, small upgrade task rather than a one-time integration. Treat the pin as ^4.0 only if our PHP and Laravel versions already satisfy the new floor; otherwise stay on ^3.0 with a documented follow-up ticket tied to the framework upgrade.