Seo Bundle Laravel Package

Getting Started

First, verify what this package actually is. Despite being catalogued as a Laravel package, rzproject/SeoBundle is a Symfony bundle — it wires up via bundles.php, a Symfony Extension/Configuration pair, and a Twig extension. It will not composer require into a Laravel app and work. If you're on Laravel, read it as a reference implementation and stop there; do not attempt adoption.

If you're on Symfony and inheriting it (the realistic scenario given it's archived with 0 stars / 0 dependents), the fastest orientation is:

1. Open DependencyInjection/Configuration.php — this is the canonical list of every default and per-page override the bundle supports. It's effectively the feature inventory.
2. Open the Twig extension — this is where tag rendering, escaping, and directive behavior lives.
3. Open the sitemap generator — this is the piece most likely to have scaling assumptions baked in.

First use case to validate: per-page metadata override on a single content route. Set title, description, and canonical for one entity, render the page, view source, and diff against what you'd expect. If that works, walk the sitemap endpoint. If the sitemap builds synchronously against a large URL set, that's your first problem to design around.

Before anything else, confirm the stack: is the target Laravel, Symfony, or framework-agnostic? A Symfony bundle on a Laravel shop is the wrong artifact, and the bridge cost (a spike to run two frameworks, or a 2–3 week port) exceeds the value of a feature set that's mostly CRUD over metadata columns.

Implementation Patterns

The only pattern that makes sense for this package is extract, don't adopt.

Feature inventory as a requirements doc. Read the bundle's source to enumerate its surface: title, meta description, canonical URL resolution, robots directives, Open Graph tags, Twitter cards, sitemap generation. Use that as a checklist when writing your SEO spec — it's a cheap way to remember the edge cases (pagination-aware canonicals, per-locale metadata, URL normalization) that a naive implementation forgets.

Rebuild behind an internal contract. Define a SeoManager interface — setTitle, setDescription, setCanonical, addStructuredData, render() — before writing any implementation. This is the highest-leverage decision: it decouples the product from whichever library or hand-rolled code ends up underneath. A Laravel implementation is roughly a service provider plus model accessors plus a Blade component; a few hundred lines.

Per-page overrides pattern. If you're mirroring the bundle's behavior, the pattern is: config defaults → route or entity override → render. Store metadata explicitly in the database (title, description, canonical, noindex flag, og_image) rather than deriving it at render time, so content editors can change it without a deploy.

Blade integration (Laravel rebuild). Use a component — <x-seo-meta :model="$page" /> — that reads from the SeoManager singleton. Keep the manager populated in middleware or a view composer, not scattered across templates.

Sitemap pattern. For anything above low-thousands of URLs, generate into a queue, cache a sitemap index, and refresh on a schedule. Never build the full sitemap on-request.

Migration path if this is already in a Symfony tree. Do not fork. Forking an archived repo means permanent ownership with no upstream to rebase against. Rebuild behind the contract, ship behind a config flag, and compare rendered HTML against production before cutting over.

Gotchas and Tips

• The Laravel/Symfony mislabel is the trap. Anyone skim-reading the catalog entry and running composer require rz/seo-bundle in a Laravel app will get a confusing failure. Surface the stack mismatch before the adoption conversation starts.
• Archived means no CVE response. No security advisories, no PHP 8.3/8.4 compatibility work, no Laravel 10/11/12 support. The failure mode is a silent break at the next runtime bump, not today. If it's transitively present in composer.lock, that's a "plan the exit" roadmap item.
• SEO regressions are silent. Crawlers don't error — they de-index over weeks. A malformed canonical or a duplicate title is not caught by a 200 status. Add automated output assertions in CI: valid canonical present, no duplicate titles sitewide, sitemap URL set matches indexable URLs. Manual spot-checks are not sufficient.
• Attribute escaping. Titles and descriptions interpolate into HTML attributes. Unescaped output is both an XSS vector and a broken-markup vector. If you lift any rendering code, run it through PHPStan/Larastan and add escaping tests.
• Sitemap scaling is the real risk. Bundles of this vintage frequently generate the full sitemap synchronously. At tens of thousands of URLs that times out or exhausts memory, and it surfaces as a crawl error in Search Console days later. Verify chunking before trusting it; assume you need queue + cache + scheduled refresh regardless.
• Cache staleness. Cached metadata or a cached sitemap serving stale canonicals after a content edit is a common, quiet bug. Wire cache invalidation to the content-save event, not to a timer.
• License and provenance are unknowns. License terms, test coverage, and last-commit date all need to be confirmed before this enters a dependency tree — and an archived repo can't be patched upstream if something surfaces.
• robots.txt helpers are usually static text. Don't expect dynamic per-environment behavior from a helper of this vintage; verify before relying on it.

One-line summary: treat rz/seo-bundle as a spec, not a dependency — read it, extract the feature checklist, rebuild behind a thin SeoManager contract you own.