Seotamic Laravel Package

Technical Evaluation

Architecture fit. cnj/seotamic is a Statamic v4 addon, which in Laravel terms means a standard Composer package with an addon service provider, auto-discovery, a publishable config, blueprint fieldset additions, and one or more Antlers tags responsible for emitting meta tags into the document <head>. That is the correct architectural shape for this problem domain: SEO metadata belongs in entry front matter, is authored in the control panel, and is rendered declaratively in templates. There is no architectural friction in adopting it — it is not a service, not a sidecar, and it introduces no new runtime infrastructure. The fit question is therefore not "does the architecture work" but "is this the right implementation of a commodity capability."

Integration feasibility. Mechanically trivial: composer require cnj-digital/seotamic, publish config, append the addon's fieldset to a collection blueprint, drop a single Antlers partial into the layout, and validate output. Realistic effort for a competent Statamic developer is measured in hours for a pilot, days for a full multi-site rollout. Two caveats raise the true cost. First, the addon competes with an entrenched, well-documented incumbent in the Statamic ecosystem (SEO Pro by Aerni), so the burden of proof is on this package to be meaningfully better, not merely available. Second, SEO metadata changes are not neutral: canonical, robots, and hreflang are directives that can deindex pages or consolidate ranking signals onto the wrong URL. Integration effort is low; integration risk is asymmetric because the blast radius of a subtle default-config error is a traffic incident, not a bug ticket.

Technical risk. The dominant risk is lifecycle, not code quality:

• Version lock. Targeting Statamic v4 only is the single largest concern. Statamic v5/v6 moved the underlying Laravel and PHP minimums; an addon pinned to v4 becomes a blocker on core upgrades and, by extension, on security patching of the CMS itself. A v4-only constraint converts a convenience package into a platform ceiling.
• Adoption signal. 21 stars and 0 dependents means effectively no third-party battle-testing. Edge cases that a mature addon has already absorbed — multisite canonicalization, localization, static caching, pagination, taxonomy/term routes, 404s — are precisely where low-adoption addons break, and precisely where the failures are silent in the browser and only visible in Search Console weeks later.
• Bus factor. Agency-owned packages (CNJ Digital) are maintained opportunistically. The recorded latest release (2026-09-08) suggests it is not abandoned, but release cadence for an agency addon tracks internal client need, not a public roadmap or SLA. Notably, a recent release that still does not claim v5 support is itself a signal worth interrogating.
• Governance gaps. License terms, CI/test coverage, security policy, and whether issues are triaged are all unverified. For a package that injects markup into every page of a site, "no published security policy" is a finding, not a formality.

Key questions to put to the maintainer and to our own team before adoption:

1. Is it MIT (or otherwise permissively) licensed, and is that stated in composer.json and a LICENSE file?
2. Are there hard Composer constraints on statamic/cms and laravel/framework, and is there a stated or in-progress path to Statamic v5/v6?
3. Which capabilities are in scope: meta title/description, Open Graph/Twitter cards, canonical, robots directives, hreflang/multisite, JSON-LD schema, XML sitemap, redirects, 404 monitoring, OG image generation? Capability surface determines whether this replaces an incumbent or merely supplements it.
4. Does it degrade correctly when fields are empty — does it fall back to sensible defaults, or does it emit empty <title> and duplicate canonical tags?
5. Is output escaped/sanitized, and does it interact safely with Statamic static caching (i.e., are cached pages invalidated on entry save)?
6. Where is the data stored — entry front matter, a separate SEO table, or the global cascade? Data residency determines our exit cost.
7. What is the test story (Pest/PHPUnit, CI matrix), and who responds to issues, with what expectations?

Integration Approach

Stack fit. The package slots cleanly into an existing Statamic-on-Laravel stack with no new runtime dependencies, no queue workers, no external API calls assumed, and no database migrations implied by the front-matter model. That is a genuine advantage: it is deployable through the normal Composer + deploy pipeline and carries no incremental infrastructure cost. It is a poor fit only if we are on Statamic v5+, in which case it is likely a non-starter until compatibility is verified.

