Aardvark Seo Laravel Package

Technical Evaluation

What the package actually is. Despite being catalogued as a Laravel/PHP package, withcandour/aardvark-seo is a Statamic addon — a Laravel package that boots through Statamic's addon service provider and extends the control panel, blueprints, fieldtypes, and Antlers rendering layer. That distinction is the single most important fact in this assessment: it has essentially zero value outside a Statamic site, and its compatibility envelope is dictated by Statamic's release cadence, not Laravel's.

Architecture fit.

• Fits: Statamic 3/4/5 sites on Laravel where SEO metadata is currently hand-rolled in Antlers partials, or where editors are pasting meta tags into a generic text field. The addon's value is consolidating SEO fields into a blueprint-driven tab plus a generated sitemap, which is a genuine editorial workflow win.
• Does not fit: headless/API-first deployments where the front end is Next/Nuxt and meta tags are assembled outside Statamic; multi-repo estates where SEO logic must be shared across non-Statamic properties; plain Laravel applications; any site pinned to an older Statamic major that the addon has since dropped.
• Coupling: the addon sits on Statamic internals that have historically churned across majors (CP components/Vite build, fieldtype registration, augmentation). That is a recurring upgrade tax, not a one-time integration cost.

Integration feasibility. Mechanically low-effort: composer require, publish config/assets, attach the provided fieldset to collection blueprints, include the meta partial in the layout, and expose the sitemap route. A competent Statamic developer can produce a working staging build in 1–3 days; the real effort is content backfill and output verification, not installation.

Technical risk.

1. License (highest severity). NOASSERTION means no machine-readable SPDX license. Legal cannot confirm redistribution, modification, or commercial-use terms from metadata alone. This must be resolved by reading the actual LICENSE file and, if absent or ambiguous, by written confirmation from the maintainer — or the package is disqualified for a commercial estate.
2. Provenance mismatch. The package name (withcandour/...) does not match the supplied repository (justkidding96/statamic-aardvark-seo). This is either a maintained fork, a mirror, or an unaffiliated republication. Until canonical upstream is confirmed, assume no upstream security patching and no guarantee that Packagist contents equal the reviewed repo.
3. Adoption signal is effectively nil. 15 stars and 0 dependents means no crowd-sourced regression coverage, no Stack Overflow corpus, bus factor of one. There is no evidence of a CVE response process.
4. Metadata hygiene. A last-release date of 2026-09-07 is not credible as-is; treat release dates and version constraints as unverified until checked against Packagist directly.
5. Correctness risk is business-critical. Canonical tags, hreflang, Open Graph, JSON-LD, sitemap pagination, and redirect handling directly affect indexation. A subtly wrong canonical or a duplicated og:title is a silent revenue problem that QA will not catch without an SEO reviewer.

Key questions to answer before approval.

• Which Statamic majors and PHP versions are supported, and what is the maintainer's stated upgrade policy?
• What exactly is the license, and does it permit internal modification and redistribution in a private Composer registry?
• Is justkidding96/statamic-aardvark-seo the canonical source, and is the Packagist vendor the same party?
• Which SEO surfaces does it actually own (meta, sitemap, redirects, JSON-LD, robots, canonicals) versus leave to us?
• How does it behave under Statamic multisite and multi-locale (per-site meta, per-locale sitemaps, hreflang)?
• Does sitemap generation scale beyond ~10k entries, and is it cache/queue aware?
• Is there a paid/pro tier or a commercial support path?

Integration Approach

Stack fit.

Migration path. Assume we are moving from hand-authored Antlers meta partials or a competing SEO addon.

1. Inventory every current SEO output (meta, OG/Twitter, canonical, JSON-LD, sitemap, robots, redirects) with a crawler diff as the baseline.
2. Map existing fields to the addon's field handles; write a one-off migration or Statamic import to backfill without editor re-entry.
3. Run both outputs in parallel behind a feature flag on staging — never emit duplicate meta tags, which is worse than none.
4. Cut over the sitemap URL last, and keep the old URL as a 301 until search consoles have re-crawled.

Compatibility. Pin an exact version in composer.json (no caret range). Verify the CP asset build works with our Vite/CP configuration. Confirm no collision with existing addons that also register sitemap routes or SEO fieldtypes.

Sequencing.

1. License and provenance clearance — hard gate, do not start engineering before this closes.
2. Read-only spike on a throwaway branch against a production data clone.
3. SEO review of rendered output against the baseline crawl.
4. Fieldset rollout to one high-value collection.
5. Template partials for meta/OG/JSON-LD; sitemap route; robots directives.
6. Content backfill and editor training.
7. Cache invalidation wiring, then full rollout to remaining collections.
8. Post-launch crawl monitoring for 30 days.

Fallback. Budget a half-day contingency for a ~100-line Antlers meta partial plus a custom sitemap route. For a site with modest SEO needs, this is genuinely competitive with adopting an unmaintained third-party addon, and it carries no license or upgrade risk.

Operational Impact

Maintenance. Assume we own this code the day we install it. Pin the version, vendor the source into our private registry, and record the exact commit SHA. Every Statamic major upgrade becomes a compatibility project; budget 1–3 days per major until the addon proves it tracks releases. If the maintainer goes quiet, forking is our only path — which the ambiguous license may not permit.

Support. Community-only, no SLA, no vendor escalation channel, no security advisory feed. Operating this requires a named internal owner (a Statamic-fluent developer at ~10–15% FTE during the first quarter, tapering to near-zero). Without that owner, this becomes orphaned infrastructure that nobody dares upgrade.

Scaling.

• Sitemap generation cost grows with entry count and multiplies per site in a multisite install; static caching mitigates it, but the cache-invalidation hook must be wired correctly or editors will publish into a stale sitemap.
• CP asset weight is negligible; runtime cost is dominated by template rendering, not the addon.
• The real scaling ceiling is editorial: as collections multiply, keeping the SEO fieldset consistently applied across blueprints requires governance, not tooling.

Failure modes to monitor.

• Meta tags silently absent after a blueprint change — highest-likelihood, highest-impact.
• Duplicate meta/canonical tags from parallel legacy partials during migration.
• Sitemap 500 or timeout on large or multisite installs.
• Stale sitemap behind static cache or CDN after publish.
• CP JavaScript breakage after a Statamic minor upgrade.
• License challenge or forced removal after engineering investment — the scenario that makes the ambiguous license expensive rather than merely annoying.
• Upstream abandonment coinciding with a Statamic major release, freezing our upgrade path.

Ramp-up. A Statamic-fluent developer reaches productivity in half a day; a Laravel-only developer with no Statamic exposure needs 2–3 days to understand blueprints, Antlers, and the addon registration model. Editors need a 30-minute walkthrough plus a written checklist (title length, description, social image, canonical override policy). An SEO reviewer — internal or contracted — should sign off on rendered output; that reviewer is the actual gate on launch quality, not the engineering work.

TPM recommendation. Conditional pilot, not a platform commitment. The integration cost is low enough to justify a time-boxed spike, but 15 stars, zero dependents, an unverifiable provenance trail, and a NOASSERTION license collectively fail the bar for a default dependency in a commercial estate. Proceed only if (a) legal clears the license in writing, (b) the canonical upstream is confirmed and pinned, and (c) a named internal owner accepts the ongoing upgrade tax. Otherwise, build the thin internal equivalent — it is cheaper over a two-year horizon than inheriting an unmaintained dependency.