Short answer
Request indexing for your most important fixed pages in Search Console, keep your sitemap’s last modified dates accurate, and link the fixed pages from pages Google already crawls often. Do not use the Indexing API, which Google limits to job postings and livestreams. And remember that a faster crawl does not mean a faster recovery from a core update.
The days after fixing a site are when owners are most impatient. The work is done, nothing has moved, and every tool promising instant indexing looks tempting.
Some of those shortcuts help a little. One of them can get your access revoked. And none of them change when Google decides to reassess a demoted site.
Recrawling is not reassessment
This is the distinction that decides whether speed matters at all. Google seeing your changes and Google judging your site again are separate events.
| Cause you fixed | What a faster recrawl does |
|---|---|
| Technical fault | Recrawl is the recovery. Faster crawling means faster results |
| Spam violation | Helps. Spam systems reassess continuously once they see the change |
| Manual action | Little. The reconsideration request is what triggers review |
| Core demotion | Makes your changes visible in time for the next core update, nothing more |
For a core demotion, the only deadline that matters is the start of the next core update. Pages crawled the day after your fix and pages crawled three weeks later are judged at the same moment. Which kind of demotion you have is covered in core update vs spam update.
The methods that actually work
- Request indexing in URL Inspection for your most important fixed pages. The daily allowance is small, so spend it on the pages that matter most rather than on everything.
- Keep sitemap last modified dates accurate. Update the date only when the content genuinely changed. Google uses these dates when they prove reliable and learns to ignore them when they do not.
- Link fixed pages from frequently crawled pages, such as your homepage, main hubs and recent posts. Googlebot finds pages through links faster than through any request.
- Make the server fast and stable. Slow responses and errors make Google crawl more cautiously across the whole site.
- Cut crawl waste. Thousands of thin or duplicate URLs compete for the same attention. Measure it with the index bloat ratio.
Points three and five do more than point one on any site of real size. Requests help a handful of pages. Structure helps all of them.
Why not the Indexing API
Google documents the Indexing API for two kinds of page only: job postings, and livestreams marked up as a broadcast event inside a video object.
- Every submission goes through spam detection, according to Google’s documentation.
- Abuse can get access revoked, including using several accounts to get around the limits.
- The default allowance is 200 publish requests a day per Google Cloud project.
- Since 16 October 2026, the documentation no longer links a form for requesting more. The direction of travel is tighter, not looser.
Many instant indexing plugins send ordinary pages through it anyway. On a site recovering from a spam or quality problem, pushing pages through a spam-checked channel they do not qualify for is the opposite of what you want.
How to check it worked
- URL Inspection shows the last crawl date for each page. A date after your fix means Google has seen the change.
- The Crawl Stats report shows whether total crawling rose after you cut waste and fixed errors.
- Server logs show Googlebot visits directly, page by page, with no sampling.
Record the crawl date of each important page. If a core update starts before a page was crawled, that page was judged in its old state. Verification is covered in how to know if the recovery actually worked.
When a slow crawl is a warning sign
Important pages that stay uncrawled for weeks, despite good links and an accurate sitemap, are telling you something.
- Check host status in Crawl Stats. Server errors or slow responses make Google back off across the whole site.
- Check robots.txt and noindex rules on the fixed pages themselves. A leftover block from a redesign is common.
- Consider whether Google sees the page as worth revisiting. Pages Google rates as low value are crawled less often, which is one more reason quality work matters before anything else.
What is not worth doing
- Resubmitting the sitemap every day. Google reads it on its own schedule. Repeated submission adds nothing.
- Changing last modified dates without changing content. It teaches Google to distrust your dates, which slows discovery later.
- Ping and submission services that promise to notify search engines. Google retired its sitemap ping endpoint years ago.
- Requesting indexing for hundreds of URLs. The allowance runs out quickly and structure does the same job at scale.
The honest summary is unglamorous. Fix the site, make the fixed pages easy to reach, confirm Google has crawled them, then wait for the system that judges your problem. How long that wait is depends on the cause, covered in how long to wait before doing anything.
When a new date is justified at all, and how to show published and updated dates properly, is covered in does changing the date on a post help SEO.
Fixed the site and nothing has moved?
Sometimes the pages have not been crawled. More often the system that judges them has not run yet. Send your Search Console access and within 48 hours I will tell you which.
Get free recovery audit