Filament Rankforge Lite Laravel Package

Technical Evaluation

Architecture fit

v1.0.0 is a content-SEO package that couples three layers into one deliverable: a persistence layer (HasSeo trait → polymorphic rankforge_meta row per record), an admin layer (Filament SeoFields form section, live analysis panel, SeoScoreColumn), and a delivery layer (<x-rankforge::tags> Blade component and @rankforge directive). For a Laravel monolith already on Filament, this is a strong fit — one install covers authoring, review and rendering, with no separate SEO service to operate.

The fit is weaker if our admin surface is not Filament. The release notes describe the form section, analysis panel and table column as first-class features without stating that the persistence and rendering layers stand alone. Before committing, we need explicit confirmation that HasSeo + the tags component work headless (no Filament installed or enabled), because that determines whether this is a platform-wide standard or a single-panel convenience. The Blade component and directive are a good sign for server-rendered front ends; Inertia/React or API-driven front ends would consume the underlying meta model directly and lose the preview/analysis UI entirely.

Integration feasibility

Low-to-moderate effort for a Filament-based app: install, publish config and migration, add the trait to content models, drop the section into existing resources, add the column to index tables, and place the tags component in the layout head. Two notes materially reduce risk:

• Coexistence with ralphjsmit/laravel-seo on the same model without trait boot-method collision means we can adopt incrementally rather than big-bang, and can run both during a transition window.
• Namespace, table, migration and config-key parity with RankForge means existing RankForge content upgrades in place with no data migration — a genuine de-risker if we are already on RankForge.

The main feasibility gap is i18n storage. The package advertises hreflang output and 22 checks across 6 languages, but the persistence model is described as one row per record. If meta title/description are single columns, a multi-locale site either needs per-locale model instances or a strategy the release notes don't describe. Any site with more than one public language must resolve this before rollout.

Technical risk

• Write-path coupling (highest). Score is recalculated and persisted on every save. That means editorial saving now depends on an analysis engine. If analysis throws, is slow, or calls an external service, it can slow or block publishing. We need to know: inline or queued? synchronous or after-commit? wrapped in failure isolation? An SEO score must never be able to reject a content save.
• Coverage gaps in "every save." Saves via saveQuietly(), bulk update(), insert(), imports, seeders and direct DB writes bypass model events; the score silently goes stale. Bulk editorial imports are the common real-world case.
• Score drift and reporting. If the 22 checks change between package versions, historical scores become non-comparable. Without a stored engine/checkset version alongside the score, any trend dashboard we build is unreliable.
• Dual source of truth. Running alongside laravel-seo produces two meta stores; which one renders must be an explicit, documented decision per template, or we ship duplicate/conflicting tags.
• Output correctness. Canonical, robots and hreflang emitted by a package are directly indexable surface area. A misconfigured default (e.g. noindex inherited, or a canonical pointing at a preview domain) is a business-visible outage, not a bug.
• Analysis engine dependencies. Unclear whether scoring is local heuristic or API-backed. If API-backed: cost per save, egress of unpublished content, rate limits, and offline/dev behaviour all become procurement and security questions.
• Maturity. v1.0.0 with no prior assessment history. Single-package bus-factor, Laravel/Filament version support matrix, and semver discipline are all unproven.

Key questions

1. Does HasSeo and <x-rankforge::tags> function without Filament installed?
2. Is analysis computed inline on save, or queued? What happens on analysis failure — does the save succeed?
3. How is per-locale meta modelled given one row per record? Is there a documented multilingual pattern?
4. Is scoring local/deterministic, or does it call a third-party API? If API: cost model, data handling, rate limits, offline behaviour?
5. Are scores versioned so historical reporting survives a package upgrade?
6. Which laravel-seo fields win when both are installed on the same model?
7. Supported Laravel, PHP and Filament versions; upgrade and deprecation policy; maintenance commitment.
8. How are existing records backfilled (command? queue job?) and what is the cost on our content volume?
9. Is the score column indexed for sorting on large tables?
10. Licence terms and any telemetry.

