Alt Seo Laravel Package

Product Decisions This Supports

• Build vs. buy for SEO metadata plumbing. If your product runs on Statamic (a Laravel-based CMS), this addon supplies the SEO tag layer — page titles, meta descriptions, canonical and Open Graph/social tags — that would otherwise be a small internal sprint. The decision this supports is whether to spend ~1–3 engineer-days building a Blueprint fieldset plus an Antlers partial, or adopt an MIT-licensed addon and spend those days on differentiated work. v1.5.1 strengthens the "buy" side slightly: two of the hardening items a reviewer would otherwise have to fix in a homegrown build (output escaping, canonical normalization) are now handled upstream.
• Feature scoping for content/marketing surfaces. Useful when the roadmap includes "let marketing own SEO metadata without engineering tickets." The addon's real value is workflow — editable SEO fields in the control panel — not novel technology, so it belongs in a content-ops initiative, not a platform initiative.
• Roadmap gating for SEO depth. This package covers baseline on-page tags only. It is a reasonable v1 to unblock a launch, but it does not settle decisions on structured data (schema.org/JSON-LD), XML sitemaps, redirects, hreflang, or internationalization. Treat adoption as a decision to defer those, with an explicit follow-up item.
• Agency and multi-site delivery economics. For client sites built on Statamic, a drop-in SEO addon reduces per-project setup cost and standardizes output across a portfolio. This is a margin decision as much as a technical one.
• Migration/consolidation triage. Because it is a thin, MIT-licensed addon, it is low-cost to trial on one property and low-cost to remove. That makes it a viable candidate for a "pilot on a low-risk site" experiment rather than a platform standard.
• Vendor/dependency policy precedent. With a small star count and near-zero dependents, approving this sets a precedent for accepting small-audience dependencies. The PM decision is whether that precedent is acceptable for marketing sites but not for revenue-critical applications. v1.5.1 is a positive data point for the precedent — a security-relevant fix landed promptly and from a second contributor — but one patch does not establish a track record.
• Canonicalization policy for marketing/analytics surfaces (new in v1.5.1). The addon now strips query strings from the canonical URL. This is a product decision, not just a technical one: it prevents campaign parameters (utm_*, fbclid, ad-click IDs) from fragmenting canonical signals and polluting SEO reporting. The flip side is that any page whose content genuinely varies by query string — pagination, faceted filters, sorted listings — may now emit a canonical that points away from the actual variant. Decide explicitly whether you want "one canonical per path" as house policy; for content sites it is usually right, for catalog/search surfaces it can be wrong.

When to Consider This Package

Consider it when:

• The application is Statamic-based (Statamic 3/4/5 — verify the supported version matrix explicitly before committing; a mismatched major version is the most common failure mode).
• The requirement is baseline on-page SEO: per-entry title, meta description, canonical URL, and social sharing tags rendered into the head.
• The audience is content editors who need self-service metadata editing without developer involvement.
• The site is low-to-moderate risk: marketing site, brochure site, blog, client deliverable — not a revenue-critical or regulated surface.
• Your team is comfortable owning a fork. With a small maintainer pool and near-zero downstream usage, assume you may need to patch it yourself; the MIT license makes that legally trivial.
• Timeline pressure favors shipping a launch over building in-house, and you have an engineer who can review ~a few hundred lines of PHP/Antlers in an afternoon.

Look elsewhere when:

• You are not on Statamic. For plain Laravel, established packages such as spatie/laravel-seo or artesaos/seotools have materially larger install bases and community support.
• You need advanced SEO: JSON-LD/structured data, sitemap generation, redirect management, hreflang/multilingual metadata, or integration with Search Console. This addon is not that, and stacking three tiny addons is worse than one coherent solution.
• You depend on query-string-distinct pages. Because v1.5.1 strips query strings from the canonical, paginated (?page=2), filtered, or sorted listing pages will canonicalize to the bare path. If those variants matter to your organic traffic, you need a per-template override or a different solution — validate this before rollout, not after.
• Maintenance guarantees matter. Adoption remains low, so there is no ecosystem pressure to keep it current. The v1.5.1 patch is a genuine positive maintenance signal — a security-hygiene fix plus a behavior change, from more than one contributor — but weigh it as one release, not a guarantee. If a Statamic upgrade breaks it, you are still the maintainer. Confirm release cadence and recent commit history against the actual repository before committing; irregular timestamps in the published metadata are a signal to inspect rather than trust.
• Security or compliance review is required. v1.5.1 added escaping of entry values in meta tags, which closes the most obvious injection class — but note that this means prior versions (≤1.5.0) rendered entry values unescaped, so pin ≥1.5.1 and do not inherit an older lockfile. Formal review will still struggle with a small-maintainer dependency lacking a visible test suite or security policy; budget time for a code read, or expect the review to fail on process rather than substance.
• You need vendor support or SLAs. There is none. This is community/MIT with an implicit best-effort model.

Practical evaluation checklist before adoption: confirm the supported Statamic/Laravel version constraints; pin at least v1.5.1 so the escaping fix is present, and verify the lockfile in any existing environment; read the canonical-URL code path and decide whether stripping query strings is correct for each template family (test pagination and filtered pages specifically); check that utm_*/click-ID normalization matches what your analytics team expects; check for a test suite and CI; confirm how defaults and fallbacks behave when fields are empty (empty meta tags are a common SEO regression); and run it against your existing templates to catch duplicate-tag conflicts with any SEO already in your layout.

How to Pitch It (Stakeholders)

To executives: This is a small, free, open-source addon that gives our content team the ability to manage SEO metadata — page titles, descriptions, and social sharing previews — without filing engineering tickets. Cost is zero in license fees and roughly a day of engineering review rather than a multi-day build. The latest patch (v1.5.1) tightened output escaping and made canonical URLs consistent, which removes two things we would otherwise have had to build or fix ourselves. It is appropriate for marketing and content sites; it is not an enterprise platform commitment.

The honest caveat, stated plainly: adoption is very low — a small star count, no downstream dependents, effectively a tiny maintainer pool. That is not a reason to reject it, but it is a reason to treat it as code we are adopting, not a vendor we are relying on. The right framing is: low cost, low switching cost, and we accept a modest ongoing ownership burden in exchange for speed. The recent security-minded patch is early evidence the project is alive, and it is one data point rather than a track record. If it stops being maintained, we fork it or replace it — the MIT license and thin surface area keep that exit cheap.

To engineering: The ask is a one-day spike: verify version compatibility with our Statamic install, pin ≥1.5.1 for the escaping fix, review the new canonical query-string stripping against paginated and filtered templates, confirm empty-field fallback behavior, and vendor or fork it into our own namespace if we adopt. If the spike surfaces meaningful friction — especially around canonicalization of variant URLs — we build the fieldset in-house instead; the package is small enough that this is a genuine toss-up, and the decision cost is low either way.

To the content/marketing lead: The win is autonomy over metadata and social previews, editable at the entry level. One improvement worth calling out: canonical URLs now ignore tracking and campaign parameters, so shared links carrying utm_* tags no longer compete with the clean page URL in search results. The limitation to set expectations on now: this covers baseline tags only. Structured data, sitemaps, and redirects remain separate workstreams and should be planned as such rather than assumed to arrive with this package.