Technical Seo Bundle Laravel Package

Getting Started

First, confirm what you're installing. The package name ends in -bundle, which is Symfony terminology. Before wiring it into a Laravel app, check the README/composer.json for a Laravel service provider (extra.laravel.providers) or an explicit Laravel bridge package. If there isn't one, you'll be registering the services manually or via a thin adapter — budget for that.

Minimal steps:

1. composer require lbonnet-gda/technical-seo-bundle:^0.5
2. Publish config (if a provider exists): php artisan vendor:publish --tag=technical-seo-config
3. Set the base URL the auditor should crawl against — do not rely on APP_URL blindly, since it often points at localhost in dev/staging and will produce a sitemap full of unreachable URLs.
4. Look first at the config file for sitemap source/path and the HTTP client options (timeout, concurrency, user agent). These two knobs determine whether your first run takes 5 seconds or 5 hours.
5. First use case: audit your own production sitemap in a console command and dump the detected issues to the log. That gives you an immediate signal on value before you wire anything into CI.

// routes/console.php or a dedicated command
Artisan::command('seo:audit', function () {
    $report = app(SitemapAuditor::class)->audit(config('technical-seo.sitemap_url'));
    foreach ($report->issues() as $issue) {
        $this->warn("[{$issue->type()}] {$issue->url()} — {$issue->message()}");
    }
});

Class names above are placeholders — resolve the real FQCNs from vendor/lbonnet-gda/technical-seo-bundle/src before writing anything permanent.

Implementation Patterns

Scheduled audit, not request-time. Sitemap auditing is an outbound HTTP workload over potentially thousands of URLs. Put it on the scheduler, off-peak, and make it a queued job if you need per-URL parallelism:

Schedule::command('seo:audit')->weeklyOn(1, '03:00')->withoutOverlapping();

Separate generation from auditing. Even though v0.5.0 bundles auditing alongside sitemap work, treat them as distinct concerns: generation is cheap and can run on deploy; auditing is slow and should run on a schedule. This also lets you audit external sitemaps (a client's site, a competitor's) without touching the generator.

Diff the issues between runs. An audit that reports the same 40 broken links every week gets ignored by week three. Persist the issue set (JSON column or a small seo_audit_issues table) and notify only on new issue types/URLs. This is the single highest-leverage addition you can make on top of the package.

Gate deploys on regressions, not on absolute counts. In CI, run the audit against the staging URL list and fail if the issue count increased versus the previous build. Failing on "any issue" makes the check unusable on a legacy site.

Use it as a pre-flight for sitemap submission. After generating a sitemap, run the auditor over it before the deploy step that pings Google. Catching a malformed <loc> or a non-200 URL here is much cheaper than debugging Search Console coverage reports later.

Extension points to reach for first: if the package exposes a check interface or a registry of validators, register your own app-specific rules (e.g. "every product URL must be reachable without a redirect", "localised URLs must return hreflang headers"). Custom checks let you encode your team's actual SEO rules rather than only the built-ins.

Gotchas and Tips

• Sitemap hard limits. The protocol caps a sitemap at 50,000 URLs and 50 MB uncompressed. If you're near either, verify the package splits into sitemap index files — an audit that silently truncates gives you false confidence.
• Auditor vs robots.txt. Your auditor's user agent may be blocked by your own robots.txt in production, producing a wall of false "403/blocked" issues. Either whitelist the auditor UA or audit from an environment where it isn't filtered.
• HEAD is not GET. If the checks use HEAD for speed, some servers/CDNs return 405 or inconsistent status codes for HEAD while serving GET fine. Confirm which verb is used before acting on the results.
• Redirects need a policy decision. Is a 301 to a canonical URL an "issue" or expected? Configure the redirect-following depth and status expectations explicitly; otherwise you'll drown in noise from a site that legitimately redirects www or trailing slashes.
• Rate limiting and politeness. Auditing your own prod site from a scheduled job is fine; auditing a client's or third party's is not, at default concurrency. Set concurrency to 1–2, respect Crawl-delay, and set a real timeout — a hung connection will stall the whole batch.
• Memory on large sitemaps. If it loads all URLs into an array before checking, a 50k-URL sitemap plus response objects can blow past memory_limit. Test with a realistic sitemap before trusting it in production, and prefer a generator/streaming API if one exists.
• Environment leakage. The most common self-inflicted bug: auditing http://localhost URLs because APP_URL was inherited from .env.example. Assert the base URL scheme/host at the top of the command and fail loudly.
• v0.5.0 is pre-1.0. Expect breaking changes in the 0.x line; pin ^0.5 and read each changelog. The auditing feature is brand new here — treat its issue detection rules as a starting point to be tuned, not as ground truth, and verify a few reported issues by hand before surfacing them to stakeholders.
• Debugging tip: run the audit against a tiny hand-written sitemap (5 URLs, one deliberately broken) first. If the issue detection doesn't flag the deliberately broken URL, the problem is configuration, not the package.