Website Disappeared From Google? How to Find Out Why and Get It Back

You search for your own business name and your site is gone. Not lower down the page, gone. Maybe a client noticed first, or your analytics show organic visits falling off a cliff on a specific day. Searching site:example.com returns nothing, or a handful of odd pages.

When a whole site vanishes from Google at once, the cause is almost never a ranking change. Ranking changes move positions up and down. A full disappearance usually means Google was told not to index the site, could not reach it, found it hacked, or applied a manual action. Most of those are mechanical faults on your side that you can find and fix today. This guide is for site owners, designers who just launched a rebuild, and anyone who inherited a site and woke up to an empty search result.

What is happening

Getting into Google happens in three stages, and a failure at any one of them can remove a page:

1. Crawling. Googlebot requests your URL. Before it does, it reads /robots.txt. If robots.txt disallows the URL, Googlebot does not fetch it. If DNS fails, the server times out or returns errors, the fetch fails.
2. Indexing. Google reads the page it fetched. If it finds a noindex rule (in a <meta name="robots"> tag or an X-Robots-Tag HTTP header), it drops the page. If a rel="canonical" points to another URL, Google may index that other URL instead.
3. Serving. Indexed pages can still be held back by a manual action from Google’s reviewers or by security problems such as hacked content.

Each cause leaves a different fingerprint, which lets you narrow it down quickly:

Cause	What you usually see	Typical trigger
Accidental noindex	Pages drop out over days to weeks as Google recrawls them; Page indexing report shows “Excluded by ‘noindex’ tag”	Launch from staging, SEO plugin setting, a security or maintenance plugin
robots.txt Disallow	Results show the URL with no description, then fade; “Blocked by robots.txt” in Search Console	Staging robots.txt copied to live, a CDN or host rule
Manual action	A notice under Security & Manual Actions, often with an email	Spam, hacked content, unnatural links, thin or scraped pages
Security issue	Warnings in results or the browser, spam pages under your domain	A compromise (see the hacked site guides)
Outage or DNS failure	“Server error (5xx)” or DNS errors in Crawl stats; drop starts on the outage date	Hosting problems, expired domain, broken nameservers
Canonical to elsewhere	Pages show “Alternate page with proper canonical tag” or another URL appears in results	A theme, plugin or migration writing the wrong canonical

Before you start

• Access you need: Google Search Console for the domain (a Domain property is best because it covers http, https, www and non-www together), the WordPress dashboard, and ideally SSH or SFTP. If you have never verified Search Console, do it now with a DNS TXT record at your DNS provider. Performance data is normally available for past dates as soon as verification succeeds, so you can still see the drop.
• Backup: nothing in the diagnosis changes your site. Before you edit robots.txt, .htaccess or plugin settings, download a copy of the file or take a screenshot of the setting.
• How to run commands: curl and dig run on your own computer. macOS and Linux include both. On Windows 10 and 11, type curl.exe in PowerShell (plain curl is an alias for a different command), use Resolve-DnsName instead of dig, or install WSL to get the Linux versions. Commands starting with wp run in an SSH terminal on the server, inside the site folder that contains wp-config.php; some hosts name the tool wp-cli instead.

Step 1: Confirm what is actually missing

Use site: as a smoke test, not a count

Search Google for site:example.com. If you see results, the site is at least partly indexed. If you see none, something serious is wrong. Do not read too much into the number of results: Google states that the site: operator does not necessarily return every indexed URL, and it is not meant for counting pages. It is a quick yes or no, nothing more.

Also search for your exact brand name and a distinctive sentence from your homepage in quotes. If your homepage shows up for the quoted sentence but not for the brand name, you have a ranking or competition problem, not an indexing problem, and the rest of this guide may not apply.

Read the Performance report

In Search Console, open Performance, then Search results. Set the date range to cover several weeks before and after the drop. A vertical cliff on one day points to a mechanical cause (noindex, robots.txt, outage, manual action). A gradual slide over weeks points to quality, competition or a slow recrawl after a change. Click the Pages tab to see whether every page fell or only some. If only your redesign’s new pages are missing, see the redesign guide (FG-79) instead.

Read the Page indexing report

Open Indexing, then Pages. The chart shows indexed versus not indexed pages over time. Under Why pages aren’t indexed, the reason with a sudden jump is usually your culprit. Click it to see example URLs. Every reason is explained in the Page indexing statuses guide (FG-78).

Step 2: Check for an accidental noindex

This is the most common self-inflicted cause, especially right after a launch. The site was built on staging with indexing switched off, and the switch came along to production.

The WordPress setting

