Seo Pro Laravel Package

Product Decisions This Supports

• Defining "done" for a page. SEO Pro moves meta titles, descriptions, canonical URLs, noindex, Open Graph/Twitter cards, and JSON-LD into the entry editor with a site → collection → entry cascade. The decision it unlocks is a quality-gate decision: does a page count as publishable only when its SEO fields are set? That is a workflow and standards call, and it changes outcomes far more than the addon itself does. Be explicit that this is on-page hygiene, not keyword, backlink, or crawl intelligence — do not let it be sold internally as an SEO strategy.
• Build vs. buy on undifferentiated plumbing. Sitemap generation, redirect management, 404 tracking, content scoring, and a cross-content report are the pieces every Statamic team eventually hand-rolls and then maintains forever. The v7.15.1 changelog is the buy case in miniature: report row rendering (#684), status colors and dark mode aligned with the CP (#690), error recording under deferred/background queue drivers (#686), a multisite fix for entries without URLs (#688), German translations (#682). We would be purchasing someone else's edge-case backlog, not features we couldn't write.
• Roadmap gating for multisite and localization launches. #688 removes a genuine blocker for editing URL-less entries (container or structured-only content) in multisite; #682 improves the non-English editor surface. If a localization or multi-brand rollout is on the roadmap, this package's readiness belongs as a dependency line item sequenced before content migration, not after it.
• Publishing-throughput architecture: does SEO block the editor? #686 confirms report generation can run under deferred or background drivers. That legitimizes a deliberate trade-off: batch scoring off the save path for faster saves, at the cost of stale scores until the queue drains — which changes what an editor can trust in the moment. Pick one and write it down.
• Accountability placement: editors vs. a marketing/SEO function. Live previews, character counters, and a scored report push quality control upstream to whoever writes the content. Price the rollout honestly: fewer marketing-to-editorial round trips, but a real adoption cost — a walkthrough, a documented report-triage routine, and a named owner for the queue. An unowned report becomes shelfware within a quarter.
• Read adoption signals correctly, and don't let them set the roadmap. 76 stars and 0 public dependents look alarming, but this is a license-gated first-party addon installed privately — public signal is structurally blind to real usage. The decision-grade signals are vendor patch cadence and issue-tracker responsiveness, and both look healthy (five issues closed in a single patch). Treat the ~48.8 opportunity score as a prompt to validate license economics and Statamic-major fit, not as a verdict against the product.

When to Consider This Package

Adopt when:

• You are on Statamic and want SEO fields, sitemaps, redirects, and an in-CP report without bespoke code. Confirm the supported Statamic major against the 7.x line first — mixing majors is the single most common install failure, and it is a one-line check in composer.json.
• Editors, not a separate SEO function, are expected to own on-page quality. The report and rule feedback only pay off if the people authoring content actually see and act on them.
• You run multisites and/or multilingual content. #688 unblocks URL-less entry editing; #682 improves the non-English experience.
• You run deferred or background queue drivers and want SEO errors surfaced rather than silently swallowed. Brief stakeholders before deploying: after upgrade, previously invisible errors will appear, and a report spike is a correctness fix, not a regression.
• You accept a commercial license dependency inside a core content workflow, can budget renewal, and can absorb one compatibility review per Statamic major. Establish explicitly what a lapsed license does — degrade reporting, block CP editing, or merely stop updates — and put that failure mode in the risk register.
• Your needs sit inside the extension surface: custom cascade classes, custom sitemap URLs, view overrides. Validate that surface before signing, because the moment you need bespoke scoring rules beyond what's exposed, you are one step from a fork, and forking defeats the buy decision.

Look elsewhere when:

• You need real search intelligence — keyword research, rank tracking, backlink analysis, crawl diagnostics. This is not that product, and no patch release will make it one.
• You are headless or API-first. SEO data lives in the entry's seo field and does not arrive in your API resource in the shape your front end needs. That mapping is an explicit engineering work item in the consuming app, not something the addon does for you.
• You are not on Statamic. The value here is control-panel integration; ported to plain Laravel it is a thin tag renderer plus a sitemap.
• You cannot staff a queue worker. Report generation scales with entries × fields × locales, and social preview image generation needs headless Chrome (Browsershot/Puppeteer) on the worker host. Without that, the flagship report and previews are the features you paid for and cannot run.
• Editorial ownership of SEO is not going to happen. If no one triages the report and no one owns redirects, you are buying a dashboard nobody opens.

How to Pitch It (Stakeholders)

To executives: This is a small, targeted purchase that removes a recurring engineering maintenance line and closes a quality gap on every page we publish. Instead of building and owning sitemap generation, redirect management, 404 tracking, and a content-wide SEO report, we buy a first-party addon that already carries that edge-case backlog — the latest patch alone closed five real defects, including a multisite bug and a queue-related bug where errors were being silently dropped. Cost is a license plus renewal; the alternative is internal build plus permanent maintenance. It also converts SEO from an after-the-fact marketing audit into a publish-time property, which is the change that actually moves organic performance.

To engineering: Statamic auto-discovers the addon; installation is composer require plus a license key in .env and a config publish. There is no service provider to register. Scope is deliberately narrow: import the shipped SEO fieldset into one collection's blueprint, drop the head-rendering tag into the layout, and remove any hand-written <title> or meta description or you ship duplicates. Then verify the loop — publish an entry, check view source, hit /sitemap.xml, confirm a draft is excluded, create one 301 and test it in a private window. That is a fifteen-minute smoke test that surfaces version, license, and cache problems immediately. Real work items to budget: queue-backed report generation, headless Chrome for social previews, redirect handling ordered ahead of the static cache, forcing noindex outside production, and feature tests that assert rendered head tags plus a sitemap snapshot so the next patch bump is a diff rather than a leap of faith. Expect an error-report spike after upgrading past v7.15.1 — #686 means those errors were never recorded before; that is a fix, not a regression.

To the editorial and marketing leads: The fields live in the control panel next to the content, with character counters and a live social preview, and sensible defaults cascade down from site to collection so editors only type where they genuinely need a custom value. The one habit to break: never copy inherited values down into an entry "just in case" — they freeze and stop tracking the cascade. The cost is adoption, not licensing: one walkthrough, one documented routine for triaging the report, and one named owner for the queue. Do that and the marketing-to-editorial round trip on titles and descriptions largely disappears; skip it and the report is shelfware by next quarter.

The honest caveats, stated up front: low public star count and zero listed dependents reflect a privately installed, license-gated addon rather than weak adoption — judge it on patch cadence and issue responsiveness, both of which look healthy. And this does not replace keyword, backlink, or crawl tooling; it makes each page correct at the moment it ships. Those are two different budgets and should stay two different lines.