Seo Bundle Laravel Package

Product Decisions This Supports

• Turning SEO hygiene into a merge gate. The package's contract is the exit code, decided solely by --fail-on. That means a PM can treat SEO regressions the same way as failing tests: a PR that introduces broken hreflang, missing meta, or bad canonicals stops the build. This is a policy decision (which severities block a deploy) expressible as a single flag, not a bespoke integration.
• Build vs. buy for site auditing. A self-hosted PHP CLI that reads a Laravel app's own routes and emits a stored JSON report competes directly with paid crawlers for the regression-prevention job — which is the job that actually protects organic traffic between quarterly audits. Buy the crawler for research; build the gate.
• Prioritizing template fixes over page fixes. The v0.5.0 summary answers a question the old table couldn't: 94 hreflang_missing_x_default issues across 94 distinct pages signals one broken layout, not 94 broken pages. That reframes a backlog item from "94 tickets" to "one template change," which is a roadmap-level insight, not just nicer output.
• Deciding how much SEO work fits in a sprint. The dozen-line summary makes the cost of an audit readable at a glance in standups and ticket descriptions; the 161-row table did not get read at all. Adoption of a quality tool is usually decided by whether its output is consumable by the people triaging it.
• CI ergonomics as a first-class product surface. The release explicitly rejects terminal sniffing: piped, redirected, and live output behave identically, and verbose output never changes the exit code. That is a decision that makes the tool safe to embed anywhere without per-environment flags.
• Reporting durability. The JSON report has always carried every issue regardless of console verbosity. Any downstream dashboard, trend line, or exec report can be built on it without the console format being a dependency — de-risking future format churn.

When to Consider This Package

Consider it when:

• The product runs on Laravel or a PHP stack and its routes are knowable to the app — this is where the package's leverage is highest.
• You want SEO quality enforced in CI on every pull request, not discovered in a quarterly crawl.
• Your team is comfortable with exit codes and JSON as interfaces; there is no hosted UI to evaluate, so the stored report is the integration point.
• You need deterministic, environment-agnostic output — build logs, cron jobs, redirected artifacts — and cannot afford a tool that changes behavior based on whether a TTY is attached.
• You want a cheap, dependency-light first step before committing to a commercial SEO platform.

Look elsewhere when:

• You need JavaScript-rendered crawling of a SPA or a site whose routes the app doesn't own.
• The audience is non-technical stakeholders who need dashboards, history, and trend visuals — the JSON is a substrate, not a product.
• You need performance/Core Web Vitals, backlink, or keyword data; this is an on-page/structural audit, not a full SEO suite.
• You are not on PHP, or you need to audit third-party or competitor sites at scale rather than your own application.
• You need SLA-backed support or vendor accountability — verify the maintainership and release cadence against your risk tolerance before it becomes a release blocker.

Also note the version: this is 0.5.0. The interface is settling but the project has not declared stability. Adopt it behind a CI job where a breaking change costs you a config edit, not a production incident.

How to Pitch It (Stakeholders)

For executives: This is a low-cost way to stop shipping SEO regressions. Today, structural SEO mistakes — broken canonical tags, missing hreflang, malformed metadata — are found weeks later in a crawl, after they've been indexed. This package turns those checks into a build step: if a change would break SEO hygiene at or above a severity we choose, the deploy fails. On a 152-page site it condenses 161 raw issues into an 11-line summary and points at the nine that actually block a release. Crucially, it surfaces whether a defect is systemic — one template affecting 94 pages — or isolated, which is the difference between a one-line fix and a 94-ticket backlog. The stored report is stable and machine-readable, so trend reporting can be layered on later without re-platforming.

For engineering: No configuration, no migration, no runtime dependency in the request path — it's a CLI over an existing report. The contract is narrow and deliberate: --fail-on alone determines the exit code; adding -v to a green build keeps it green. Console output is never terminal-sniffed, so piped and redirected output is byte-identical to a live run and needs no CI-specific flags. The detail view lists exactly the issues that decide the exit code, with a line accounting for what's counted but not shown; -v restores the full listing. The summary is derived from the same report object as the detail, so the two cannot drift. Page URLs remain terminal hyperlinks. If you were pasting or grepping full output, add -v — that's the entire upgrade. The JSON report is unchanged and has always carried every issue.