- How do I install backstage/laravel-seo-scanner in a Laravel project?
- Install it as a dev dependency with composer require --dev backstage/laravel-seo-scanner, since it is a build-time inspection tool rather than a request-path component. Laravel package auto-discovery registers the service provider, then you publish the config with php artisan vendor:publish and run the scanner's artisan command against your route list. A Laravel developer should be able to reach a first report in well under an hour.
- Does Laravel SEO Scanner crawl my site over HTTP or resolve routes internally?
- Confirm this early, because the documentation does not make the scanning model unambiguously clear. If it issues outbound HTTP requests to your own app, you need correct base URL, host header, proxy, and TLS configuration, which is a frequent source of silent failures in Docker, behind load balancers, or in CI. If it resolves routes internally through the framework instead, it sidesteps network config but may not reflect production middleware such as auth, redirects, or caching.
- Which Laravel and PHP versions does backstage/laravel-seo-scanner support?
- Check the package's composer.json for exact PHP and illuminate/support constraints, and compare them against both your current and next-upgrade Laravel version. The project shows a single release so far, so verify whether the version line is pre-1.0 with likely breaking changes or already stable. Adding a CI matrix job that installs the package is a cheap way to catch compatibility drift before it reaches a feature branch.
- Can I run the SEO scanner in CI and fail the build on regressions?
- It depends on whether the package exposes a CI mode with non-zero exit codes and machine-readable output such as JSON or SARIF, which the current documentation does not clearly confirm. If it only renders a human-readable report, you can still run it on a schedule and triage findings manually, or wrap its output in your own threshold check. Because it is a require-dev tool with no runtime dependency, the worst case for a CI job is a failed build rather than a production incident.
- Does Laravel SEO Scanner work with Inertia, Vue, or React SPA front ends?
- Only partially. With SPA front ends the server response is usually just a shell, so the scanner will either see almost nothing or score the shell markup instead of your rendered page. If your application is mixed, scope the scanner to the server-rendered route group and use a rendered-DOM or Lighthouse-based tool for the client-side routes.
- How do I choose which routes the scanner should audit?
- Point it at the route groups that carry organic acquisition value, such as marketing pages, blog posts, documentation, and e-commerce category or product pages. Excluding admin, API, auth-gated, and noindex routes keeps the report focused and avoids false positives. The real effort in adopting this package is deciding what your SEO surface actually is, not the installation itself.
- What SEO issues does the scanner check for?
- It inspects rendered HTML and flags common problems around titles, meta descriptions, headings, links, image alt text, canonical tags, robots directives, sitemap and robots.txt presence, and Open Graph tags. Each page receives a score alongside actionable recommendations. Treat that score as an opinionated rubric rather than a ranking predictor, and prioritize the concrete markup fixes underneath it.
- Does the SEO score actually predict Google rankings?
- No. The score is a fixed heuristic rubric, not a ranking signal, and search engine guidance changes constantly, so the package's checks will inevitably lag behind it. Use the findings as a checklist for fixing real markup issues rather than optimizing the number itself. Blast radius stays low because the tool sits outside the request lifecycle and never serves live traffic.
- Is backstage/laravel-seo-scanner safe to use in production?
- It is intended as a pre-deploy inspection tool installed with composer require --dev, not a request-path component, so it should not be enabled against production traffic. No schema changes or middleware unwinding are expected, which means removal is just deleting the Composer entry. Still confirm whether any scan data is persisted and where, especially if you run it against a production-like environment.
- How is the package maintained, and what is the exit plan if it is abandoned?
- Ecosystem validation is thin: roughly 274 GitHub stars and essentially zero dependents, so there is little third-party production signal. It looks like a small-team or single-maintainer project with a single release so far, so treat it as adopt with an exit plan rather than adopt and forget. Keeping it in require-dev means you can remove it by deleting one Composer line, with no migration or middleware to unwind.