Sulu Indexnow Bundle Laravel Package

Technical Evaluation

Framing correction: this is not a Laravel package. kreativsoehne/sulu-indexnow-bundle is a Symfony bundle for Sulu CMS (a Symfony-based content management platform). The first decision is stack applicability, not version selection.

Architecture fit

• The package is a thin integration layer over IndexNow (the Bing/Yandex/Naver/Seznam URL submission protocol). Its value is event wiring and address resolution inside Sulu — not protocol complexity. The underlying call is a single authenticated POST.
• v2.0.0 correctly follows Sulu 3's architectural pivot: documents and PagePublishedEvent are gone, publishing is now a workflow transition, and addresses live in the route table. Subscribing to PageWorkflowTransitionAppliedEvent / ArticleWorkflowTransitionAppliedEvent and resolving via the route repository is the idiomatic Sulu 3 hook.
• Splitting one package into per-generation majors instead of maintaining a runtime version switch is the right call for a small maintainer. The cost is two maintained lines; the benefit is one clean code path, one PHPStan config, one CI job.
• The unpublish semantics are the most substantive design change and they are correct: Sulu 3 retains the route and serves 404, so a withdrawn page must still be reported or it lingers in the index.

Integration feasibility

• Sulu 3 only. Composer constraint sulu/sulu: ^3.0. Not installable in a Laravel application and not meaningful in a Symfony app without Sulu (no events to subscribe to).
• For a Laravel codebase, the equivalent capability is roughly 100–200 lines: a queued job posting to api.indexnow.org/indexnow, a route serving the key file, and hooks on publish/unpublish plus a noindex guard. That is a viable substitute and avoids adopting a CMS-specific dependency.
• Sulu 3 is young (verified only against 3.0.8). The bundle is now coupled to workflow event names and payload shapes that may shift in 3.1+.

Technical risk

• Breaking — namespace move: EventSubscriber\Sulu3\* → EventSubscriber\*. This changes class names and, in Symfony DI, likely service IDs. Any local decorator, compiler pass, container override, or YAML referencing the old FQCN breaks silently or at container compile. This is the highest-impact change and is under-emphasized in the notes.
• Breaking — hard ^3.0 constraint; cannot coexist with Sulu 2.6.
• Dev-dependency removals (sulu/article-bundle, jackalope/jackalope-doctrine-dbal) are low risk for consumers, but will break the bundle's own contributor setup and any fork.
• Maintainer/sustainability risk: single-vendor package, small surface, and the 1.x line is now explicitly "bug fixes" only. That is a dated EOL on the Sulu 2 path.
• Unverified behaviors in the notes: synchronous vs. queued submission, HTTP timeout/retry/error handling, per-host key management for multisite, and whether repeated workflow transitions can double-submit.
• Positive signal: 71 tests with no skips, PHPStan level: max, clean lint:container, and a four-case runtime matrix against a fresh Sulu skeleton. That is unusually disciplined evidence for a package this size.

Key questions

1. Is the submission synchronous inside the workflow transition? If so, what are the connect/read timeouts and does a slow IndexNow endpoint block the editorial publish action?
2. How are IndexNow key files and host values handled for multi-domain / multi-locale Sulu installations? Is the host derived from the resolved route or from config?
3. What happens on non-2xx responses (422 wrong key, 403 key-file unreachable, 429 rate limit)? Logged, retried, or swallowed?
4. Are service IDs documented, and is there a stated upgrade note for anyone decorating the old EventSubscriber\Sulu3 services?
5. Minimum PHP and Symfony versions? Not stated in the notes.
6. Is submission idempotent across repeated workflow transitions (e.g. draft → review → publish → publish)?
7. What is the maintainer's stated support window for the 1.x line?

Integration Approach

Stack fit

• Laravel application: does not fit. Do not attempt to shoehorn a Sulu bundle; scope a small in-house IndexNow job instead and treat this package as a reference implementation.
• Symfony + Sulu 3 application: strong fit, with low integration effort.
• Symfony without Sulu: no fit, no events to subscribe to.

Migration path

1. Inventory: grep the codebase and container config for EventSubscriber\Sulu3, subscriber service IDs, and any decorators or compiler passes touching them. This is the only genuinely breakable surface.
2. Confirm bundle configuration keys (IndexNow key, enabled environments, host) are unchanged between 1.x and 2.0.0 — the notes do not mention config changes, which suggests they are stable, but confirm against composer.json / extension class.
3. While the application remains on Sulu 2.6, pin kreativsoehne/sulu-indexnow-bundle:^1.0 explicitly and record the EOL exposure.
4. Treat the Sulu 3 application upgrade as the gating work item. The bundle bump is a one-line follow-up, not a project.
5. On the Sulu 3 branch: composer require kreativsoehne/sulu-indexnow-bundle:^2.0, run bin/console lint:container, and confirm both subscribers register on their events.
6. Validate against the published runtime matrix: publish → submitted; unpublish → submitted; noindex publish → not submitted; noindex unpublish → submitted.

Compatibility

• Verify the application's PHP and Symfony versions satisfy Sulu 3's floor before sequencing anything.
• For multisite, confirm key-file hosting per host and that route-resolved hosts match the submitted host, or IndexNow will reject the payload.

Sequencing

• Do not upgrade the bundle independently of Sulu 3; they are one change.
• If the Sulu 3 upgrade is not imminent, there is no action here — 1.x remains the correct pin.
• If the upgrade is imminent but not urgent, consider waiting for a 2.0.x patch or Sulu 3.1 to reduce churn on a brand-new event contract.

Operational Impact

Maintenance

• Small, auditable surface area. The main ongoing cost is not this package but the Sulu major-version treadmill it now tracks: every Sulu generation yields a new bundle major.
• Two live lines to reason about; expect 1.x to receive fixes only and eventually stop.

Support

• Community/GitHub support only, no vendor SLA. Acceptable for a best-effort, non-revenue-critical indexing signal; not acceptable as a dependency with contractual uptime expectations.
• Single-maintainer concentration is the real support risk. Mitigation is cheap: the package is small enough to fork or replace if abandoned.

Scaling

• Scales with publish volume, not traffic. Each transition is an outbound HTTP call to a third party.
• IndexNow enforces per-host quotas and rate limits; a bulk content migration or mass re-publish could hit them. Confirm whether submissions are batched or one-per-URL.
• Multisite multiplies key-file and host configuration overhead linearly.

Failure modes

• Slow or hanging IndexNow endpoint blocking the editorial publish workflow (if synchronous) — the most user-visible failure and the one to test first.
• Missing or misconfigured key file → 4xx rejections that go unnoticed because publishing still succeeds.
• Host mismatch between the route-resolved address and the key host in multi-domain setups.
• Duplicate submissions if a page passes through multiple qualifying transitions; mostly harmless, but it consumes quota.
• Silent regression on a Sulu 3.1 event rename — no submissions, no errors, no alerts. Add a log-based check or a periodic assertion that submissions are actually occurring.
• Unpublish reporting is a feature, not a failure mode, but confirm that withdrawn pages are intentionally de-indexed rather than temporarily hidden.

Ramp-up

• For a developer already fluent in Sulu 3: well under a day to integrate and validate, given the clear runtime matrix in the release notes.
• Debugging route resolution failures requires Sulu internals knowledge (route table, workflow transitions), so budget half a day of a Sulu-fluent engineer's time for validation rather than delegating to a generalist.
• For a Laravel team pursuing the equivalent capability in-house: roughly one to two days including key-file hosting, queuing, and retry/logging — and that path avoids adopting a CMS-coupled dependency entirely.