Request Indexing after every page edit: useful or just burning quota?

Lots of SEOs hit Request Indexing every time they touch a page, and I'm not convinced it does much beyond prompting a recrawl of that one URL. Google describes the tool as being for new or significantly changed pages, and the daily quota is small. On a site with a few hundred pages that get updated often, internal links and sitemap lastmod dates that reflect real changes probably do more for how fast updates get picked up. URL Inspection is still worth using when a title change doesn't show up, because it shows you which version Google actually crawled. As a routine after every minor edit, though, I'd skip it. Has anyone seen the button move crawl rate or rankings in a way that wasn't just timing?

Agreed on the routine part, but I'm not sure the sitemap point holds. lastmod only helps if Google trusts it, and it stops being trusted once it changes on every template touch. A simple rule: use Request Indexing for new pages or a real rewrite, and only update lastmod when the content has actually changed.

Agreed on lastmod. Google has said it ignores the field once it looks unreliable, so a template change that bumps every page is worse than leaving the dates stale. One case I'd add is a page where the internal links or structured data changed but the body didn't, since that can matter for crawling even when the text stays the same. Does your site have many of those, or is it mostly copy edits?

I don't think the internal link and structured data case holds up. A changed link or schema block on a page that's already indexed usually gets picked up on the next normal crawl, so burning Request Indexing quota on it doesn't speed things up much. The exception is when the change is only reachable from a page Google crawls rarely. In that case the fix is getting the linking page recrawled, not submitting the target URL. And the Rich Results Test only tells you whether the markup is valid, not whether Google has actually seen it yet.

Same here on the Rich Results Test. It can pass while the markup Google actually fetched is missing, especially when the JSON-LD gets injected by Tag Manager or client-side JavaScript. The better check is the crawled HTML in URL Inspection. Open "View crawled page", go to the HTML tab, and search for the schema block. If it's there, crawling is fine and you just wait for the next pass. If the test passes but the crawled HTML has no script tag, the problem is rendering, and no amount of recrawling will fix that.

Before blaming rendering, look at the "More info" section under the crawled page in the URL Inspection tool. It lists the resources Google tried to load. If the Tag Manager container or the script file that writes the JSON-LD shows as blocked there, the markup never gets injected, no matter how clean the template is. Robots.txt rules that block an assets or scripts folder cause this more often than people expect, because nobody thinks of the tag container as a page resource.

Another common cause is a consent manager that only fires the injection after a visitor accepts cookies. Googlebot doesn't click the banner, so the script that adds the schema never runs for it. If the markup depends on that click, it belongs in the server HTML instead.

The consent manager case is the one to watch hardest. A lot of banners only load the tag container after acceptance, so the JSON-LD never exists for a crawler that doesn't click anything. Quick test: load the page in a fresh browser with cookies cleared and no interaction, then check the DOM. If the schema isn't there, it's a server HTML problem, not a crawl problem, and moving the block into the template fixes it for good.

The same gate usually hits ad tracking too. If the banner holds back the whole tag container until acceptance, your conversion tags only fire for visitors who click accept, so the numbers you feed into bidding skew toward that group. Moving the schema into server HTML fixes the crawl side, but measurement is a separate problem that needs Consent Mode or a properly configured default-denied state.

Does your banner block the whole container, or only the non-essential tags?

Agreed, and a lot of people miss that Consent Mode in its default-denied state still sends cookieless pings to Google. That means the conversion modeling has something to work with even when nobody touches the banner. Blocking the whole container is the setup that really starves bidding of data.