tomatophp/filament-seo
A Filament plugin for Laravel admin panels that lets you manage SEO titles, meta descriptions, Open Graph tags, and related metadata for your models and pages directly from the dashboard.
Buy vs. build for baseline SEO admin tooling. Editable meta titles, descriptions, keywords, Open Graph/Twitter cards, and canonical URLs are table stakes, not differentiators. This package collapses roughly one to two sprints of work — form schemas, a polymorphic seos table, a HasSeo trait, sitemap/robots generation, and Blade tag rendering — into an installable MIT dependency. The build case is weak; the buy case is strong, contingent on the maintenance caveats below.
Drawing an explicit line between "baseline SEO" and "SEO as a product bet." Adopting this package is a roadmap decision to fund editorial hygiene (per-record metadata, social preview cards, verification tags) and deliberately defer search strategy (redirect management, hreflang, JSON-LD authoring, programmatic page generation, chunked sitemaps at scale). It gives you a defensible "we shipped SEO" milestone without committing headcount, and makes the deferral intentional rather than accidental.
Editorial ownership and publish-loop velocity. The product win is workflow, not markup. SEO fields live inside the same Filament resource form where editors already write the post or product, which removes an engineering ticket from the publish path. If marketing is currently shipping pages with empty meta descriptions or generic OG images, this is a measurable content-quality intervention with a short payback period.
Cheap, reversible piloting. As a panel plugin it maps to admin UX, not public site architecture. You can pilot on a single model or route group behind a flag, keep the legacy <head> renderer untouched, diff the emitted tags against a page sample, and decide from evidence. Low blast radius, reversible, shippable in an afternoon for the admin-only phase.
De-risking the dependency decision through a fork plan. The code surface is small — a form schema, a model, a trait, a Blade partial — so "we can fork the view layer in an afternoon" is a credible escape hatch. That materially changes the risk calculus for adopting a 15-star, single-maintainer package.
Scoping decisions the package forces you to make now, not later: which models get SEO treatment and in what order (blog → pages → products), whether canonical URLs are derived in code or editor-editable (recommend derived, read-only, with logged overrides), and where OG images come from (recommend the existing media library, not a second upload path).
Consider adoption when all of the following hold:
<title> emitters is the single most common way this goes wrong.seo relation, null-safe filled() rendering, and a seo:export command before you write a single row.Look elsewhere — or budget significant custom work — when:
seos table has no tenant column by default and tenant scoping is unverified. You'll need your own migration and global scope, tested before the pilot — not after.composer.json constraint. Check that constraint before anything else; it tells you more about your upgrade roadmap than the README does.artesaos/seotools or a hand-rolled meta partial with no appetite for a migration. Consolidation is a prerequisite, not a follow-up.For executives: This is a small, MIT-licensed admin plugin that gives marketing direct control over page titles, meta descriptions, social sharing cards, canonical URLs, and sitemap/robots output — inside the CMS they already use. It replaces one to two sprints of custom build with a dependency, and it removes engineering from the routine publish path. The strategic framing is deliberate: we are funding content hygiene now and deferring search strategy (redirects, structured data, programmatic pages) as a separate, explicitly-scoped bet. Risk is bounded and named: a small codebase we can fork in an afternoon, a pinned version, an internal owner, and a phased rollout that starts admin-only with zero impact on the public site and flips per route group only after a diff of the rendered HTML. Success is measurable — percentage of published records with a non-empty meta description, social card coverage, and no drop in indexed pages.
For engineering: Treat this as an editing surface plus a data model, not an output contract. Adopt the HasSeo trait and the seos table as the reliable part; treat the Blade view path as replaceable and write the partial against the seo relation so a broken upstream view is a one-file swap. Install with an exact version pin and verify the filament/filament and php constraints on day one. Non-negotiables before the first record ships: a snapshot test asserting the exact <head> block, eager-loading seo on every listing and sitemap loop, filled() guards against empty strings, canonical derived in code rather than authored by editors, any Google API integration running in scheduled jobs with backoff against a non-production property, and an export command so we can walk away cleanly. Effort is small; the discipline is what makes it cheap to own.
How can I help you explore Laravel packages today?