You publish a post and then you wait. Your sitemap says here is everything I have, come back whenever, and the crawler comes back whenever. The page might there invisible for days.
IndexNow flips that around. It is a small protocol: you publish a key file on your domain, then POST the URLs that changed. Bing, Yandex, Seznam, Naver and Yep consume it, and one submission to the shared endpoint reaches all of them. Google does not participate, so this complements your sitemap, it does not replace it. If that alone rules it out for you, stop reading here.
Laraindexnow wires the protocol into Eloquent. You describe which records deserve a URL and under what conditions, and the package works out when to submit. This post walks through the whole thing.
The last command generates a key, writes INDEXNOWKEY to your .env the way key:generate writes APPKEY, and drops the key file into public/. That file is the whole authentication story: if you can publish at https://yourdomain.com/{key}.txt, the domain is yours. There is no account to open.
The package also serves that URL through a route, so the file is optional. Generate it anyway: the web server hands a real file over without booting the framework, so it keeps answering while php artisan down returns a 503 for every route.
An unreachable key file is behind almost every rejection from the endpoint, and the endpoint itself tells you nothing useful about which half failed.
That is the whole integration. No trait, no interface, nothing added to the model.
url() takes a route name and resolves it with the record bound to it, which covers most models. Anything that already looks like a URL is left alone, and a closure handles the rest:
There is also affects(), for the other URLs a write leaves out of date. Publishing a post changes the post page, but it also changes the index and the category listing:
An attribute named on its own has to hold something true, and whenNot() is the opposite. Truth is read the way PHP reads it, so 1, "1" and true all pass while 0, "0", null and "" do not. A tinyint(1) column with no boolean cast comes back from MySQL as 1, and the same attribute is true when you just assigned it in PHP. Both have to read the same way, or your conditions work on a fresh record and not on a reloaded one.
A counter reads nicely as a flag, so when('commentcount') is "has at least one".
The package asks one question on every write. Did this record belong in the index before it, and does it belong after?
| Before | After | Submitted | | --- | --- | --- | | no | no | no | | no | yes | yes, it entered the index | | yes | yes | only if a content attribute changed | | yes | no | yes, it left the index |
That last row is the one people forget. A record leaving the index matters as much as one entering it: the URL now 404s or turns noindex, and the engines should be told to go and look. The same goes for a deleted record, and for a changed slug, where both the old URL and the new one go out.
The third row is where you keep the noise down. Not every write is a content change, and some applications rewrite half a table on a schedule:
A scheduled command that recomputes cached counters across a large table is the case that bites: without that list every row it touches counts as a content change, and one run becomes thousands of submissions. With it, the run is silent and a real edit still goes out.
Sometimes the interesting thing is not what the record holds but what just happened to it:
whenChanged() is the precise way to say what counts as content, and it is the inverse of ignoring(): a whitelist instead of a blacklist. If forgetting one column would flood the endpoint, prefer the whitelist.