In the dashboard go to Settings, Reading and look at Search engine visibility. If Discourage search engines from indexing this site is checked, current WordPress adds <meta name='robots' content='noindex, nofollow' /> to every page. Uncheck it and save. Check it from the server too:

wp option get blog_public

Run this over SSH in the site folder. There are no placeholders. Output 1 means the site is public. Output 0 means search engines are being discouraged. Fix it with wp option update blog_public 1 if you cannot reach the dashboard.

SEO plugin settings

Yoast SEO, Rank Math, All in One SEO and SEOPress all have site-wide and per-post robots controls. Look for settings that hide a whole content type from search (for example a “Show Pages in search results” toggle set to off) and per-post “noindex” or “No Index” boxes on your key pages. Some plugins also noindex the site when a “coming soon” or maintenance mode is active.

X-Robots-Tag headers

A noindex can also arrive as an HTTP header, which you will never see in the page source. Hosts add it to staging domains, and an old .htaccess or Nginx rule can survive a migration. Check the real response:

curl -sI https://example.com/
curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/IMPORTANT_PAGE/

Run these on your computer. Replace example.com with your domain and IMPORTANT_PAGE with the path of a page that used to rank. -s hides the progress bar, -I requests headers only, and -A sends Googlebot’s user agent string, which catches plugins and firewalls that treat bots differently. Good output starts with HTTP/2 200 and has no x-robots-tag line, or one that says index. Bad output contains x-robots-tag: noindex (or none), or returns 403, 503 or a redirect to a login page for the Googlebot request only.

Then check the meta tag in the delivered HTML:

curl -s https://example.com/ | grep -io '<meta[^>]*robots[^>]*>'

Run this on your computer. -i makes grep case-insensitive and -o prints only the matching tag. Good output is nothing, or a tag containing index, follow or max-image-preview:large. Bad output contains noindex.

Confirm with the URL Inspection live test

In Search Console, paste a key URL into the inspection bar at the top, then click Test live URL. Under page indexability, Indexing allowed? should say Yes. If it says No, the detail names whether the block came from the meta tag or the X-Robots-Tag header. The live test fetches the page as Google sees it now, so it is the best proof that your fix worked.

Step 3: Check robots.txt

Open https://example.com/robots.txt in a browser. This is the dangerous version:

User-agent: *
Disallow: /

This is a file on your site, not a command. It tells every crawler not to fetch any URL. Compare it with Disallow: followed by nothing, which allows everything. One slash is the difference between a working site and an invisible one. Remove the Disallow: / line, then in Search Console open Settings, then the robots.txt report, and request a recrawl of the file. The full parsing rules, the WordPress virtual file and staging protection are covered in the robots.txt and noindex guide (FG-80).

Also check that robots.txt itself loads. If it returns a 5xx error or times out, Google treats the site as temporarily off limits and pauses crawling, which looks a lot like a block.

Step 4: Check for a manual action or security issue

Manual actions

In Search Console open Security & Manual Actions, then Manual actions. “No issues detected” means no human reviewer has penalized the site. If there is an action, it names the type (for example pure spam, user-generated spam, unnatural links to your site, thin content, cloaking or hacked content) and whether it affects the whole site or some pages.

To recover, fix the problem everywhere it exists, not just on the example URLs, then click Request review. Explain what was wrong, what you changed, and how you will stop it happening again, with evidence. Google sends the outcome by email and in Search Console. Reviews are not instant, and a request sent before the problem is fully fixed tends to be rejected, so take the time to clean up properly.

Security issues

Under the same menu, open Security issues. Hacked content, malware or deceptive pages show up here, and they often explain a sudden drop together with odd pages in a site: search. If you find anything, follow the first hour hacked guide (FG-05), the Japanese keyword spam guide (FG-22) and the deceptive site warning guide (FG-24), then request a review from this report.

Step 5: Rule out outages, DNS and an expired domain

If Googlebot cannot reach the site for long enough, pages start dropping out. Short blips rarely matter. Long or repeated outages do.

Crawl stats

Open Settings, then Crawl stats and click Open report. Look at Host status: problems with robots.txt fetching, DNS resolution or server connectivity are flagged here with dates. In the breakdown by response, a rise in server errors (5xx) or a drop to near zero requests lines up with an outage.

Check DNS and the domain

dig +short example.com A
dig +short example.com NS
whois example.com | grep -i -E 'expir|status'

Run these on your computer. Replace example.com with your domain. +short prints only the answer. Good output is your server’s IP address for the A record, your expected nameservers for NS, and an expiry date in the future with statuses such as clientTransferProhibited. Bad output is an empty answer, a parking or registrar IP you do not recognize, or a status such as clientHold, serverHold or redemptionPeriod, which means the domain is suspended or expired. Some registries trim whois output, so if it is unclear, log in to your registrar. Expired domains, NXDOMAIN and DNSSEC failures are covered in FG-16, and server errors in FG-12, FG-13 and FG-14.

