If you run an online business, you probably assume the biggest threat to your website is “hackers”. Fair enough — but some of the worst slowdowns don’t come from Hollywood-style break-ins. They come from perfectly legitimate bots hammering your site so hard that real customers start feeling the drag.

This morning, during our daily server checks, we found exactly that: Amazon’s crawler (“Amazonbot”) swarming one of our WordPress sites with thousands of hits per minute. Not on your home page like a normal visitor — but on a specific WordPress endpoint that can trigger extra work on the server.

Now, let’s be fair: bots aren’t automatically “bad”. Amazon (and other big platforms) crawl the web for a mix of reasons — discovery, previews, indexing, and data collection. In small doses, that’s just background internet noise. The problem is when it turns into a high-frequency scrape that chews CPU, burns server headroom, and makes your website feel sluggish right when a genuine buyer is trying to load a page.

In this post I’ll show you:

• What we saw in the logs (and why it matters to performance)
• What Amazonbot was targeting and why that endpoint is “expensive”
• Whether Amazonbot is good or bad (answer: it depends)
• What we did to stop the hammering — a small, targeted PHP rule that blocks Amazonbot only where it was causing trouble, without breaking normal visitors

If you’ve ever wondered why a site can be “fine” one minute and mysteriously slow the next, this is one of the big, under-discussed reasons.

What we found: Amazonbot hammering a WordPress endpoint

During our normal daily checks, one pattern jumped off the page: a crawler identifying itself as Amazonbot was generating thousands of requests per minute.

Here’s the important part: it wasn’t “reading your website” like a human. The traffic was heavily concentrated on a single WordPress endpoint:

/wp-json/oembed/1.0/embed

This endpoint is part of WordPress’ oEmbed system — the thing that helps generate rich previews when someone pastes a link into an editor, a chat app, or a platform that creates link cards.

In small amounts, that’s harmless background noise. But when a bot repeatedly hits an endpoint like this at high speed, the impact is wildly out of proportion to the page it’s requesting, because:

• It still triggers PHP execution (and sometimes theme/plugin logic).
• It can involve extra lookups to build the response.
• It hits again…and again…and again — turning “minor work” into a steady load.

To put the scale in plain terms: even 1,000 requests per minute is about 17 requests per second. A few thousand per minute can easily become a level of background load that steals server headroom and makes the site feel slower for real customers.

One quick honesty note: user-agents can be spoofed, so we don’t treat “Amazonbot” as a trusted identity. We treated it as a behaviour problem (high-frequency requests to a costly endpoint) and fixed it that way.

Why Amazon (and other platforms) crawl your site

First up: this usually isn’t personal, and it’s not “because you did something wrong”. Amazon (like Google, Microsoft, Meta and others) runs large-scale crawlers that visit public websites for a mix of reasons — content discovery, previews, indexing-style processing, and various automated systems.

Does it matter whether you sell on Amazon?

Usually, no. Your site can be crawled whether you sell on Amazon or not. If you do sell on Amazon, you might see extra Amazon-related traffic for other reasons (widgets, integrations, links being shared, etc.), but Amazonbot-style crawling can still happen even if you’ve never sold a thing on Amazon.

Are they collecting prices to compete with you?

Price scraping is common across eCommerce in general. Bots often hit product pages to read prices, stock status, and shipping cues. That said, seeing “Amazonbot” in a log doesn’t prove Amazon is doing competitor price monitoring of your store — user-agents can be spoofed and many bots wear borrowed names.

That’s why we treat this as a behaviour problem first: if a bot is hitting your site at an extreme rate and creating load, we stop the harmful behaviour regardless of who it claims to be.

How we make this simple for our managed VPS customers

This is exactly the sort of thing we handle for customers hosted on our managed VPS. You don’t need to become a “bot expert”. We:

• Spot the surge (for example: thousands of hits per minute).
• Identify the target (which URLs/endpoints are being hammered).
• Confirm impact (server headroom and CPU being chewed up).
• Apply a safe, targeted fix so normal visitors are unaffected.

If you want visibility yourself (non-technical version)

• Ask us “what’s hammering the site?” — we’ll check and translate it into plain English.
• When we report it, focus on two numbers: how many hits per minute, and which URL(s) they’re hitting most.
• If you see a sudden slowdown, tell us what time it happened — we can line it up with traffic spikes and confirm the cause quickly.

What Amazonbot was hitting (and why it can slow a site down)

In our case, the swarm wasn’t “Amazonbot reading your home page”. The bulk of the traffic was concentrated on a single WordPress REST endpoint:

/wp-json/oembed/1.0/embed

That address is part of WordPress’ oEmbed system. The simple way to think about it is this:

