If your journal runs on WordPress, you are not alone. We talk to editors every month who started exactly that way. WordPress was free, it was familiar, and someone on the team already knew how to use it. Publishing an article felt as easy as writing a blog post.
But “easy to publish” and “built for scholarly publishing” are two very different things. Sooner or later, many of these editors hit the same wall: articles that never show up properly in Google Scholar, a growing pile of plugins just to keep things running and, in the worst cases, a hacked website full of gambling spam.
Several of the publishers we have worked with have since moved their journals to Open Journal Systems (OJS) and now host them with us at Openjournaltheme.com. This article shares what they learned the hard way, so you don’t have to.
Table of Contents
WordPress Was Built for Blogs, Not for Journals
WordPress is a great tool for company websites, news portals and blogs. A scholarly journal, however, is not just a collection of pages. It is a workflow and a permanent record: submission, peer review, revision, copyediting, production, publication in volumes and issues, persistent identifiers, and metadata that indexers can read.
None of that exists in WordPress by default. So journals bolt it on with custom post types, page builders, extra plugins and a lot of manual work. The result may look like a journal on the front end, but underneath it is still a blog trying to act like one. In practice, that usually means:
- No built-in submission or peer review. Manuscripts travel by email, and reviewer identities end up scattered across inboxes.
- No real volume and issue structure. Issues are faked with categories or static pages that break when the theme changes.
- No standard citation metadata for each article. Academic search engines struggle to understand who wrote what, and when.
- No OAI-PMH endpoint and no native DOI deposit. Indexers and harvesters can’t collect your metadata automatically.
The Security Problem Hiding in Your Plugin List
Let’s be fair first, WordPress core itself is well maintained. In 2025, only six vulnerabilities were reported in core, and all of them were low priority. The danger is everything you install around it. Here is what Patchstack’s 2026 security report found for the WordPress ecosystem in 2025:
- 11,334 new vulnerabilities were discovered, a 42% increase compared with 2024.
- 91% of them were in plugins and 9% in themes.
- More high-severity vulnerabilities were found in 2025 than in the previous two years combined, and highly exploitable vulnerabilities rose by 113% year over year.
- 46% of vulnerabilities did not get a fix from the developer in time for public disclosure. Updating your plugins doesn’t help when there is no update yet.
- For the most heavily attacked flaws, the weighted median time to mass exploitation was just 5 hours. Roughly half of high-impact vulnerabilities were exploited within 24 hours.
- In Patchstack’s tests of popular hosting companies, typical defenses blocked only 26% of vulnerability exploit attempts, and just 12% of WordPress-specific attacks on known exploited flaws.
Read that again: 5 hours. Most editors check their journal website once a week, sometimes once a month. Attackers start exploiting the most popular new flaws within hours. That gap is where journal sites get hacked.
Why journal websites are especially exposed
A journal on WordPress usually needs far more plugins than an ordinary website: a PDF viewer, a citation exporter, submission forms, a membership plugin for reviewers, statistics, SEO, a page builder, caching, backups. Each one is written by a different developer, updated on a different schedule, and some are quietly abandoned.
Paid plugins are not automatically safer. Patchstack found that 76% of the vulnerabilities discovered in premium components were exploitable in real attacks, and premium components had three times more known exploited vulnerabilities than free ones.
Add the fact that most journal sites are managed by an editor or a lecturer, not a full-time security engineer, and you get a website that is very easy to fall behind on.
What a Hack Actually Costs a Journal
When an online shop gets hacked, it loses sales for a few days. When a journal gets hacked, the damage lasts much longer, because your reputation is the product.
- SEO spam you can’t see. According to Patchstack and Monarx, the most common malware families in 2025 used cloaking: search engine bots are shown keyword-stuffed spam, human visitors are redirected to scam sites, and site owners and scanners often see a perfectly clean page. Many editors only find out when someone sends them a screenshot of their journal ranking for casino or online gambling keywords.
- Tampered academic records. Published articles are supposed to be permanent. Injected links, altered pages or swapped PDFs undermine the trust readers place in your journal.
- Exposed confidential data. Unpublished manuscripts, author emails and reviewer identities are exactly what blind peer review is meant to protect.
- Malware that keeps coming back. Modern malware can run in server memory and rewrite cleaned files the moment they are restored, which makes do-it-yourself cleanups frustrating and often temporary.
- Lost visibility in Google Scholar. If crawlers hit errors, redirects or spam, articles can drop out of the index. From the cases our team has handled, getting back in is slow and never guaranteed.
Google Scholar and Indexers Don’t “Speak” WordPress
Google Scholar is not a regular search engine, and it has very specific expectations. Its inclusion guidelines say, among other things, that:
- Each paper must have its own unique URL.
- Bibliographic data should be exposed in HTML meta tags such as the Highwire Press tags (citation_title, citation_author and so on).
- The website must consist primarily of scholarly articles. News, magazine articles and editorials are not considered appropriate content.
- Pages must be available to users and crawlers at all times. Server errors, misconfiguration or very slow responses can cause articles to drop out of Google and Google Scholar.
A typical WordPress journal breaks several of these rules without anyone noticing: PDFs sit in the media library and are linked from posts that list several articles at once, meta tags are missing or duplicated by an SEO plugin, and the homepage mixes announcements, event posters and articles.
Here is the telling part: for publishers who manage their own website, Google Scholar’s own documentation recommends Open Journal Systems (OJS). Databases such as DOAJ and Scopus also look closely at things like a clear peer-review process, consistent metadata and long-term preservation. OJS gives you a structure for all of these from day one. On WordPress, you have to build and maintain each piece yourself.
Why OJS Is Built for the Job
Open Journal Systems is free, open-source software developed by the Public Knowledge Project (PKP) specifically for scholarly journals. According to PKP’s 2025 Beacon data, OJS now powers about 58,000 journals across 156 countries. Here is what you get out of the box:
- A complete editorial workflow: submission, peer review (including blind review), copyediting, production and publication, with roles for authors, reviewers and editors.
- Proper volumes and issues, with a clean archive that crawlers can browse.
- Google Scholar meta tags generated automatically for every article.
- OAI-PMH so indexers and harvesters can collect your metadata.
- DOI registration through the Crossref plugin, plus ORCID integration for authors.
- JATS XML support and long-term archiving through the PKP Preservation Network.
In other words, OJS doesn’t need fifteen plugins to behave like a journal. It is one.
Six Signs Your Journal Has Outgrown WordPress
If two or more of these sound familiar, it is time to plan your move:
- Your articles are published as blog posts or PDF attachments.
- You depend on a long list of plugins just to make the site look like a journal.
- Peer review happens over email and spreadsheets.
- You don’t have DOIs or proper citation metadata for each article.
- Your articles are hard to find in Google Scholar, or appear with the wrong titles and authors.
- You have already seen spam pages, strange redirects or unknown admin users on your site.
OJS Is the Right Platform, But It Still Needs the Right Care
We want to be honest here. Switching to OJS solves the structural problems, but it doesn’t make your journal immune to attacks. Because OJS is so widely used, it is a target too. The issues we see most often are spam user registrations, fake bot submissions, outdated OJS versions, gambling content injected into journal metadata, and flaws in bundled components.
We have written about real examples, such as a PDF.js flaw combined with an open redirect that can poison a journal’s Google results, and how we helped a UMM journal recover after it disappeared from Google Scholar following months of attacks and spam registrations.
The problem is that generic shared hosting doesn’t know OJS. It isn’t tuned for OJS, it has no OJS-specific firewall rules, and patches wait until you notice them. Moving to OJS on a generic host is a bit like moving into a better house and leaving the front door unlocked.
How OJT Hosting Keeps Your OJS Journal Safe
At Openjournaltheme.com, OJS hosting isn’t a side product. It is what our team works on every day. Our infrastructure is built only for PKP platforms, and it comes with security tools you won’t find at a general hosting company:
- Vortex Shield (OJT Guardian AI), server level. A web application firewall, malware scanning, brute-force and DDoS protection, bad-bot blocking, and real-time monitoring of uptime, malware injection and unusual activity. Learn more.
- OJT Advanced Security Plugin, application level. OJS-specific hardening built from real incidents we have handled, including protection for your metadata against illegal content such as gambling spam. Learn more.
- Exclusive OJS routine patching. We monitor PKP advisories and CVE databases, close security gaps early, and also patch vulnerabilities that PKP doesn’t cover. Every fix is tested on a staging copy first and deployed with zero downtime.
- Automated backups to S3 cloud storage, with database, article files and configuration included, so your archive is safe even if something goes wrong.
- Speed that helps indexing, with an Nginx smart-caching server and the OJT Blazing Cache Pro plugin included.
- Indexing-friendly extras such as the Crossmark plugin, RePEc for economics and finance journals, JATS Editor quota and a certificate generator on selected plans.
- Free installation, free SSL, free OJS-to-OJS migration with zero downtime, and an OJS upgrade every year.
- Infrastructure you can trust: ISO 27001-certified data centers, a 99.9% uptime SLA, and support from people who work with OJS every day.
What our clients say “We highly appreciate the OJT Team for their excellent support and commitment in securing our OJS site with their exclusive security tools such as Vortex Shield and Advanced Security Plugin.”Assoc. Prof. Marko Matulin, Ph.D., Traffic Journal (Scopus Q2), University of Zagreb |
Our managed OJS hosting plans start from $259 per year for a single journal, with larger plans for multi-journal and institutional publishers. See the full plan details.
Conclusion
WordPress is a great tool for many things, but publishing a scholarly journal isn’t one of them. It was never designed for peer review, volumes and issues, or the metadata that Google Scholar and other indexers depend on, so journals end up stacking plugin after plugin to fill the gaps. Every one of those plugins is another door for attackers, and today they can break in within hours of a new flaw going public. When that happens, the damage goes far beyond a few days of downtime: spam in your search results, tampered articles, exposed reviewer data, and a reputation that took years to build.
The good news is that you don’t have to keep patching a blog and hoping it holds. OJS gives your journal the right foundation from day one, with a real editorial workflow and metadata that indexers understand. Host it with a team that patches, monitors and protects OJS every day, and that foundation stays secure, so you can get back to what really matters: publishing good research and getting it read.
