A core update reshapes relevance signals across the web; an index update changes which pages Google has crawled and stored. Confuse them and you will waste weeks optimising the wrong thing. This guide gives you the diagnostic framework to tell them apart in minutes.
The browser history says ‘traffic dropped on the 15th’. The Google Search Console graph shows a steep decline. You open Twitter and someone yells ‘core update!’ - but that someone is often wrong. A core update attacks your relevance signals: content quality, E-E-A-T, topical authority. An index update attacks your presence: pages that were in the index suddenly are not, or pages that were ranking now return a soft 404. The fix for one is editorial; the fix for the other is technical. Mix them up and you rewrite articles for pages that Google simply stopped crawling because your sitemap expired or your JavaScript rendered an empty shell.
In practice, when you see a ranking drop, the first thing we do is open the URL Inspection Tool. If the page says ‘URL is not on Google’ or ‘Discovered - currently not indexed’, you are dealing with an index update problem. If the page is indexed but dropped from position 4 to position 40, you are dealing with a core update problem. The distinction is that simple - and yet most audits skip this step entirely.
| Diagnostic dimension | Index update signal | Core update signal | Verdict / next step |
|---|---|---|---|
| GSC URL status Check 3-5 pages that lost traffic | URL is 'not indexed', 'discovered - not indexed', or 'crawled - not indexed'. Coverage report shows errors like 404, soft 404, or blocked by robots.txt | URL is 'indexed' and status is valid. Average position dropped without a change in index status | Index issue: fix crawl errors and submit via sitemap protocol. Core issue: audit content and E-E-A-T signals |
| Timeline shape Look at 7-day vs 28-day chart | Drop is sudden, often within 24-48 hours, and affects specific URL patterns or sections of the site. Recovery can happen within days if cause is removed | Drop is gradual over 3-7 days, affects many pages across different sections, and recovery often takes 4+ weeks | Sharp, narrow drop = index. Broad, slow move = core |
| Crawl budget signals Check crawl stats in GSC | Crawl requests drop sharply, crawl errors spike, or Googlebot stops hitting certain URL patterns entirely. Server logs show no requests for affected pages | Crawl rate stays stable or even increases. Googlebot continues to hit the pages but re-crawls less frequently | Low crawl volume + errors = index issue. Normal crawl + ranking drop = core issue |
| Query-level impact Compare exact match vs informational terms | Drops are uniform across all queries that used the affected page. If the page is gone, it does not rank for any query | Drops are query-dependent. The page ranks well for some queries but not others. Topical relevance changed in Google's model | Uniform drop = index. Query-variant drop = core |
| Recovery action What actually moves the needle | Fix technical barriers: remove noindex, update sitemap, re-index the sitemap quickly, resolve JS rendering gaps. Results in 2-5 days | Publish deeper content, improve E-E-A-T signals, add original research, improve internal linking. Results in 2-12 weeks (next core update cycle) | If troubleshooting index issues, see the hands-on workflow for JavaScript SEO rendering fixes to avoid missed content |
A B2B SaaS client lost 63% of organic traffic overnight on 12 March 2024. Our team ran the diagnostic protocol.
Step 1: URL Inspection Tool - We checked the top 10 landing pages. 6 of 10 showed ‘Discovered - currently not indexed’. The remaining 4 were indexed but had dropped in average position by 2-3 spots, likely a secondary effect of missing pages.
Step 2: Coverage report in GSC - 2,300 pages were marked ‘Crawled - currently not indexed’. The error started 11 March, not 15 March when the client noticed the drop. Googlebot had stopped indexing new blog posts due to a server-side redirect loop that returned a 302 for all URLs with trailing slashes.
Step 3: Server log analysis - Googlebot hit 1,800 URLs on 10 March, only 412 on 11 March. The redirect loop caused a soft 404. We fixed the .htaccess rule, removed the empty redirect, and resubmitted the sitemap via the quick re-index workflow. Within 72 hours, 1,800 pages were re-indexed and traffic recovered to 91% of pre-drop levels. No core update was involved.
If any show 'not indexed', proceed to index audit. If all are 'indexed' with a drop in position, proceed to core audit.
Filter by 'Crawled - not indexed' and 'Discovered - not indexed'. Compare error counts before and after the drop date.
Check server logs for Googlebot requests. A drop of more than 50% in daily requests points to an index problem.
If the page dropped for some queries but not others, it is a core update. If it dropped for all queries, it is an index issue.
Index issue: fix crawl errors, update sitemap, re-index. Core issue: publish better content, improve E-E-A-T, wait for next update cycle.
A common situation we see is the React or Next.js site that looks perfect in a browser but returns an empty
Edge case: a site that uses client-side rendering with a loading spinner. Googlebot waits for a timeout (usually 5-10 seconds), then captures whatever is on screen. If your content loads after 8 seconds, some Googlebot instances get the spinner, some get the content. This creates an index update that flickers pages in and out daily. You see ranking volatility and think it is a core update. It is not. It is a race condition between your JavaScript and Google's render queue.
Check 5-10 affected pages in URL Inspection Tool: are they indexed?
Open GSC Coverage report: filter by error type and date range
Compare crawl stats before and after the drop: did Googlebot stop coming?
Check if the drop is uniform across queries or varies by intent
Review sitemap submission status: is Google still reading it?
Test pages with mobile-friendly test and URL inspection: any soft 404s?
Check JavaScript rendering with 'Fetch as Google': does the rendered HTML contain the body content?
Look at the Google Search Status Dashboard: was a core update announced on the drop date?
Check if the category page is still indexed. If yes but dropped from position 5 to 35 for product queries, it is likely a core update affecting relevance signals. If the page shows 'Crawled - not indexed' or the number of indexed product URLs dropped by 40% or more, it is an index update. Ecommerce sites often confuse the two because core updates hit thin category pages while index updates hit paginated or filter-parameter URLs.
Agencies should build a dashboard comparing three metrics per client: indexed URL count (GSC), average position for top 20 queries, and crawl rate. A drop in indexed URLs with stable crawl rate suggests a core update (Google still crawls but devalues pages). A drop in crawl rate with stable indexed URLs suggests an index update (blocked crawling). A simultaneous drop in both is the edge case, often caused by a robots.txt error or a sudden site migration that triggered both issues.
Yes. If a page gets de-indexed due to a technical error (e.g., noindex tag accidentally applied during a migration), all its backlinks become worthless. The resulting traffic drop looks like a core update because the drop is sudden and affects many queries. The clue: check if the page itself is still in the index. If it is gone, backlinks are irrelevant. Restore the page to the index first, then assess if the core update also affected remaining pages.
Yes. Use the API to pull the 'indexStatusReport' dimension for affected pages. If the 'Crawled - not indexed' count increased by more than 20% on the drop date, it is an index update. If the indexed count is stable but the 'averageTopPosition' metric dropped by 5+ positions for the same queries, it is a core update. Automate this script to run daily and email you the diagnosis, so you do not waste time manually checking 100 URLs.
Guest post networks frequently see index updates when Google changes its policy on low-value third-party content: pages get crawled but not indexed. If the network's pages were previously indexed and suddenly show 'Crawled - not indexed', it is an index update triggered by a quality policy change. If the pages are indexed but dropped in ranking, it is a core update that devalued the authority signals of the linking domains. Both can happen simultaneously, so check the index status first.
Index update recovery: 2-7 days if the root cause is a technical block (robots.txt, noindex, sitemap error). 2-4 weeks if the issue is a large-scale JavaScript rendering problem that requires code changes. Core update recovery: 4-12 weeks, and only if you improve the content quality, E-E-A-T signals, and topical depth. Large sites often need 2-3 core update cycles to fully recover because the breadth of published content takes time to improve.
Core updates are rarely rolled back; Google may tweak the algorithm in a follow-up update 2-4 weeks later, but the original distribution of traffic rarely returns exactly. Index updates can be reversed within hours if you fix the technical error: remove a noindex tag and re-submit the URL, and the page can be re-indexed and rank again in 24-48 hours. If you see a traffic drop that recovers quickly after a technical fix, it was an index update. If you wait weeks and see no change, it was likely a core update.
Yes. A core update does not change how Google reads your sitemap; it changes how Google evaluates the content of the pages listed in it. An index update often reveals problems with sitemap data: outdated URLs, incorrect lastmod dates, or pages listed that return 4xx/5xx errors. If your sitemap submission via the <a href='https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview'>sitemap protocol</a> shows 'Could not fetch' errors, that is an index update trigger. Fix the sitemap first, then reassess ranking.
Yes, and crawl budget analysis is the most reliable signal for large sites. An index update typically reduces Googlebot's daily crawl requests by 50-90% because the crawler hits a wall (rate limit, blocked URLs, infinite redirect loops). A core update does not reduce crawl requests; it may even increase them as Googlebot re-crawls pages to reassess quality. If your crawl rate drops sharply, it is an index problem. If it stays stable or increases while traffic drops, it is a core problem.
1) Export all indexed URLs from GSC (or use a bulk API checker). 2) Re-run the bulk check 2 hours later and compare: any URLs that went from 'indexed' to 'not indexed' are the index update victims. 3) For URLs that remain indexed but lost positions, run a content gap analysis against top competitors. This dual workflow catches both issues in one pass. A common failure: using a bulk checker that does not refresh cached results, so you see stale data and miss the index drop entirely.
Quick calculator. Put in the expected monthly value of a page or link batch and the natural waiting time.