Getting Started

Install with Composer and confirm Laravel package auto-discovery. On older Laravel versions, verify the provider is registered manually.
Publish the package config first and inspect config/meta-tags.php; this is where site-wide defaults such as title suffix, description, Open Graph image, and Twitter handle usually belong.
Render the package output in your main layout <head> using the package’s documented Blade include, helper, or facade render method.
First use case: set a page title, description, canonical URL, and Open Graph tags in a controller for one page, then confirm the config defaults are used everywhere else.

Implementation Patterns

Keep global defaults in config and override per request in controllers, middleware, or a dedicated SEO action. Avoid scattering meta tag logic throughout Blade templates.
For model-backed pages, map model fields into a small meta array or DTO and pass it to the layout. Use accessors or presenters for fallback descriptions and images.
Use view composers for shared tags such as site name, default image, and social handles; use route middleware for route-group concerns such as robots directives, locale, or canonical host rules.
In Inertia or Livewire apps, set meta values server-side in the controller and render them in the root Blade layout. Do not rely on client-side-only tags for SEO-critical pages.
Add feature tests that assert the rendered <head> contains expected title, description, canonical, and Open Graph tags. A small snapshot test for key page types catches regressions quickly.
Wrap the package behind an app-level SEO service if multiple teams touch meta tags; this keeps tests and future package changes isolated.

v1.2.0 is a minor release from v1.1.1. Semver suggests no breaking changes, but the release notes only link to the changelog, so review the diff/changelog and run your test suite before upgrading. Pin the version if meta output is production-critical.
Clear and rebuild config cache after changing meta defaults: php artisan config:clear locally and php artisan config:cache during deployment.
Watch for duplicate tags if manual <meta> tags remain in layouts alongside the package output. Pick one rendering path.
Escape user-provided meta values and be deliberate about raw HTML. Titles and descriptions should not allow untrusted markup.
Define explicit fallbacks for null or empty values; otherwise you may render empty tags or unexpectedly inherit global defaults.
Check canonical URL generation behind proxies and load balancers, and verify locale/hreflang behavior if the package supports it.
Extension points to look for: publishable config and views, custom tag generators, and the underlying service binding. Prefer extending through config and an app-level wrapper over editing vendor files.