Seo Laravel Package

Product Decisions This Supports

• Multi-tenant / multi-store architecture (build vs. buy gate). The headline capability in v1.8.0 is support for models whose getMorphClass() returns a non-class identifier (e.g. App\Models\Record:products), i.e. one Eloquent model backing several tables. This is the classic shape of a shared-schema or per-tenant-table design. If multi-tenancy, multi-brand, or per-storefront content is on the roadmap, this release is a prerequisite rather than a nice-to-have — without it, SeoMeta::seoable and SitemapEntry::sitemapable throw Class "…" not found on exactly those records.
• Organic acquisition as a roadmap line item. SEO metadata, sitemap generation, hreflang, and content analysis are commodity capabilities. The decision this package supports is "buy/adopt, don't build" — the differentiated work is in your content model and templates, not in emitting <link rel="alternate"> tags.
• Internationalisation / localisation scoping. HreflangService handling morph-map aliases and resolver-backed types is what makes a multi-locale, multi-domain rollout safe when content types aren't plain class names. Relevant when deciding whether i18n SEO lands this quarter or next.
• Feature: polymorphic SEO across content types. The resolver filter (ap.seo.resolveMorphModel) is an explicit extension point — a product decision to support content types the package can't infer, rather than forcing a schema refactor to make types class-nameable.
• Risk item for the roadmap: cache correctness. The cache-key fix (meta:<class>:<table>:<id>) closes a genuine cross-contamination path — records of one model class spread across several tables previously shared a cache entry and could serve each other's SEO data. If you ship multi-tenant today, treat this as a compliance/brand-safety fix, not a performance tweak.
• Upgrade scheduling. Minor version, additive extension point, and self-healing cache invalidation ("existing entries simply miss once and are rebuilt"). Low-cost upgrade; slot it into the current maintenance window rather than treating it as a migration project.

When to Consider This Package

Consider adopting when most of the following hold:

• Laravel/PHP stack — the package is Laravel-idiomatic (Eloquent relations, service provider config, filters/hooks). Outside Laravel, evaluate standalone SEO tooling instead.
• Multiple content types share SEO concerns — you attach metadata and sitemap entries polymorphically across pages, posts, products, categories, etc.
• Morph maps are in play, or will be. If any model uses a custom getMorphClass(), or a single model serves multiple tables, v1.8.0 is the minimum viable version. Earlier versions will hard-fail on those records.
• You need sitemap generation + hreflang + stored analysis in one place, rather than stitching three packages together.
• You accept a config-registration step. The resolver is opt-in: you must register the ap.seo.resolveMorphModel filter and map identifiers to model instances. Unresolved types fall back to prior behaviour, so partial adoption is safe, but the benefit only materialises if you wire it up.
• You have a warm-cache invalidation story. The cache-key change is self-healing but does cost one cold rebuild per entry; on a large corpus, plan for the hit.

Look elsewhere when:

• You need a full content-marketing or editorial suite (briefs, keyword tracking, SERP monitoring) — this is metadata plumbing, not an SEO platform.
• You have a single content type in a single table. The polymorphic machinery is overhead you will never exercise.
• You require contractual support/SLA or vendor indemnity; a community package with patch-level churn may not clear procurement.
• You have tests asserting the previous meta:<class>:<id> key shape — those will break; budget a small test-fix task.

How to Pitch It (Stakeholders)

To executives: This release makes our SEO metadata and sitemaps correct for multi-brand and multi-tenant setups, where one content model spans several tables. Two things matter commercially. First, it unblocks the multi-storefront roadmap item that currently cannot ship with accurate SEO data. Second, it fixes a defect where records in different tables could serve each other's cached SEO metadata — a brand-safety and, in some markets, a compliance exposure. Adoption cost is low: it is a minor version, behaviour for existing single-table setups is unchanged, and stale cache entries rebuild themselves automatically.

To engineering: v1.8.0 adds an ap.seo.resolveMorphModel filter plus a ResolvesMorphModels trait and ResolvableMorphTo relation, so lazy loading and eager loading (with('seoable'), with('sitemapable')) both resolve non-class morph types through configuration rather than reflection. Unresolved types retain prior behaviour — the change is strictly additive. HreflangService cache clearing now consults MorphModelResolver::canResolve(). Cache keys gain a table segment (meta:<class>:<table>:<id>, same for analysis:), which fixes cross-table bleed and self-invalidates once. Action items: register the resolver filter for any model using a custom morph class, and update any tests asserting the old key format.