Alt Seo Laravel Package

Technical Evaluation

Architecture fit. alt-design/alt-seo is a Statamic addon (Alt Design is a Statamic-focused agency), which means it targets Laravel applications running Statamic as the content layer rather than plain Laravel apps. Architecturally that is a good fit for our use case if our marketing sites are Statamic-driven: it registers a service provider via Laravel package auto-discovery, publishes config, and exposes tag rendering through Antlers/Blade partials and likely per-entry fieldset/blueprint additions. It sits in the presentation layer alongside the layout templates, which is the correct place for meta, Open Graph, canonical, and structured-data output. It is not a general-purpose Laravel SEO package — we should not assume it works in a non-Statamic Laravel app.

Integration feasibility. Mechanically simple: composer require alt-design/alt-seo, publish config, add fields to blueprints, include the tag partial in the <head>. The blockers are not install effort but validation effort — SEO output is only correct if verified end-to-end (canonical, hreflang, OG/Twitter, JSON-LD, sitemap/robots interactions). Community signals remain thin (12 stars, 0 dependents), and the previously flagged anomalous release dating is now corroborated by a normal-looking patch train: v1.5.0 → v1.5.1 with two small PRs. That is modest but genuine evidence of active maintenance by two named maintainers, which is a marginal improvement to the abandonment picture. MIT license still gives us fork rights, which materially reduces that risk.

Technical risk. Primary risks: (1) bus factor — an agency-maintained addon with a small community means we are largely self-supporting; (2) unvalidated compatibility matrix against current Statamic/PHP versions; (3) SEO regression risk from duplicate or conflicting meta tags if another SEO addon or hardcoded partials remain; (4) interaction with static caching / SSG, where a silent render failure produces permanently cached bad markup; (5) no visible test suite, so upgrades must be validated by crawl diff rather than trust. v1.5.1 adds two specific risks worth naming. First, canonical URLs now have query strings stripped, which is a behavior change shipped in a patch release: for paginated listings (?page=2), faceted/filtered category pages, and search results, the canonical will collapse to the base URL. That is usually the correct SEO default, but if any of our pages rely on query-parameter canonicals today, this silently repoints them and can deindex paginated content. Second, entry values are now escaped in meta tags — a welcome XSS hardening, but it changes rendered output for values containing &, quotes, or existing HTML entities, and there is a double-escaping risk if our templates already apply escaping. Both changes require a rendered-output diff, not just a version bump.

Key questions for the maintainer/vendor. Which Statamic and PHP versions are supported and tested? Does it emit canonical, hreflang, OG/Twitter, and JSON-LD, and can each be overridden per-entry and per-template? Multi-site and multi-locale behavior? Sitemap and robots.txt generation, or does it defer to Statamic core/other addons? Does it work under static caching, Live Preview, and static site generation? Is there a test suite and a stated support/response expectation? What is the upgrade policy across Statamic majors? Added for v1.5.1: does query-string stripping apply to all parameters including page/pagination, and is there a config flag or per-entry canonical override to preserve parameterized URLs where legitimately needed? Is the canonical override field authoritative over the stripping logic? Which escaping function is used, and is it applied once (safe) or layered on top of Antlers' own escaping (double-escape risk)? Was anything else in the v1.5.0→v1.5.1 commit range beyond the two changelog lines?

Integration Approach

Stack fit. Assumes Laravel 10/11/12 + Statamic 4/5, Composer, auto-discovery, Antlers-first templating (Blade-compatible in most cases). Fits content-marketing and brochure sites with editorial teams in the control panel. Poor fit for API-only Laravel services or apps where SEO tags are generated outside the CMS.

Migration path. Inventory the current head markup and any existing SEO addon or hardcoded partials first; produce a field-by-field mapping to the addon's blueprint fieldsets. Install in a feature branch, publish config, wire one collection, and render into a staging environment that mirrors production caching. Then migrate collection by collection, retiring legacy partials only after a crawl diff confirms parity. Capture a pre-migration baseline with a crawler (Screaming Frog or equivalent) plus Search Console and social debugger snapshots so regressions are attributable. Use v1.5.1 as the floor rather than 1.5.0 — the escaping fix is a security hardening we should not ship around — but treat it as a behavior change, not a no-op patch.

Compatibility. Pin exact versions in composer.json (minimum 1.5.1), verify constraints against our PHP and Statamic versions, and check for collisions with any existing SEO/sitemap addon before install. Confirm blueprint changes are additive so existing entry data is not orphaned. Add two explicit compatibility checks the release forces: (a) canonical regression across paginated, filtered, and UTM-tagged URLs; (b) rendered-output regression for entry values containing &, <, quotes, and pre-existing entities, to rule out double escaping in titles and descriptions.

Sequencing. (1) Timeboxed spike: install ^1.5.1, one collection, validate output with Rich Results Test and OG/Twitter debuggers, plus the two regression checks above. (2) Full blueprint rollout and template wiring. (3) Sitemap/robots/canonical ownership decision — one source of truth only, including who owns query-string policy. (4) Remove legacy partials and conflicting addons. (5) Add CI assertions on rendered head markup plus a Lighthouse/Core Web Vitals gate. (6) Production release with an explicit cache-invalidation step. Roughly one sprint for a two-person team, weighted toward QA rather than build; v1.5.1 adds a half-day of canonical/escaping verification.

Operational Impact

Maintenance. Low code churn expected for a tag renderer, but we must own the upgrade cadence: re-validate on every Statamic major and on PHP minor bumps, and now also read every patch changelog for behavioral changes like the canonical policy. v1.5.1 is mild positive evidence of an active maintainer pair, but two PRs is not a track record — hold the assumption that we may fork or vendor (MIT permits it). Assign a named internal owner and require a rendered-head diff as the merge gate for addon upgrades.

Support. Community-grade: GitHub issues, no SLA, no dependents to corroborate behavior. Escalation path is direct vendor contact or in-house patching. Do not place it on a critical path without that fallback documented. The v1.5.1 fixes address issues that presumably were not reported as security advisories — worth asking whether a disclosure process exists.

Scaling. Rendering cost is negligible — it is string assembly in the head. Real scaling concerns are query behavior when structured data traverses entry relationships (watch for N+1 across listing pages) and configuration sprawl under multi-site, where each site/locale needs its own defaults validated. Static caching neutralizes most of this but raises the cost of getting it wrong.

Failure modes. Missing or duplicated meta after an upgrade; broken canonical or hreflang producing ranking loss that surfaces weeks later; stale cached HTML pinning bad tags in place; blueprint changes orphaning field data; conflicts with a second SEO addon; invalid JSON-LD after content-model changes. New from v1.5.1: canonical collapse on paginated or faceted URLs causing deindexing or ranking shifts on deep listing pages — and because it ships cached, the wrong canonical persists until cache invalidation; and double-escaped entities rendering as & or literal quotes in SERP snippets and social cards. Mitigations: CI head-markup assertions, scheduled crawl diffs, cache-invalidation in the deploy runbook, a canonical-policy test fixture set covering pagination and filters, and a single documented owner of SEO tag generation.

Ramp-up. A developer fluent in Statamic needs roughly one to two days to be productive; a Laravel-only developer needs longer to learn Antlers, blueprints, and the caching model. The larger ramp-up cost is on the SEO/analytics side — plan for marketing-ops involvement in acceptance testing, not just engineering, and route the canonical query-string decision through them explicitly since it has ranking consequences.