- Is rmzamora/seo-bundle a Laravel package?
- No. Despite the name, rmzamora/seo-bundle is a fork of Symfony's SonataSeoBundle and plugs into the Sonata Admin and SonataCore ecosystem. It ships no Laravel service provider, facade, publishable config, or Blade integration, so nothing in it binds to a Laravel application. Treat it as a Symfony artifact rather than a Laravel SEO package.
- Can I install rmzamora/seo-bundle in a Laravel app with Composer?
- Composer may resolve the package, but installing it into a Laravel app adds dead weight rather than working behavior. Without a service provider or framework hooks, none of its SEO features activate in Laravel. Its vintage Symfony and Doctrine constraints may also block installation on modern PHP 8.x runtimes. For a Laravel project, do not add it to composer.json; use it as a reference only.
- Does rmzamora/seo-bundle have a Laravel service provider or publishable config?
- No. There is no Laravel service provider, no config/seo.php to publish, and no Blade directives or response-layer integration. Configuration follows Symfony bundle extension conventions aimed at Sonata Admin and Doctrine. Any Laravel-style config surface would have to be written from scratch.
- Which Laravel and PHP versions does rmzamora/seo-bundle support?
- There is no Laravel version support matrix because the package is not Laravel-native. Sonata bundles of this vintage assume Symfony 2.x/3.x and older Doctrine ORM idioms, and their PHP constraints will likely block install on current PHP 8.x runtimes. Check the composer.json constraints before assuming compatibility, and expect no compatibility work for modern Symfony or Laravel releases.
- How do I test SEO meta tags and Open Graph output with this package?
- There is no visible test or CI signal for this fork, and because it does not run in Laravel there is no framework behavior to test as-is. If you reuse its metadata schema in your own implementation, write Laravel feature tests that assert the rendered title, meta description, canonical, robots, and Open Graph tags in the response HTML. Snapshot or Blade assertion tests plus a preview screen for editors cover most regressions.
- Is rmzamora/seo-bundle safe to use in production for SEO metadata?
- It is archived and unmaintained, with zero stars, zero dependents, and single-fork provenance. There is no issue triage, no security patching, and no compatibility work for current PHP or Symfony releases. SEO markup is a customer-facing surface, so an unpinned, unowned dependency there is a poor risk trade. If you adopt it, you become the sole maintainer of record from day one.
- What are the best maintained Laravel SEO alternatives to rmzamora/seo-bundle?
- For Laravel, evaluate spatie/laravel-seo, ralphjsmit/laravel-seo, and artesaos/seotools first; all are maintained and framework-native. Compare them on the fields you need: title, meta description, keywords, canonical, robots directives, Open Graph, Twitter cards, and sitemap support. In most cases a maintained package covers 80 to 100 percent of the Sonata field set, and the remaining gap is your own content model rather than the package.
- How do I add SEO meta fields to Eloquent models if I reuse this bundle's schema?
- Model the Sonata metadata schema as a polymorphic Eloquent table with subject type, subject id, locale, and the field set: title, description, keywords, canonical, robots, Open Graph, and Twitter card values. Add a trait or relationship on the content models and expose the fields through Filament, Nova, or Blade forms for editorial overrides. Resolve metadata in a view composer or layout partial so defaults fall back cleanly per page.
- Can rmzamora/seo-bundle generate sitemaps and robots.txt for Laravel?
- Not directly. Sitemap and robots generation in Sonata SEO is wired through Symfony and Sonata hooks, not Laravel routes, commands, or queues. In Laravel you would reimplement this with a maintained sitemap package or a scheduled job that writes the XML, and serve robots.txt from a route or static file. That work is part of the greenfield build, not something the dependency provides.
- Why use this fork instead of the upstream Sonata SEO bundle, and how do I migrate existing Sonata SEO data?
- If you are on Symfony or Sonata, use the upstream Sonata SEO bundle rather than this fork; upstream has maintainers and version guarantees, while this republished fork has no adoption trail. If you are on Laravel, evaluate a framework-native SEO package and keep this repository only as a design reference. If you later find inherited Sonata-era SEO data, migrate it with a one-off ETL that maps the Sonata metadata table into your polymorphic metadata table rather than keeping a runtime dependency.