Only Your Homepage Is Indexed? How I Diagnose a Site Google Stopped Indexing
Only your homepage indexed after a hack cleanup? Rule out leftover spam and technical blocks, then treat it as a site quality problem.
You cleaned up the hack, but Google seems to have kept only your front door. When only your homepage is indexed months later, rule out a leftover hack and a technical block first because both are cheap to prove or disprove. If those checks are clean, treat this as a site-wide quality reassessment: recovery can take months, and Request indexing does not fix the underlying problem.
If your whole site vanished overnight, start with the whole-site overnight drop guide. Here, I'm dealing with a narrower problem: internal pages remain outside the index long after cleanup.
My method separates three hypotheses. This table is my diagnostic order, not an official Google decision tree.
| Signal | Points to | First check |
|---|---|---|
| Security issues lists hacked content, or spam URLs return 200 | Leftover hack | Remove every instance, then Request Review |
| Spam URLs appear in sitemaps or Page indexing lists | Hack residue | Remove sitemap entries. Return 404 or 410 |
| Live test finds noindex, robots.txt blocking or canonicals to the homepage | Technical block | Fix the directive. Retest key URLs |
| Rendered HTML lacks internal links | Rendering or discovery problem | Check crawlable <a href> links |
| Internal pages are “Crawled - currently not indexed” at scale. Tests are clean | Quality reassessment | Review, improve or consolidate across the site |
| Drop starts with a core update rather than the hack | Quality and overlapping timing | Compare dates. Plan for months |
What Mueller said when only your homepage is indexed
On November 3, 2026, Barry Schwartz reported a Bluesky exchange. Sarah Blocksidge described a client hacked the previous year, cleaned up, and still left with only the homepage indexed. She also reported trouble getting internal links crawled.
John Mueller said he could not assess it without more information. His tentative reading was:
“this sounds like a general quality issue that might be unrelated to the hack (unless the hack was in place for a long time - ca many months). Times timing makes it hard to notice, eg when the hack & a core update happen together.” Search Engine Roundtable
That makes quality my leading hypothesis, not a diagnosis. Schwartz also notes that an incomplete cleanup or a technical issue could explain the situation. Neither possibility was ruled out in that exchange.
Expert Insight
A hack cleanup removes the problem you can see. It does not automatically restore Google's confidence in everything else. My working interpretation is that a surviving homepage can indicate willingness to show the brand without the same confidence in internal pages. I'd verify the exclusions before treating that interpretation as the cause.
Rule out the hack before judging the content
Start with Search Console's Security issues report. Google identifies it as the reference for verifying reported security issues and their resolution. Check Manual actions separately: that report covers attempts to manipulate search, while Security issues covers hacked or harmful behavior. Google's Security issues documentation
I then check the evidence beyond the sample URLs:
- Search for injected patterns using queries such as
site:example.com pharmacyorsite:example.com/wp-admin/. - Review Page indexing exclusions, XML and CMS-generated sitemaps, and server or CDN requests for old spam patterns.
- Confirm injected URLs return 404 or 410, rather than 200 or a blanket redirect to the homepage.
Compare key pages fetched normally with versions using a Google referrer and Googlebot user-agent. For an actual page, replace the example address in both commands:
curl -L 'https://example.com/'
curl -L -e 'https://www.google.com/' -A 'Googlebot' 'https://example.com/'
Look for injected links or text. Google documents cloaking that changes what appears depending on referrer or user-agent. URL Inspection adds another view. These comparisons are evidence checks, not proof that the whole site is clean.
Flag unknown administrators, plugins or rewrite rules for whoever owns the cleanup. Keep the SEO investigation focused on what gets served and indexed.
Google warns that examples are incomplete and every instance needs fixing. Once all reported security issues are resolved, use Request Review. Reviews can take a few days to a few weeks. Don't resubmit before a decision. The penalty recovery playbook provides the related recovery framework.
Technical causes that can look like a quality problem
For Google only indexing the homepage, I'd live-test five to ten important internal URLs. Check crawl permission, indexing permission, rendered content, and user-declared versus Google-selected canonicals. The Page indexing documentation explains why the exclusion reason and selected canonical matter.
Inspect cleanup changes closely: robots.txt blocking folders, a template-wide noindex, canonicals pointing every page to the homepage, blanket redirects, or a sitemap containing only the homepage. Check responses for 5xx errors and soft 404s too.
Open the rendered HTML. Can Google see the main content and links to internal pages? Google's link best practices specify crawlable <a> elements with href attributes. JavaScript can insert those links, but onclick-only navigation is not the recommended markup.
Every important page should have a link from another page on the site. A working menu in your browser doesn't establish that its links appear in Google's rendered HTML.
Use the indexation and crawlability playbook to structure those checks. The real estate rendering and crawlability case study is the related rendering reference.
Put the hack and core updates on one timeline
Build one timeline with the hack's start, detection, cleanup, security review result, and robots, canonical or template changes. Add announced core and spam update dates, then align indexed-page counts and impressions underneath.
If exclusions started at cleanup, I would investigate what the restoration changed. If the drop began with a core update instead of the hack, that supports the quality hypothesis. Overlap makes attribution harder. Matching dates alone does not establish cause.
Our core update analysis and August 2026 spam update article are related reading. Use the dates relevant to your site's history, rather than assuming the latest update explains everything.
Google says core updates do not target particular sites. For comparisons around an update, its core update guidance says to wait at least a full week after completion, then compare with a week before it began.
What moves recovery when quality is the working diagnosis
After clean hack and technical checks, I review the site as a whole. Widespread “Crawled - currently not indexed” can support that direction. Neither that label nor “Discovered - currently not indexed” proves a quality problem by itself.
For the discovered status, Google describes a URL found but not yet crawled, typically rescheduled because crawling was expected to overload the site. Check crawl conditions before treating those pages as evidence about content value. Page indexing explanations
I'd examine thin or near-duplicate templates, doorway-like location and tag pages, material restored from old backups, and copied content left from the compromise. Decide which important pages need improvement or consolidation. The thin content article provides related context without turning every exclusion into a manual-action diagnosis.
Google recommends reviewing the whole site after sustained large drops, avoiding quick fixes, and treating deletion as a last resort. Google's core update guidance
My recovery plan pairs that work with a sitemap of important URLs and internal links from the homepage and relevant hubs. Repeated Request indexing submissions do not improve page value or correct a site-wide quality signal. For “Crawled - currently not indexed,” Google explicitly says there is no need to resubmit for crawling. Page indexing report
How long recovery takes, and what I measure
Google says some changes can take effect within days, but confirming sustained site-wide improvement can take “several months.” If months pass without an effect, the next core update may matter. Smaller unannounced core updates can also show improvements. None guarantees recovery. Google's recovery guidance
I would track this weekly:
- Page indexing counts by reason, filtered by a sitemap of key URLs: indexed, crawled but not indexed, and discovered but not indexed.
- URL Inspection status for ten sample key pages, including the selected canonical and indexing result.
- Performance impressions for non-homepage pages, alongside Crawl Stats requests and response codes.
- Whether Security issues and Manual actions remain clean.
Google documents filtering Page indexing by a sitemap of important pages to focus validation. Its example lists are limited to 1,000 URLs, so don't mistake the displayed sample for every affected page. Page indexing report
Keep crawl activity separate from search visibility. More requests alone do not show that internal pages returned to the index. See Googlebot crawling versus clicks for that measurement distinction.
My short recovery checklist
This is my working checklist:
- Verify security findings and remove every injected instance.
- Retest key URLs, canonicals, directives, responses and rendered links.
- Align cleanup and site changes with update dates.
- Improve or consolidate important pages. Avoid reflexive deletion.
- Track indexing reasons, sample URLs and non-homepage impressions weekly.
Frequently asked questions
Why is only my homepage indexed?
A leftover hack, technical block or site-wide quality reassessment could explain it. I check the first two before adopting quality as the working diagnosis. Mueller's comment was tentative and based on limited information.
Can a hack cause pages to drop out after cleanup?
An incomplete cleanup can leave injected URLs, cloaked content or other residue. Mueller also mentioned hacks lasting many months. The timing can overlap with a core update, so the hack alone does not establish the cause.
Should I keep using Request indexing?
Repeated requests do not fix technical blocks or quality issues. For pages marked “Crawled - currently not indexed,” Google says resubmitting for crawling is unnecessary. Work on the underlying evidence first.
What does “Crawled - currently not indexed” mean here?
Google crawled the page but did not index it. It may or may not index it later. At scale, after clean security and technical checks, I treat it as a reason to assess site-wide value, not proof of a penalty.
How long does recovery after a quality issue take?
Google says confirming sustained improvement across a site can take several months. You may need to wait until another core update. There is no fixed recovery date or promised outcome.
Do I need a reconsideration request?
A suspected quality reassessment is not a reported manual action. Check Manual actions separately. For reported security issues, fix everything and use Request Review through Security issues. That review is separate from quality reassessment.
A clean site is a starting point. It does not promise renewed indexing.
Growing Search can help you assess the evidence through an SEO audit or work through priorities with technical SEO advisory. Start with the pages that matter to your business and a diagnosis you can verify.
About the Author
