Link Checker Bundle Laravel Package

Getting Started

• Install with composer require lbonnet-gda/link-checker-bundle. Note the -bundle suffix: this is packaged in Symfony Bundle conventions, so before assuming Laravel auto-discovery, check the package for a Illuminate\Support\ServiceProvider or framework-agnostic core. If there is no service provider, register the package's core services (crawler, HTTP client, checker, reporters) manually in a small app-level provider — it's usually a handful of bindings.
• Read in this order: README.md → the package config file (crawl scope, concurrency, timeouts, reporters) → the console command entry point → the link-checker/HTTP-client service.
• The first use case worth wiring up is a console command that crawls your app's own routes or a list of seeded URLs and reports non-2xx/3xx results:

  Artisan::command('links:check {url?}', function (LinkChecker $checker) {
      $report = $checker->check($this->argument('url') ?? config('app.url'));
      $this->table(['URL', 'Status'], $report->failures()->map(fn ($f) => [$f->url(), $f->status()]));
  });
  

  (Exact class/API names will vary — match what the README exposes rather than copying the shape verbatim.)
• In v0.4.0 the robots.txt fetch path now handles and reports server errors. That means: if the checker fetches /robots.txt and gets a 5xx, that is surfaced as a reportable condition instead of being folded into a generic crawl failure. Treat this as the second thing you wire up — a reporter/notification channel for robots.txt transport errors, kept separate from broken-link reports.

Implementation Patterns

• Deploy gate. Run the checker against the freshly deployed environment in your pipeline (or a post-deploy Artisan command) and fail the job on new broken internal links. Diff against a stored baseline so pre-existing debt doesn't block every release.
• Scheduled crawl, not request-time. Put it on the scheduler (nightly, or after each deploy) and ship results to a log channel or Slack notifier. Crawling inline in a request will blow past PHP time limits on anything non-trivial.
• Separate the two failure classes. With v0.4.0 there are now two distinct signals: (a) broken links (4xx/5xx reached via the crawl) and (b) robots.txt fetch/server errors. Route them to different channels — (b) is an infrastructure/availability signal about your own host, (a) is a content/SEO signal. Conflating them makes both noisy.
• Scope the crawl explicitly. Restrict to internal hosts, cap depth and total URL count, and decide deliberately on query strings, trailing slashes, and fragments. Unbounded crawls are the most common way this package causes an incident.
• Custom reporters are the intended extension point. Implement the package's reporter/handler interface and bind your own in the container rather than post-processing arrays in a command — that keeps CI, scheduler, and ad-hoc runs consistent.
• Pair with your HTTP client config. If the package uses Laravel's Http facade or a PSR-18 client, set a sane total timeout, connect timeout, and retry policy. A link checker with no timeout will hang a queue worker.
• Local dev. Point the checker at http://localhost:8000 via sail/artisan serve; it's the fastest way to validate config before putting it in CI.

Gotchas and Tips

• v0.4.0 changes what lands in your reports. If you had alerting on the report output, expect new robots.txt error entries on the next run. Tune thresholds or filter the category before the first post-upgrade scheduled run, otherwise you'll get a burst of unfamiliar alerts.
• Distinguish "no robots.txt" from "robots.txt is broken." A 404 on /robots.txt is normal and should mean "no restrictions"; a 500 means your host is misbehaving. Verify the package makes that distinction — if it collapses both into "error," you'll get false positives on sites that simply don't ship a robots.txt.
• Respect and verify robots.txt semantics. Confirm whether a robots.txt server error results in skip or treat as allow. Whichever it is, encode that expectation in a test so a future minor release doesn't silently change crawl coverage.
• Framework mismatch is the main integration risk. A *Bundle release cadence and Symfony-style PR/issue flow means Laravel-specific docs will be thin. Pin the version in composer.json and re-run your integration test on every bump rather than relying on semver alone — this is a 0.x package, so minor versions can carry behavior changes.
• Debugging: start with a single URL (depth 0) and verbose output before running a full crawl. Most "why is nothing reported" issues are crawl-scope or host-allowlist config, not the checker.
• Politeness. Add a delay/concurrency cap against production hosts, and never point a full crawl at a third-party site you don't control.
• Watch the dependency footprint on the underlying HTTP client and crawler — conflicts here are the usual cause of a failed composer update, and there's no Laravel-ecosystem constraint to keep it in check.