Sulu Indexnow Bundle Laravel Package

Getting Started

Version line first. v2.0.0 is Sulu 3 only. Decide before you touch composer:

# Sulu 3
composer require kreativsoehne/sulu-indexnow-bundle:^2.0

# Sulu 2.6 — stay put, 1.x is still maintained
composer require kreativsoehne/sulu-indexnow-bundle:^1.0

The sulu/sulu: ^3.0 constraint makes the wrong choice fail loudly at install time rather than at runtime, which is the right trade.

Register and configure. Enable the bundle in config/bundles.php, then add the IndexNow credentials (key + host) through the bundle's extension config. IndexNow requires the key to be publicly fetchable as a plain-text file at the host root (https://<host>/<key>.txt); confirm whether the bundle serves that file or whether your web root must provide it — do this before you publish anything, or your first submissions will 403.

Where to look first. The subscribers now live in EventSubscriber\ (no more EventSubscriber\Sulu3). Open the page subscriber and read which workflow transition it matches — that one file tells you more about behaviour than the README. Then check debug:event-dispatcher output for PageWorkflowTransitionAppliedEvent to confirm your listener is wired on your kernel.

First use case. Publish a page through the Sulu admin, then verify the submission landed (application log + Bing Webmaster Tools' IndexNow report). Then unpublish it and confirm a second submission — that behaviour is deliberate and non-obvious.

Implementation Patterns

The default flow needs zero application code. Pages and articles are covered out of the box: publish submits, unpublish submits, noindex publish does not, noindex unpublish does. Treat the bundle as infrastructure and don't wrap it unless you need one of the patterns below.

Extending coverage to other content. Only pages and articles are subscribed. For custom entities or anything else with a route, write your own subscriber on the relevant workflow-transition event, resolve the address from the route repository (the same way the bundle does), and reuse the bundle's client service rather than rolling your own HTTP call — that keeps rate limiting and key handling in one place.

Backfilling an existing site. Installing the bundle does nothing for already-published content. Write a one-off command that walks the route table and submits in batches, applying the same filters as the subscribers (skip noindex, skip routes that don't resolve). Run it once after the first deploy, then delete it or gate it behind a flag.

Multi-webspace / multi-domain setups. The address comes from the route repository, so submissions follow whatever host the route resolves to. Each distinct host needs the key file reachable at its root. Verify per webspace — a single-host test will not catch this.

Testing. Sulu 3 has no PagePublishedEvent. Integration tests must drive a workflow transition (as the bundle's own 71 tests do) and assert on the dispatch, not on a document event. If you're porting tests from a Sulu 2 project, they will not translate — rewrite the arrange step, keep the assertions.

CI. Pin sulu/sulu: ^3.0 and keep static analysis at a level you can hold. The package itself ships PHPStan level: max clean, so a decorator or extension you add is the most likely source of new violations.

Gotchas and Tips

The namespace move is the real upgrade hazard. Subscribers went from EventSubscriber\Sulu3\* to EventSubscriber\*. If you decorated, aliased, or !tagged_iterator'd those classes, or wrote a compiler pass referencing the old FQCNs, the references break silently — services simply stop resolving and nothing submits. Run bin/console lint:container and debug:event-dispatcher immediately after upgrading, before you trust a green deploy.

Leftover Sulu 2 config. The version switch and its dual code paths are gone, so the extension config now has one shape. Diff your project config against the bundle's; keys that existed only to drive the version switch are dead weight and may now be ignored without warning.

Unpublish always submits — including for noindex pages. A page that was never indexed still gets reported on withdrawal (it answers 404, so the address is worth reporting). This is intentional, not a bug. If your logs look noisy after a bulk unpublish, that's why.

Workflow transitions are broader than "publish". PageWorkflowTransitionAppliedEvent fires for every transition. The bundle filters by transition name. If you customise the Sulu workflow — extra places, a review/approval step, renamed transitions — re-verify the filter still matches your publish and withdraw transitions, otherwise you'll submit on editorial moves or miss real publishes. This is the single most likely production surprise in a non-standard Sulu install.

Custom withdraw logic breaks the assumption. Reporting a withdrawn page relies on Sulu 3 keeping the route and letting the page answer 404. If your project removes routes on withdrawal (or redirects them), the submission points at a URL that no longer 404s and the dead page stays in the index. Check this if you've customised route cleanup.

noindex is read at transition time, not at request time. Flipping a live page to noindex does not resubmit anything; the index only learns on the next transition. If de-indexing on noindex matters, that's a gap to fill yourself.

Rate limits and batching. IndexNow endpoints throttle bulk submissions. The per-publish flow is naturally low-volume; backfills are not. Batch and back off in any command you write.

Debugging checklist, in order: lint:container → debug:event-dispatcher | grep -i workflow → application log for the outbound request → the search engine's own IndexNow report. Most "it doesn't work" reports resolve at step two.