How to tell bots from people when your WordPress traffic spikes

When your WordPress site suddenly gets busier or quieter, the first question is who is visiting: people, search engines, AI crawlers, or something trying to break in. This guide shows you how to answer it with the web statistics and logs in Plesk, how to check that a "Googlebot" really is Google, and what to do about each kind of visitor before your site spends its days at its plan's limits. It is written for a Noiz client on sLegacy or sPremium and needs no plugin.

Last reviewed: 19 October 2026, against Plesk Obsidian and the crawler documentation of Google, Bing, OpenAI, Anthropic and Perplexity. This guide is written for Noiz hosting and is kept current against those sources. It complements, and does not replace, the official documentation linked below.

Official Documentation Reference

• Viewing Web Statistics (Plesk): where the GoAccess report lives.
• Log Files (Plesk): reading access and error logs, live.
• Verify Google's crawlers (Google Search Central): telling the real Googlebot from a fake.
• Verify Bingbot (Bing Webmaster Tools): the same for Bing.

What Happens When Your Site Reaches Its Limits

Every Noiz shared plan prints its cores and memory, and those figures are the limits:

• Memory is a hard limit. When your sites ask for more, the process that asked is stopped, and a visitor may see an error page.
• Processor time is held at your figure. At the limit, pages queue and load slowly; nothing is taken from other customers.
• Traffic is not billed, and neither is processor or memory use.

A spike that sends you to the limit for an hour is normal, and we do not act on it. What we watch for is a site that sits at its limits day after day. When that happens, we look at why, tell you what we can see, and, if the site has grown, set out the plan it should move to. Our Acceptable Use Policy sets this out in section 4. Plesk does not alert you when your site reaches its limits. The signs you see are slow pages and error pages, and the steps below find their cause.

Before You Start

• You can log in to Plesk for the subscription that holds the site.
• Note roughly when the spike or drop started. The logs are easier to read with a time in mind.

Step 1: Look at the Web Statistics

1. In Plesk, open your site under Websites & Domains and open Web Statistics SSL/TLS. Your plan's statistics are produced by GoAccess.
2. Compare the days before and during the spike. Look at three panels: - Visitor Hostnames and IPs: a handful of addresses with thousands of requests each is a crawler or an attack, not people. - Not Found (404): a burst of requests for pages you never had, such as /.env or old plugin paths, is a scanner looking for weaknesses. - HTTP Status Codes: a rise in 5xx codes means visitors were getting error pages, the sign of a site at its memory limit.

Step 2: Read the Access Log Live

1. Go to Websites & Domains > Logs for the site.
2. Choose the access log and select Start real-time updates.
3. Watch for a minute. Each line shows the visitor's address, the page asked for and the visitor's name for itself (the user agent).

What the lines tell you:

Step 3: Check That a Crawler Is Real

Anyone can call themselves Googlebot. Google and Bing tell you how to check:

1. Take the address from the log, for example 66.249.66.1.
2. Look up its name. On Linux or macOS, run host 66.249.66.1 in a terminal; on Windows, nslookup 66.249.66.1.
3. For Google, the name must end in googlebot.com, google.com or googleusercontent.com. For Bing, it must end in search.msn.com.
4. Look up that name the other way (host followed by the name) and check it returns the same address.

If both checks pass, it is the real crawler. If not, it is a bot pretending to be one, and you treat it as an attack.

OpenAI, Anthropic and Perplexity publish the names and address lists of their crawlers on their own pages, so you can check AI crawlers the same way.

Step 4: Act on What You Found

People

A spike of real visitors is good news. If it lasts and pages slow down, your site has outgrown its plan's figures. Moving from sLegacy to sPremium, or up a tier, is a plan change on the same panel, and the shared hosting page prints each tier's cores and memory.

A real search engine crawling too fast

• Bing follows a Crawl-delay line in your robots.txt, and Bing Webmaster Tools lets you set its crawl rate by hour.
• Google ignores Crawl-delay and adjusts its own pace when your site slows down. A short spike from Googlebot usually passes on its own.

AI crawlers

Each AI company publishes the user agents it uses, and you can allow or refuse each one in robots.txt. Anthropic also follows Crawl-delay. The agents that fetch a page because a person asked for it, such as ChatGPT-User and Perplexity-User, may not follow robots.txt, because they act for that person. Refusing a search crawler costs you that engine's answers: OpenAI, for example, says sites that refuse OAI-SearchBot are not shown in ChatGPT search answers. Blocking a training crawler such as GPTBot or ClaudeBot does not. Decide which you want before you block.

Attacks and fake crawlers

1. Open a ticket with the addresses and the times from your log, and tell us what you see.
2. Make sure no account uses a weak password, and that two-factor authentication is on for administrators.
3. If nothing you use needs xmlrpc.php (the WordPress mobile app and some older tools do), block it with a security plugin, or on Premium with WP Toolkit's security measures in Plesk.

Your own site's jobs

If the busy times match a backup plugin, an import or a plugin's scheduled job rather than visitors, move that work to a quiet time of day.

A Drop in Traffic

A sudden drop is worth the same look:

• 5xx codes in the statistics: visitors were turned away by errors. Read the error log under Logs for the time the drop began.
• A drop in one crawler's visits: check you have not refused it in robots.txt by mistake.
• No errors and no change in crawlers: the cause is outside the server, such as a change in search rankings or the end of a campaign.

Get Warned Before Visitors Tell You

An uptime monitor checks your site every few minutes from outside and alerts you when it is slow or down. Uptime Kuma is a free, open-source monitor you run yourself, on a computer or server that stays on, and it can alert you by email or a chat app. It tells you something is wrong; Steps 1 to 3 tell you why.

Troubleshooting

• Web Statistics shows nothing for today: the statistics are built on a schedule, not live. Use the Logs page for today.
• The log scrolls too fast to read: stop real-time updates, download the log from Manage Log Files, and search it on your computer for one address or one page, such as wp-login.php.
• host returns "not found": the address has no name, which a real Google or Bing crawler always has. Treat it as a fake.
• Error pages continue after the spike ends: the cause may be on the site itself, such as a plugin that has started using far more memory. Open a ticket; it is one of the causes we look for.

Let Noiz Look After WordPress

WordPress Care updates WordPress core, themes and plugins every week with a restore point first, applies security patches, keeps comment spam out, and fixes and restores the site if it is hacked.