This page explains how content on Press Forge gets written, checked, reviewed, and corrected. It's here so you can hold us to the process and so Google's quality raters can see what that process actually is. Every blog post and service page on this site follows the workflow below.
Our content is written by working WordPress practitioners, not a content farm. When we say "we tried X on a client site", we did. When we cite a number, we link to where we got it.
How We Research
We write about WordPress from lived experience. Every blog post is drawn from 25 years of building, hosting, and maintaining WordPress sites for UK small businesses. We don't rewrite release notes.
When a topic needs outside context, we cite primary sources: official WordPress documentation, the Make WordPress blog, Core Trac tickets, or first-party announcements from plugin vendors and hosting providers. Secondary sources are a starting point, never an endpoint. For news-related posts we verify each claim against at least two independent primary sources before publication.
How We Fact-Check
Before a post goes live we verify:
- Every external link returns HTTP 200. Broken or redirected links are replaced or removed.
- Every statistic, price, or date traces back to a named source we have read and linked to.
- Every quote is attributed to a named person with a reachable identity: employer, profile URL, or published interview.
- Every code sample has been run locally against the WordPress version it targets.
- Every schema block validates against the Schema.org Validator and Google's Rich Results Test. Zero errors is the ship bar.
We do not use AI-generated statistics or fabricated quotes. If we can't verify a claim, it doesn't go in.
How We Cite Sources
Primary-source citations first, always. When we quote or paraphrase an outside expert, we link to the page where the statement can be independently verified, not to a blog recap of it.
Links to our sister companies (365i for hosting, BSolve IT for software) stay dofollow and are disclosed in context. Sponsored or affiliate links, if we ever use any, get rel="nofollow sponsored". Third-party plugin recommendations in our Plugins library are rel="nofollow noopener".
At the end of every research-based article you'll find a Sources block listing every external reference used.
Who Reviews Content Before Publication
Every post has a named author and a named editorial reviewer. The reviewer checks each post against this standards page before it publishes, and again whenever the post is substantively updated.
The reviewer name and review date appear in each post's meta line as "Editorially reviewed by [Name] on [Date]", so you don't have to take our word for it. The author's identity, role, and contact path are in the author bio at the bottom of every article.
Where the author and the reviewer are the same person, we say so. We'd rather be transparent about a one-person review than pretend a one-person review is a team review.
How We Correct Errors
The web changes. We prefer transparent correction over silent rewriting.
When we materially update a post (new sections, factual corrections, or pricing changes) we log the change in an Update Log block near the author bio, with the date and a one-line summary. The post's dateModified and visible "Last reviewed" date are updated to match. Typos, formatting tweaks, and link refreshes do not warrant a log entry.
If we discover a factual error serious enough to change a reader's decision, we flag it at the top of the post, not only in the log.
See it in practice: our Lockerfella case study carries a live Update Log (revised as new ranking data came in) plus the "Editorially reviewed by" line, and our WordPress 7 delay coverage shows the same log pattern on a news post, including a dated correction when the release schedule changed. Every standard on this page is checkable against the published work. That is the point of having the page.
Our Use of AI
Modern AI tools are good at some parts of content work and poor at others. We use them, openly, for the parts where they actually help. We don't use them to write the article.
What AI is used for on this site
- Research assistance: surfacing primary sources, cross-referencing claims, spotting contradictions between releases and documentation.
- Fact-check support: verifying that an external URL still 200s, that a quoted statistic appears in the cited source, that a code sample runs against the version it targets.
- Structural feedback: spotting missing sections, slipped heading hierarchy, places where a list or table would help the reader.
- Final polish: catching typos, awkward phrasing, British-English slips, inconsistent capitalisation.
What AI is NOT used for on this site
- Writing the draft. Every post on this blog is drafted by a human who has done the work being described. Thinking, angle, voice, and opinion are human.
- Fabricating statistics, quotes, or examples. If a number isn't sourced to a named organisation, it doesn't go in.
- Standing in for lived experience. When we say "we tried X on a client site", we did.
How we enforce it
Before publication every article is swept for the patterns that betray pure AI output: em dashes in prose, curly quotes, filler phrases like "delve into", "navigate the landscape", "leverage", "it's not just X, it's Y", or "Whether you're a...". Sentences should vary in length. Contractions should sound like a real writer used them. Concrete client examples should outnumber generic lists. If a draft fails the sweep, it goes back for a rewrite.
Report a Correction
If you spot something wrong on this site, tell us. Get in touch with the page URL and what you think is wrong. We'll investigate, fix it, log the correction if it's substantive, and update the review date. Suggestions for things we should cover next are also welcome.