• oEmbed exists to create previews of a page when a platform wants to display a “rich link” (title, image, snippet, etc.).
• So instead of loading a normal page like a browser does, a bot can call this endpoint to get structured preview data quickly.

Now here’s the catch.

Even though it looks like “just a URL”, it still forces WordPress to wake up and do work. That typically means:

• PHP runs.
• WordPress loads core components (and sometimes plugin/theme logic).
• A response is generated and sent back.

One request like that is nothing. But when it’s thousands of hits per minute, it becomes a steady background load that steals server headroom.

Why that matters: website performance isn’t only about “how fast is my server”. It’s about how much spare capacity the server has when a real customer arrives. Heavy bot traffic eats that spare capacity — and that’s when customers experience slow loads, laggy checkout, and intermittent “it feels clunky today” behaviour.

In short: the problem wasn’t that the endpoint exists. The problem was the crawl rate and the concentration of requests on an endpoint that triggers WordPress processing every time.

What we did: a targeted block that doesn’t hurt real customers

When a business owner says “Just block the IP”, I completely understand the instinct — it’s simple and it sounds decisive.

The problem is: modern bots rarely use a single IP. They rotate addresses, use large cloud networks, and pop up from multiple locations. If you only block one IP, you often end up playing whack-a-mole while the load continues.

So instead of blocking “one IP”, we blocked the specific bad behaviour.

The fix in plain English

We wrote a small piece of PHP logic and added it to the site so that:

• If the request is for /wp-json/oembed/1.0/embed and the visitor identifies as Amazonbot, the site returns 403 Forbidden.
• Normal browsers and normal visitors still receive a normal 200 OK response.
• The rest of the website remains completely untouched.

This is important: we did not “block Amazon” from the whole site. We blocked Amazonbot only where it was causing trouble, on the one endpoint being hammered.

Why this approach is safer

• It’s precise: we’re not blocking customers or legitimate traffic broadly.
• It’s effective: it stops the load at the source, even if the bot rotates IPs.
• It preserves performance headroom: real customers don’t have to compete with high-frequency bot calls.

Because our customers are hosted on our managed VPS platform, we can implement fixes like this quickly, verify them from the server side, and keep monitoring for any repeat behaviour.

Result: the “hammering” stops, server headroom returns, and the website stays fast for the people who actually matter — your customers.

How we verified the fix (and what you can take away from it)

Whenever we block or restrict anything, we don’t “hope it worked” — we verify it.

After deploying the targeted rule, we tested two simple outcomes:

• Amazonbot requesting the oEmbed endpoint now receives a 403 Forbidden response.
• A normal browser/user requesting the same endpoint (or any normal page) still receives a 200 OK response.

That confirms two things:

• The abusive behaviour is stopped.
• Real visitors are unaffected.

The business takeaway (the bit that matters)

When your site “mysteriously slows down”, it’s often not your content, your hosting plan, or your customers. It can be background automation eating your resources.

So the smart approach is:

• Don’t panic.
• Don’t randomly block whole countries or huge IP ranges (easy to cause collateral damage).
• Do identify the specific pattern (which URL is being hit, and how often).
• Do apply a targeted fix that protects performance while keeping the site fully usable.

This is one of the hidden benefits of being on a properly managed VPS: you’re not just buying “hosting”. You’re buying active protection and performance management — including the boring-but-critical work of keeping bots from stealing your server headroom.

What this means for our managed VPS customers

If your site is hosted with us on our high-performance VPS hosting - you don’t need to do anything.

This is the whole point of our service: we run proactive checks, we spot bot surges early, and we fix the cause before it turns into a business problem.

• We monitor for abnormal request patterns and “hammering” behaviour.
• We investigate which URLs/endpoints are being targeted and whether it’s consuming server headroom.
• We implement targeted protections (like the Amazonbot oEmbed block) that stop the load without harming real visitors.
• We keep watching so if the pattern changes, the protection changes with it.

In other words: you’re not buying “hosting space”. You’re buying a managed environment where performance and protection are actively maintained — so you can focus on running your business.

Sydney Business Web: based in Thornton NSW — serving the Hunter and greater Sydney

Sydney Business Web is proudly based in Thornton NSW 2322. We build and protect business websites on our managed VPS, and we handle the “bot hammering” problems pre-emptively so our customers don’t have to become techies just to keep their site fast.

Regional service pages:

• Thornton
• Maitland
• Newcastle & Hunter Valley
• Sydney CBD
• Sutherland Shire
• Eastern Suburbs
• Inner West
• Northern Beaches
• Port Stephens
• Wollongong–Illawarra
• Lower Hunter
• Central Coast
• Blue Mountains