On Page Seo Bundle Laravel Package

Getting Started

• Install with Composer: composer require lbonnet-gda/on-page-seo-bundle. This package is distributed as a Symfony bundle, so in a Laravel app you will usually wire the underlying analyzer/report services manually or through a small adapter service provider rather than relying on auto-discovery.
• Look first at the package README, the bundle configuration file (typically config/packages/on_page_seo.yaml or equivalent), the console command classes, and the report/result DTOs. Those tell you what can be configured and what shape the audit output takes.
• Minimal first use case: run an audit against a staging URL and inspect the report for robots.txt handling. In v0.3.0, robots.txt server errors are surfaced and sites blocked by robots.txt are explicitly flagged in reports, so this is the first thing to verify after upgrading.
• A practical first check is a single-page or shallow crawl of staging, then confirm that a deliberately broken robots.txt (e.g. returning 500) is reported as a server error rather than silently treated as “allowed” or “disallowed.”

Implementation Patterns

• Wrap audits in an Artisan command and schedule them nightly or per-deploy against staging and production. Persist the report as JSON or normalized database rows so you can diff results over time.
• For larger sites, dispatch crawling/auditing to queued jobs. Keep per-job scope small (a URL group or sitemap shard) to avoid timeouts and to make retries safe.
• Treat v0.3.0’s “blocked site” flag as a first-class CI signal. In a pre-deploy smoke test, fail the build when key pages are reported as blocked by robots.txt or when robots.txt returns a 5xx.
• Pair the package’s report output with Laravel notifications/events: send a Slack or email alert when a new robots.txt server error or blocked-site flag appears between runs.
• If the bundle exposes analyzer/check interfaces, implement custom checks for your own SEO rules and register them in configuration. Keep custom checks idempotent and side-effect free so they compose with built-in checks.
• Normalize report ingestion behind a small application service. That way, if the report schema changes in a future release, you update one adapter instead of scattering parsing logic across commands and jobs.
• Use a consistent user agent and HTTP timeout configuration for audits. If the bundle uses its own HTTP client, align it with your Laravel HTTP client settings so staging/production behavior matches.

Gotchas and Tips

• Distinguish robots.txt 5xx from 4xx and from an explicit Disallow. A server error is not the same as a deliberate block; v0.3.0 surfaces both, so confirm how your report consumers interpret the new flag before failing builds on it.
• Watch for CDN or reverse-proxy caching of robots.txt. An audit may see a stale or cached response, especially after a deploy that changes robots directives.
• Symfony bundle DI in Laravel is the main integration friction point. Check whether the package ships a Laravel service provider; if not, instantiate services directly or build an adapter and bind it in your own provider.
• Version-pin and review report schema changes. v0.3.0 adds blocked-site reporting, which may introduce new fields or status values; update any strict parsers, snapshots, or dashboard mappings.
• Set explicit timeouts for robots.txt fetches. A hanging robots.txt endpoint can slow an entire audit, and the new server-error handling only helps if the request actually completes or times out predictably.
• For debugging, run the audit with verbose output and inspect the raw robots.txt response (status, headers, body). Log the URL and status code when a server error is flagged so you can reproduce it outside the package.
• Keep extension points minimal and documented: custom checks, report formatters, and event/listener hooks are safer integration seams than overriding internal analyzer classes.
• Re-run a baseline audit immediately after upgrading to v0.3.0 and diff it against the previous report. The new robots.txt handling can change previously “clean” results into flagged results, and you want that delta understood before it hits a scheduled CI gate.