job
How Do You Find Which Keywords and Pages Dropped?
Compare two recent windows in your search data, list every query and URL that lost impressions or position, then look at those specific pages for the things that actually decay: outdated facts, broken links, thin sections, titles that no longer match the query. That list of losses with a cause beside each one is the deliverable — not a hunch about what Google wants. A note on where this product stands: you can open these pages and sign in to the workspace today, but that does not mean we have connected your Search Console or crawl accounts for you, and it does not mean Indexfold has formally launched.
What this search is usually asking
Traffic fell and nobody can say which pages are responsible. The useful version of the question is narrower: which queries lost impressions, which URLs served them, and what changed on those pages or around them. Site-wide drops usually have a technical or indexing cause; slow erosion across many pages usually means content that aged out.
The two kinds need different fixes, so the first job is telling them apart with data you already have — not with a new theory.
What you need before starting
Access to Search Console or an equivalent source of query-level impressions, or an export from a rank tracker covering the period before and after the drop. Bring the URL list you care about and the approximate date traffic changed. If something shipped near that date — a redesign, a migration, a template change — write it down; it will matter later.
Step 1: Compare two comparable windows
Pick a 28-day window before the drop and the same length after. Comparing unlike windows — a holiday month against a normal one — manufactures losses that are really seasonality. Write down both date ranges so anyone can reproduce the comparison.
Step 2: List the losing queries and their landing URLs
Export queries whose impressions or average position fell materially, and record which URL ranked for each. One URL losing twenty queries is a page problem. Twenty URLs each losing a little is a site-wide problem, and the rest of this checklist should wait until the site-wide cause is understood.
Step 3: Inspect the losing pages for visible decay
Open each URL and check the things that age: statistics and dates that are now stale, internal links to pages that moved or died, images that no longer load, sections thinner than what currently ranks for the query. Note one concrete defect per page rather than a vague verdict like “needs updating.”
Step 4: Sort the losses into a refresh queue
Split the list three ways: pages worth a targeted fix, pages worth a real rewrite, and pages better retired or redirected. Order by how much traffic the page used to get and how small the fix is. A queue sorted this way can actually be worked; an unsorted list of forty URLs cannot.
Step 5: Ship the fixes and schedule the recheck
Fix the top items, then recheck the same queries in the same window length after shipping. Without the recheck you will never know whether the refresh did anything. This is the step most audits skip, and it is the reason the same pages keep appearing in every audit.
How you know the list is right
Every row names a query, a URL, the loss in numbers, and one observed defect. Someone else can open the page and find the defect you recorded. The queue has an order, and each fixed item has a recheck date attached. If any row says “trust me,” it is not done.
Limits worth stating plainly
Indexfold does not sell article writing or guaranteed rankings. Search-console and crawl access still need a connection you authorize. Rankings move for reasons outside any one page refresh. Competitors ship, algorithms change, demand shifts — a recheck measures your page against a moving field, not against a fixed scoreboard.
A refresh list is a diagnosis, not a forecast. Nothing here promises that fixing a page restores its old position.
Where Indexfold fits
Indexfold is a workspace for exactly this loop: point it at the site, get a list of dropped terms, broken links, and stale pages, draft the refresh against the live URL, and recheck after you ship. The opening action is Audit a site. It does not write piles of new articles and it does not promise rankings.
You bring the site and what you already track; the workspace keeps the findings and the recheck side by side so the second audit is faster than the first.
FAQ
Questions this guide is for
I only have Analytics, not Search Console. Can I still do this?
Partially. Analytics shows which pages lost traffic but not which queries stopped matching. You can build a page-level queue without query data, but expect to guess at intent more often.
How big does a drop need to be before this is worth doing?
If the loss is within normal week-to-week wobble, wait another window. If a page that fed leads or orders visibly fell, one worked example is enough to start — you do not need the whole site queued first.
Should I rewrite every stale page at once?
No. Batch rewrites make the recheck unreadable — you cannot tell which change helped. Fix a few, recheck, then continue.
Start in the workspace
Audit the site and build the refresh list
Sign in or create an account and you return to the Indexfold conversation canvas on indexfold.kuca.app. Bring the site URL and what you already track; the audit lists drops, broken links, and stale pages before anything gets rewritten.