3,222 Requests an Hour. Six Login Posts. That Is Not the Same Event.

This morning, about 7:10 AM PDT on 14 September 2026, the knowledge cluster showed a fresh spike: roughly 3,222 requests in an hour, and six POST hits on wp-login.php. Same box. Same shape as the 11–13 September run. Slightly hotter on volume. Cooler on the login door.

That is the whole alert. It is not a breach report. It is not a reason to open the firewall. It is two numbers that most dashboards smash into one word — “attack” — and then the operator starts changing things they cannot undo cleanly.

What does a 3,222 request-per-hour spike actually mean?

It means the box was busy. It does not mean someone is in the admin. On this stack, an hour in the low thousands is loud enough to page a human and too coarse to name a cause. AI crawlers, feed fetchers, uptime checks, and junk scanners all land in the same request counter. We already showed that GA4 misses crawler traffic and that server logs are the only honest desk for that layer in Server Log Analysis for AI Search.

The 11 September field note left this card open. That write-up recorded an earlier pulse on the same cluster at about 1:51 PT: roughly 2,487 requests per hour and nine wp-login POSTs. The instruction then was a read-only log pull and a one-paragraph verdict. No firewall change, no plugin change, no credential change without a named gate. That card is the parent of this morning. See The 1 MB Limit Ate the Clips.

Why are six wp-login POSTs the number that matters?

Because that path is the door. A GET to wp-login.php is usually a probe. A POST is a credential attempt. Six POSTs in an hour is not a brute-force campaign. A campaign that is actually trying passwords does not stop at six. It stacks POSTs until a rate limit, a WAF, or a 429 answers.

Six against 3,222 is the tell. Login is about two-tenths of one percent of the hour. If the spike were “someone hammering wp-login,” the login count would be the spike. Here the spike is everything else, and the door got a light knock.

Those two rows are first-party. They come from the ops cards and this morning’s alert. They are not a full log dump. They are enough to stop the sentence “we are under attack” from shipping as fact.

How do you tell bot noise from a hostile login event?

You do not tell from a single request-per-hour number. You tell from five columns that have to sit on one page: top source networks, paths, methods, status codes, and whether any POST to an auth endpoint returned a success path instead of a fail, a 403, a 429, or a challenge.

• If volume is high and wp-login.php / xmlrpc.php POSTs are near zero, start with crawler or scanner noise.
• If POSTs to the login door climb while other paths stay flat, start with credential stuffing or a cheap brute-force kit.
• If one network owns both the volume and the POSTs, treat that network as the subject of the verdict, not the whole internet.
• If status codes are 200 on a login POST, do not celebrate. WordPress often returns 200 on a failed login because it re-renders the form. You still need the auth result, not the HTTP code alone.
• If you cannot see whether rate limiting or the WAF fired, you do not have a close. You have a draft.

That list is the desk, not a product. It is the same discipline we use when we refuse to treat Bing AI citations as sessions in How to Read Bing Webmaster Tools AI Citations. Wrong unit, wrong decision.

What is the one-paragraph verdict from this morning’s numbers alone?

Provisional, read-only: this morning looks like bot noise with opportunistic login probes, not a concentrated hostile event. The volume rose from the mid-2,000s last week to the low-3,000s. The login door went from nine POSTs to six. That is the opposite of a campaign that is finding a seam. Nothing in the alert says a login reached a successful auth. Nothing in the alert says the WAF or a rate limit fired. Until those two facts are in the log extract, the box stays as-is.

What to do from this paragraph: pull the hour. Rank source networks, paths, methods, and status codes. Confirm whether any login POST crossed into an authenticated session. Write the close in one paragraph. Do not touch firewall, plugins, credentials, DNS, or WAF from the spike number alone.

Why does this belong on an AEO and GEO desk?

Because the same operators who publish for answer engines also run the origin those engines crawl. A spike that is actually GPTBot or a citation crawler is the retrieval layer working. A spike that is actually wp-login.php is the origin under cheap pressure. If you flatten both into “bots,” you will rate-limit the crawler you spent a year trying to attract. We mapped that split in The AI Crawler Hierarchy and in Google vs Bing vs OpenAI.

SEO still needs the URL up. AEO still needs a clean block a snippet can lift. GEO still needs a page a model will cite without inventing a second sentence. None of those layers survive an origin that treats every request burst as an incident and starts flipping controls. The cited-answer work on this site — Your Website Doesn’t Need More Traffic. It Needs to Be the Answer. — assumes the box that serves the sentence stays boring.

What we would not claim

• That we have this morning’s full access log in this article. We have the alert counts. The path table and the auth result are the next pull, not this page.
• That six POSTs means zero risk. It means the door was tried. It does not mean the door opened.
• That 3,222 requests per hour is a universal threshold. It is the number on this box, this hour.
• That hiding wp-login.php is the fix. Obscurity is not the close, and this post is not a plugin recommendation.
• That any named source network belongs in a public URL. Publishing attacker addresses helps the next scanner more than it helps the reader.

What we would do again

Keep the two counts separate on the card. Request volume on the left. Auth-path POSTs on the right. Write the verdict in one paragraph before anyone is allowed to change a control. Leave the change list empty until the named gate says yes. Publish the method, not the address list.

The 11 September card said a spike is not automatically an attack and it is not automatically “leave it.” It is a log plus a verdict. This morning’s numbers did not close the log. They did close the panic sentence. The door was quiet. The weather was not.

FAQ

Is a WordPress request spike the same thing as a brute-force attack?

No. A request spike is total traffic in a window. A brute-force event is repeated credential POSTs against an auth path such as wp-login.php or xmlrpc.php. This morning’s hour had both a spike and six login POSTs. Those are adjacent facts, not proof they are the same campaign.

How many wp-login POSTs should trigger a change?

There is no public magic number that authorizes a firewall, plugin, credential, DNS, or WAF change on this stack. The trigger is a log extract that shows concentrated POSTs, a repeated source network, and either a successful auth or a clear miss by the existing limiters. Six POSTs in an hour does not clear that bar.

Can AI crawlers cause a 3,000-request hour?

Yes. On this network we have already logged hours where a single AI crawler family mapped tags, feeds, and endpoints at four-figure rates. That traffic belongs in the server log, not in GA4. Confirm the user-agent and the path list before you treat the hour as hostile.

Should you publish the source IP addresses from a spike?

No. A public post can carry the counts, the method, and the verdict. It should not carry a live target list. The addresses live in the private log pull.

Sources: Tygart Media ops alert, knowledge cluster, ~7:10 AM PDT, 14 September 2026 (about 3,222 requests/hour and 6 wp-login POSTs). Prior public card in The 1 MB Limit Ate the Clips (~2,487 requests/hour and 9 wp-login POSTs, ~1:51 PT). Method context: server log analysis for AI search, AI crawler hierarchy. Will Tygart, Tygart Media, 14 September 2026.