- How do I install ralphjsmit/laravel-seo in a Laravel application?
- Install it with composer require ralphjsmit/laravel-seo. Then publish the migration and config with php artisan vendor:publish --tag="seo-migrations" and php artisan vendor:publish --tag="seo-config", and run php artisan migrate. Finally, add {!! seo() !!} inside the <head> of your Blade layout and remove any hard-coded meta tags. The service provider is auto-discovered, so no manual registration is needed.
- Which Laravel and PHP versions does laravel-seo support?
- Supported versions are declared in the package's composer.json constraints, so check that file directly on Packagist or GitHub before adopting rather than trusting release-date metadata alone. Confirm that your target Laravel 11 or 12 and PHP 8.3+ setup satisfies those constraints. Because the provider is auto-discovered and the package follows a conventional structure, upgrading within supported ranges is typically low risk. Verify the last release date and cadence over the past 12 months as part of your review.
- How do I attach SEO fields to an Eloquent model with laravel-seo?
- Add the HasSEO trait to any Eloquent model, which gives it a polymorphic seo relation. You can then read and update fields with $post->seo->update(['title' => 'My great post', 'description' => '...']). The same trait works on any model, so pages, products, and categories all follow one pattern. Because the relation is polymorphic, no schema changes are required on your own tables.
- Can I generate SEO data dynamically without saving it to the database?
- Yes. Implement getDynamicSEOData() on the model and return a SEOData object with only the properties you want to override, such as title, description, and image. The package resolves values through a cascade: transformer, then getDynamicSEOData(), then the stored seo model, then config defaults. This means existing model columns can drive SEO output with zero extra work from editors.
- Do I need to remove existing title and meta tags from my Blade layout?
- Yes, and this is the biggest source of integration friction. The package renders the title, canonical, robots, and OpenGraph tags itself, so any hard-coded equivalents left in the layout will produce duplicate tags. Build an explicit checklist of every tag to delete per layout before rollout. Keep a single {!! seo() !!} call in the head and nothing else competing with it.
- Are SEO field values escaped to prevent XSS when rendering {!! seo() !!}?
- The integration uses unescaped output via {!! seo() !!}, so you must confirm how titles, descriptions, and author values are concatenated before they reach the HTML. If any of those fields can be edited by users or CMS authors, treat escaping as a hard gate rather than a nice-to-have. Verify it by code review or a dedicated test that submits a payload containing angle brackets and checks the rendered output. Do not ship SEO fields editable by non-trusted users until that is confirmed.
- Does laravel-seo cause N+1 queries on index and listing pages?
- The seo relation is loaded per model, so rendering a list of posts without eager loading will add a query per item. Use with('seo') on your index and listing queries to collapse that into a single query. This is easy to miss because the SEO layer otherwise looks invisible in the Blade template. Add it to your query review checklist alongside your other relations.
- How do I test that laravel-seo renders the correct tags?
- Assert on the rendered output rather than just checking that the page returns 200. Use response assertions to confirm the expected title, description, canonical, and OpenGraph values appear in the head. This matters because missing config values silently produce missing tags instead of errors, so bad SEO is invisible in logs. Cover both a database-backed seo model and a getDynamicSEOData() model in those tests.
- Does laravel-seo support multiple languages and hreflang alternates?
- Yes, the package renders alternate links (hreflang) and defaults the locale to app()->getLocale(). You still have to curate the alternate sets manually per page, so multi-region SEO is only partly automated. If multi-locale SEO is in scope for your first release, plan for that curation work explicitly. Otherwise, defer hreflang and ship a single-locale setup first.
- Is laravel-seo actively maintained, and what is out of scope?
- It is MIT licensed with a single maintainer and no commercial backing, so plan an internal fork-and-patch fallback before depending on it heavily. It deliberately does not generate sitemaps (the README points to spatie/laravel-sitemap), does not produce Open Graph images, and ships no admin UI for editors. Those are adjacent workstreams to schedule separately. Confirm release cadence and the actual dependent count on Packagist and GitHub rather than relying on summary metadata.