Migration path. The saving grace of this entire category is that SEO data lives in Markdown front matter alongside the entry. That means migration off this package is cheap — we retain the content and only lose the rendering layer. Migration onto it from an incumbent (SEO Pro, Aardvark, or hand-rolled Antlers meta) is the harder direction: field handles differ, so we need an explicit handle-mapping table and a one-time scripted rewrite of front matter across all collections, plus a fallback in the head partial so pages render correctly during the transition window. Plan for a dual-read period rather than a cutover.

Compatibility. Verify explicitly, not by assumption: PHP version floor, Laravel major, statamic/cms constraint, and behaviour under multisite and static caching. Also verify coexistence — if any legacy meta tags remain in layouts, we will emit duplicate canonical and og:* tags, which search engines handle inconsistently. Removal of legacy tags must be part of the same change set as the new partial, not a follow-up.

Sequencing. Gate the rollout:

1. Due diligence — license, constraints, capability inventory, issue-tracker responsiveness. Cheap, and can kill the initiative early.
2. Spike branch — install on a disposable environment, render one page, validate with Google Rich Results Test, Schema Markup Validator, and a curl diff of the <head>.
3. Single-collection pilot — one collection, one blueprint, one layout, production-adjacent. Define exit criteria in advance (zero duplicate tags, correct canonical on paginated and multisite URLs, cached pages invalidated on save).
4. Multisite and caching hardening — the highest-risk area; do not skip.
5. Fleet rollout — collection by collection, with a per-collection SEO regression check.
6. Legacy decommission — remove incumbent tags and, if applicable, the incumbent package, once Search Console shows stable indexing for a defined window.

If any of steps 1–4 fails, the fallback is to keep the front-matter field schema and render meta tags ourselves with a small Antlers partial. That fallback is genuinely viable and should be documented before we commit, because it caps our downside and neutralises the maintenance concerns below.

Operational Impact

Maintenance. Ownership sits with a single external agency whose incentives are not aligned with our upgrade calendar. Concretely: when Statamic ships a major version, we do not control the timeline on which this addon follows, and an unmaintained addon becomes a blocker on core security updates. Mitigations are (a) confirm the license permits forking, (b) budget a fork-and-maintain contingency of roughly a few engineer-days per year, and (c) treat the addon as replaceable by design — since the metadata is portable front matter, the exit cost is the rendering layer only. Do not let it become load-bearing for anything beyond head markup.

Support. Realistically GitHub issues with no SLA and no commercial tier. Internal support therefore rests on our own team's Statamic fluency. For a 21-star package, expect to debug edge cases ourselves and to upstream fixes or carry a local patch. This is acceptable for a rendering-layer addon and unacceptable if we were relying on it for redirects or 404 monitoring, where failure is operationally visible.

Scaling. Runtime cost is negligible — it is string assembly in the head. The scaling concerns are elsewhere: sitemap generation on large content sets (tens of thousands of entries) can be slow and should be checked against static caching and any sitemap caching layer; multisite multiplies the URL surface and therefore the hreflang/canonical permutation space, which is the most common correctness failure at scale; and any OG image generation, if present, is the one place where per-request compute could appear. Confirm behaviour before committing a large-site rollout.

Failure modes, ranked by expected damage:

• Silent deindexing — a bad default robots or a canonical pointing at the wrong host after a domain or environment change. Highest severity, lowest visibility; only Search Console catches it.
• Duplicate meta emission during partial migration, producing conflicting canonical/og:* signals.
• Cache staleness — static or full-page cache serving a stale canonical or noindex after a content edit; the SEO addon and the cache layer must be verified as coupled.
• Upgrade deadlock — Statamic security release arrives, addon is incompatible, and we must choose between a patched CMS and working SEO output.
• Handle drift — a field renamed in a blueprint orphans front-matter data with no error surfaced to editors.
• Multisite leakage — one site's metadata or hreflang set bleeding into another.

Ramp-up. Developer ramp is short for anyone already fluent in Statamic blueprints and Antlers — under a day. Editor ramp is short but needs deliberate training, because the failure mode is human: editors leaving noindex on, or pasting full URLs into canonical fields. Allocate a short CMS-editor guide and a CP-level guardrail (sensible defaults, inline help, required fields). The genuine ramp cost is domain expertise: whoever owns this must be able to reason about canonicalization, hreflang, and structured data, and must own a recurring Search Console review. Scope this as an ongoing responsibility, not a one-off integration task.