Step 6: Check for a canonical pointing elsewhere

A rel="canonical" tag tells Google which URL is the main version of a page. If every page canonicalizes to the homepage, to a staging domain, or to an old domain, Google may drop your real URLs in favor of the target.

curl -s https://example.com/IMPORTANT_PAGE/ | grep -io '<link[^>]*canonical[^>]*>'
curl -sI https://example.com/IMPORTANT_PAGE/ | grep -i '^link:'

Run these on your computer. Replace IMPORTANT_PAGE with a page path. The first finds a canonical tag in the HTML, the second finds a canonical sent as a Link header. Good output is a canonical whose URL is exactly the page you requested (same protocol, host and trailing slash). Bad output is a canonical pointing to staging., a different domain, http://, or the homepage on every page. In URL Inspection, compare User-declared canonical with Google-selected canonical. Fixing duplicates and canonical choices in depth is the subject of FG-81.

Step 7: Recover and set expectations

1. Fix the cause and confirm it with curl and the URL Inspection live test.
2. Click Request indexing on your homepage and your most important pages. There is a daily quota, so prioritize.
3. Make sure your XML sitemap loads (WordPress core serves /wp-sitemap.xml; SEO plugins often use /sitemap_index.xml) and resubmit it under Indexing, Sitemaps.
4. In the Page indexing report, open the reason you fixed and click Validate fix so Google rechecks those URLs and reports progress.
5. Watch Performance daily. Search Console data lags by a day or two.

Be realistic about timing. Recovery depends on how quickly Google recrawls your pages, which varies with the site’s size and how often it was crawled before. Important pages on an established site can return within days of a fix; deeper pages can take weeks. Returning to the index does not guarantee returning to the same positions, especially after a long absence or a manual action. Nobody can promise a date, and anyone who does is guessing.

Advanced: build a timeline from your own logs

When the cause is not obvious, line up dates. Search Console tells you when traffic and indexing changed; your server logs tell you what Googlebot actually received. Over SSH, find requests from Googlebot and count response codes by day:

grep -h 'Googlebot' /PATH/TO/access.log* | awk '{print substr($4,2,11), $9}' | sort | uniq -c | tail -50

Run this on the server. Replace /PATH/TO/access.log with your access log location (often under /var/log/nginx/, /var/log/apache2/ or a logs folder in your hosting account; on managed hosting you may need to download it from the control panel). The awk part prints the date and the status code, assuming the common combined log format where field 4 is the timestamp and field 9 is the status; adjust if your format differs. Good output shows mostly 200 and some 301 or 304 every day. Bad output shows a run of 403 (a firewall or bot blocker), 5xx (server trouble), or days with no Googlebot lines at all.

Anyone can fake the Googlebot user agent, so confirm suspicious lines with a reverse DNS lookup:

host GOOGLEBOT_IP
host CRAWLER_HOSTNAME

Run these on your computer or the server. Replace GOOGLEBOT_IP with the IP from a log line. The first lookup should return a hostname ending in googlebot.com, google.com or googleusercontent.com; put that hostname in place of CRAWLER_HOSTNAME and the second lookup should return the same IP. If either step fails, the request was not from Google and its status codes do not explain your drop.

Then compare the dates: a noindex shows up as 200 responses with traffic still falling, a firewall rule shows up as 403s starting on the day a security plugin or CDN setting changed, and an outage shows up as 5xx or missing days. Write the timeline down. It is the fastest way to prove the cause to a client or your host.

When to contact your host

Open a ticket when the evidence points to the server or network: 5xx errors in Crawl stats, Googlebot getting 403 responses you did not configure, an X-Robots-Tag header you cannot find in your own files, DNS answers you did not set, or a robots.txt you did not write. Include:

• The date and time the drop began, in UTC, from the Performance report and Crawl stats.
• Two or three affected URLs and the full output of curl -sI for each, including any CDN ray or request ID headers.
• Screenshots of the Search Console reason (Server error, Blocked by robots.txt, Excluded by ‘noindex’ tag) with example URLs.
• Relevant access log lines showing Googlebot requests and their status codes.
• What changed shortly before: a migration, a new plugin, a firewall or CDN change, a DNS edit, a renewal.

Our diagnostic tools can check status codes, headers and DNS from outside your network before you write the ticket. If the site is not just missing from Google but down for visitors too, start at the Emergency Room.