Seo Pro Laravel Package

Technical Evaluation

Framing the buy decision. statamic/seo-pro is not a general-purpose Laravel package — it's a first-party, license-gated addon for the Statamic CMS. Everything of value (blueprint fieldsets, the control-panel report, the {{ seo_pro }} head tag, sitemap and redirect routes) only exists inside a Statamic runtime. The first TPM question is therefore not "is this good?" but "are we, and will we stay, on Statamic?" If the answer is no or "we're evaluating a move to headless WordPress/Next," this evaluation ends here.

Architecture fit. The addon sits cleanly at the content-model ↔ presentation boundary and is config-declared rather than code-invasive:

• Content layer: SEO fields enter via the shipped fieldset imported into collection blueprints; data persists in the entry's seo field.
• Resolution layer: a site → collection → entry cascade supplies defaults, so definitions live in one place and entries override only when needed.
• Presentation layer: a single head-rendering tag plus generated sitemap/redirect routes.
• Ops layer: report scoring runs through Laravel queues.

That shape is hub-and-spoke and upgrade-friendly — which is the main architectural argument for buying it over hand-rolling.

Integration feasibility: high, but gated. Install is composer require, an env license key, and a published config — Statamic auto-discovers addons, so there's no service provider to wire. Real effort is concentrated in three places: the version matrix (Statamic major ↔ addon major, the single most common install failure), rendering the head tag centrally without duplicating hand-written <title>/meta, and headless/API consumers where the seo field does not automatically arrive in the shape a front end needs.

Technical risk register.

Key questions to close before signing:

1. Which Statamic major are we on, and what's our upgrade cadence over the license term? Write the supported matrix into the runbook.
2. Who owns the license (procurement, renewal budget) and what is the documented behavior at lapse?
3. Server-rendered Statamic views, or a headless/API front end? If headless, who owns mapping seo into OG/title/canonical tags?
4. Do we have a running queue worker, and does its host have a Chrome/Chromium binary for social previews?
5. Do any existing blueprints squat on seo or seo_pro? (Collisions manifest as confusing fallback behavior, not errors.)
6. Are custom routes, error pages, and controller-rendered views in scope? They have no implicit cascade and will silently render defaults.
7. Do our content needs require bespoke scoring rules beyond what's exposed?

On the signals. 76 stars and 0 public dependents are structurally blind for a privately installed, license-gated first-party addon — they should not drive the decision. The decision-grade inputs are vendor patch cadence and issue-tracker responsiveness, both of which look healthy (five fixes in v7.15.1 spanning UI, queue error recording, multisite, and i18n). Treat the ~48.8 opportunity score as a prompt to validate license economics and version fit, not a verdict.

Integration Approach

Stack fit. Laravel host + Statamic + addon 7.x, no service provider registration. Prerequisites in the order they actually break installs: (1) Statamic major ↔ addon major alignment checked against composer.json constraints, (2) PHP version, (3) license key in .env, (4) config:clear — an unlicensed banner in the CP is almost always cached config, not a bad key.

Migration path. Sequence it as a phased rollout with a hard pilot gate; do not sweep every blueprint on day one.

• Phase 0 — Gate & safety. Confirm version matrix, license, and a runbook entry. Force noindex outside production via config or a globals setting before any content migration. Publish and read config/seo-pro.php end to end — sitemap, redirects, reports/queue, social preview, and cascade blocks are the map for everything downstream.
• Phase 1 — Pilot on one collection. Import the shipped SEO fieldset into the blog/posts blueprint only. Drop {{ seo_pro }} into the layout head and remove existing hand-written <title>/meta to avoid duplicates. Acceptance criteria: publish one entry, set meta title/description, confirm tags in view source (not DevTools); confirm the entry appears in /sitemap.xml and a draft/noindexed entry does not; create one 301 and verify it in a private window. That's the whole loop in fifteen minutes and surfaces version, license, and cache problems immediately.
• Phase 2 — Cascade and sitemap. Set title/description/social templates once at site level, narrow per collection, and fill entry fields only where editors genuinely need a custom value. Rule: never copy inherited values down into entries — they freeze and stop tracking the cascade, and removing an inherited value requires an explicit override, not a blank. Enable sitemap per collection rather than globally, add custom routes (product landing pages, docs) via config rather than submitting a second sitemap.
• Phase 3 — Redirects. Choose the driver deliberately: file-based is version-controllable and fine at small scale; the database driver is the better fit once editors manage thousands and you want queryable records. Enable auto-creation on slug change where available. Bulk-import the legacy redirect map once, then let the CP own it.
• Phase 4 — Reporting at scale. Move report generation onto the queue (deferred or background), schedule regeneration instead of asking editors to press a button, and keep a worker alive. Brief stakeholders on the post-v7.15.1 error spike before deployment, or someone will roll it back.
• Phase 5 — Multisite/localization. Set defaults per site, verify canonical and hreflang output per locale, check the sitemap once per site. Retire any workaround built around #688 (editing URL-less entries); keep paying for it and you keep paying for it.
• Phase 6 — Headless consumers. Add an explicit work item to include the seo field in API resources/transformers and map it to <title>, description, OG tags, and canonical in the consuming app. This is the most common integration gap and no patch release closes it for you.