Integration Approach

Stack fit

Assume Laravel 10/11, PHP 8.2+, Filament admin, Blade-rendered public site. Add to a single low-traffic content model first, on a non-critical section (e.g. blog, not the money pages). Confirm headless behaviour on that pilot before widening scope. If the public site is not Blade, treat the package as an authoring tool only and build a thin renderer against the meta model — do not assume the component covers us.

Migration path

Path depends on current state:

• Not on RankForge, not on any SEO package: greenfield. Publish config and migration, add trait, backfill via command, roll out UI resource by resource.
• On RankForge: upgrade in place — parity of namespace, table, migration names and config keys means no content migration. Validate by diffing rendered <head> output before and after on a sample of pages.
• On ralphjsmit/laravel-seo: run both. Add HasSeo to one model, render RankForge tags for that template, verify laravel-seo output is suppressed for the same template, then migrate template by template. Retire laravel-seo once parity is confirmed — leaving both live indefinitely is the worst outcome.

Compatibility

Verify in this order: Filament version, PHP version, Laravel version, and coexistence with whatever else hooks saved/created/updated on content models (audit logs, search indexers, revision packages). Multiple listeners on the same events are fine functionally but compound save latency.

Sequencing

1. Sandbox spike (1 week). Install, publish, add trait to one model, confirm headless rendering, measure save latency delta with and without the trait.
2. Backfill design. Decide command vs queued job, chunk size, and whether backfill respects rate limits if analysis is API-backed.
3. Pilot in staging. One content type, editors from one team. Capture score distribution to calibrate thresholds.
4. Head output audit. Automated test asserting presence and correctness of title, description, canonical, robots, OG and X tags on representative templates, including a noindex page and a paginated page.
5. Production pilot. One content type, one template, both packages live if mid-migration.
6. Widen. Remaining content types, then table columns, then retire the legacy package.
7. Editor enablement. Threshold policy, guidance on treating scores as advisory, and a rule that scores never block publishing.

Operational Impact

Maintenance

Two maintenance surfaces: the package itself (upgrade cadence, changelog discipline at v1.x) and our own configuration — the 22 checks in 6 languages are content that may be tuned or overridden, and overrides become our code to maintain. Budget a recurring review per minor version to catch score drift. If we override check weights or locale strings, document them centrally or they will silently diverge from upstream defaults.

Support

Primary support load is editorial, not technical: "why did my score drop", "why is this green but ranking badly", "why is the preview wrong". Publish an internal one-pager framing the score as a hygiene checklist, not a ranking predictor, before rollout. Secondary load is template-level tag questions from the front-end team. Third-party vendor support is unknown at v1.0.0 — assume self-support and plan accordingly.

Scaling

• Write path: scoring on every save multiplies save cost by the number of checks (and by any API calls). Measure on realistic content lengths before wide rollout; if it is inline and API-backed, push to a queue first.
• Read path: the tags component and directive will execute per request on public pages. Add a cache layer keyed on the meta record's updated_at; otherwise every page view costs a query. Confirm the package doesn't already do this.
• Sorting: SeoScoreColumn is sortable, which on large tables means a sort on a polymorphic-scoped column — needs a composite index or it will table-scan. Verify the published migration includes it.
• Bulk operations: imports and mass content refreshes will either thrash the analysis engine or bypass it. Define one sanctioned bulk path.

Failure modes

Ramp-up

Editors: roughly 30 minutes. The live panel, SERP preview and social card previews are self-explanatory, which is the package's strongest adoption lever. The required training is not mechanical but policy: what score is "good enough" for our site, and that the score is advisory. Developers: half a day for the trait/component wiring, plus the head-output test harness, which is the real work. Front-end: 1–2 hours to validate tag output against our existing templates and analytics/tag-manager assumptions. Expect the first two weeks of pilot to generate most of the questions; capture them into the internal one-pager rather than answering individually.