AI Bots on OJS: How to Review Your Journal's Overload

Learn to review automated traffic on OJS, tell it apart from other failures and evaluate controls without blocking legitimate access to the journal.

A slow journal does not prove that an artificial intelligence bot is consuming its resources. The problem may also lie in the database, a server configuration, an editorial task or an external integration.

Even so, automated traffic deserves a look when the load rises. In July 2026, PKP described how requests associated with commercial AI services were putting pressure on its hosted platforms and which controls it used to keep the service running.[5]

For whoever administers OJS, the decision requires identifying what is happening before blocking anything. An overly broad control can limit requests that the journal does need to serve.

What PKP documented and what we should not infer from that report

PKP reported aggressive automated requests that demanded network and server resources. It described the use of firewalls, rate limiting and additional filtering tools. It also noted that AI services take part in content discovery and that they could not be blocked entirely without considering that role.[5]

This is the experience reported by that provider. It does not mean that every OJS journal suffers the same pattern or that AI traffic explains every slowdown. Nor does it allow us to conclude that an installation has a vulnerability or has been compromised.

Our recommendation is to treat automated traffic as a diagnostic hypothesis, alongside the other possible causes.

What to gather before deciding on a measure

The initial record should make it possible to relate the user's experience to the state of the platform. It is worth keeping:

Date, time and duration of the problem, with time zone.
Affected URLs or functions: reading, downloads, search or the editorial workflow.
Response codes and available response times.
Volume and distribution of requests during the same interval.
CPU, memory and database resource usage, if those measurements exist.
Recent changes to version, configuration, content or plugins.

Do not post complete logs on forums or send them to external services without reviewing their contents. They may contain IP addresses, private paths or other data that require careful handling.

If the journal does not have this background, the next step is to set up proper monitoring with its technical owner, not to attribute the problem to a category of bot.

How to interpret the signals without treating them as conclusive proof

An intense sequence of requests across many pages may justify a review. It is also worth watching for repeated access to costly functions, concentrated errors and deviations from that platform's usual behavior.

But a name in the User-Agent header does not by itself identify who is responsible. PKP warns that some crawlers change their characteristics and source addresses, which means controls have to be reviewed and adjusted.[5]

Hypothetical example: during a slow period, requests to internal search increase. To attribute an impact to them, the administrator should check their timing against the response times and the resources consumed. The coincidence alone does not show that they are the only problem.

If the relationship is not strong enough, the investigation should be widened: database queries, file processing, scheduled tasks or recent changes.

Choose a response proportionate to the problem

The following controls are options to evaluate with the administrator, not universal instructions for production.

Limit the rate at the right point

If the evidence shows an excessive pattern, a targeted request limit can be considered. The threshold should take into account the normal behavior of the service and the effect on users and integrations.

We do not recommend copying the limits of another journal: installations differ in the amount of content, architecture and usage.

Filter specific patterns

A measure on specific routes or patterns may be easier to control than blocking entire countries or all access without a signed-in session. Before applying it, identify the legitimate requests that could match the same rule.

It is not enough to create an exception based on the name a client declares. The evaluation must consider the available evidence and the appropriate checks for that service.

Review capacity and configuration

Blocking does not replace a review of the server. If the platform has a capacity or operating problem, preventing part of the traffic may hide it without solving it.

It is worth reviewing the architecture and the cost of the affected functions before adding resources. Our existing article on the OJS production stack provides context for that conversation; the diagnosis must be adjusted to the real installation.

Test that the control did not break the journal

For each change, we recommend recording an owner, the goal, the success criterion and the way back to the previous state.

Then check article reading, downloads and access to the relevant editorial functions. Also review the integrations and discovery mechanisms that the institution uses. An improvement in CPU usage is not enough if, at the same time, necessary access to the content is blocked.

A new rule must stay under observation. PKP's report describes precisely a job of monitoring and adjustment, not a single solution that eliminates the problem forever.[5]

When to escalate to specialized support

Ask for help when the incident recurs, the logs needed to investigate it are missing, the measures affect readers, or there are signs of a problem other than overload. The report for support should summarize symptoms and evidence, without sharing passwords or confidential files through unauthorized channels.

The journal defines its access and continuity needs; the technical owner evaluates and implements the authorized controls. That separation avoids forcing the editorial team to improvise server rules just to keep publishing.

OJS ONE offers administration and operation of OJS platforms.[11] If your journal is slow or has outages, request an assessment stating the times, the affected functions and the recent changes. The first goal is to determine the cause, not to assume in advance that it is AI bots.

Frequently asked questions

How do I know whether AI bots are overloading my OJS journal?

You cannot tell just because the journal is slow. Gather the date and duration of the problem, the affected URLs, response codes, request volume and CPU and database usage, and check whether the rise in requests coincides in time with the slowdown.

Should I block AI bots on OJS?

Not without evidence. An overly broad control can block legitimate access, and AI services take part in content discovery. Choose a proportionate response (rate limiting, filtering specific patterns, reviewing capacity) and test that it did not break the journal.

When should I escalate to specialized support?

When the incident recurs, the logs needed to investigate it are missing, the measures affect readers, or there are signs of a problem other than overload.