Compatibility hygiene. After every upgrade, diff CP customizations and overrides under lang/vendor/seo-pro — #690 touched report status colors and dark mode, #682 touched German. Keep a feature test asserting rendered head tags (title, description, canonical, og:*) plus a sitemap snapshot for a known fixture; that harness turns the next patch bump into a diff instead of a leap of faith.

Sequencing constraint. If a localization or multi-brand launch is on the roadmap, this addon's readiness is a dependency line item and must be sequenced before content migration, not after.

Operational Impact

Maintenance. Low code maintenance — the vendor owns the hard parts — but the cost is recurring and should be budgeted as such: one compatibility review per Statamic major, a per-upgrade diff of CP/translation overrides, and a license renewal. In practice we're purchasing someone else's edge-case backlog: report row rendering (#684), status/dark-mode alignment (#690), queue-driver error recording (#686), multisite URL-less editing (#688), German translations (#682). None of those are features we couldn't write; all of them are features we'd rather not maintain forever.

Support. First-party vendor plus public issue tracker. Triage is a team responsibility, not a vendor one: someone must own the report, the queue, and the failed_jobs table. A report that never completes is usually a dead job, not a broken addon.

Scaling. Three independent scaling axes:

• Reports — cost is entries × fields × locales. Queue them, schedule regeneration, monitor worker health.
• Redirects — lookup volume grows with the redirect map; the database driver is the right call past a few thousand entries.
• Social previews — headless Chrome is expensive. Keep generation queued and cached, never on the request path, and verify the worker host actually has the binary.

Failure modes to instrument and rehearse:

• License lapse — behavior unverified until modelled; put it in the risk register.
• Duplicate tags — a leftover hand-written <title> alongside the tag is invisible in the CP preview and obvious in the SERP.
• Untitled custom routes — error pages and controller-rendered views have no implicit cascade; guard the tag with a fallback <title>.
• Staging outranking production — prevented only by the Phase 0 noindex control.
• Redirect loops — almost always host config (www vs. non-www, trailing slashes), not the addon; enforce absolute destinations, no self-references, no chains.
• Stale redirects via static cache — ensure redirect handling runs before the cache and clear cache on redirect edits.
• Post-upgrade error spike — a backlog of previously unrecorded errors surfacing; pre-brief stakeholders.

Ramp-up. Developer ramp is genuinely small: one fieldset import, one tag, one config file. Editor ramp is the real cost and the thing that determines ROI: a walkthrough, character-counter habits, a documented report-triage routine, and a named owner. The payoff is moving quality control upstream to whoever writes the content — fewer marketing-to-editorial round trips — but an unowned report becomes shelfware within a quarter. The product decision this enables is making "SEO-ready" a publish-time property rather than a post-publish audit; that's a workflow and quality-gate change, and it should be staffed as one.

Bottom line for the roadmap. Adopt if we're on Statamic and want editors to own on-page quality, especially with multisite/multilingual and queued report generation in play. Defer if we're headless with a separately owned front end that won't absorb the seo field mapping, if we can't absorb a commercial license inside a core content workflow, or if our needs run to bespoke scoring rules that push us toward a fork.