Editorial
Standards

We start every article with primary sources: the official Google Search Central documentation, the WordPress core release notes, the original announcement from a vendor or government department, the actual product page from the company being discussed. When we link to a claim, we link to the source that originated it, not to a secondary recap.

Articles draw on actual experience hosting WordPress sites and managing infrastructure since 2002. Where we cite uplift figures, support load reductions, or migration outcomes, those numbers come from real client work, not industry averages.

We do not rewrite vendor press releases or recap commentary from other outlets without adding analysis grounded in our own work.

Since Google's 15 May 2026 non-commodity content guide and the May 2026 core update, we apply an explicit test we call The Receipt Test to every page we publish: could a competitor produce this without doing the work? If yes, the page is commodity and we rewrite it. In practice that means dated certificates instead of "fully insured", named customers and real callouts instead of "we serve thousands of clients", and live verification instead of self-declaration. The framework is explained in full in our case study, The Receipt Test: a non-commodity local business website case study.

Every external link in a published article is fetched live before deployment. Broken links and 403/404 responses are replaced or removed before the article ships.

Statistics, prices, and dates are cross-checked against at least one independent source. For breaking news posts that target Google Discover, we require at least one Tier 1 source (an official company blog, government source, or recognised press release) plus two corroborating sources from named, credible publications.

Code examples are tested locally before publication. JSON-LD schema blocks are parsed at build time and validated against the Schema.org Validator and the Google Rich Results Test after deploy.

Primary sources first. We prefer linking to the official documentation page, the original announcement, or the original research over a blog summary of the same. External outbound links use rel="nofollow noopener". Links to our sister sites (365iwebdesign.co.uk, ai-visibility.org.uk, pressforge.co.uk, and mcneece.com) are not marked nofollow because all are part of the same property, owned by BSolve IT Limited.

Every article that makes external claims ends with a Sources block listing the references in the order they were used. Quotes are attributed to a named person at a named organisation, with a verifiable URL.

We do not accept paid placements, sponsored posts, or affiliate commissions inside articles. If that ever changes, the disclosure will appear directly in the article body, not buried in a footer.

Hosting copy is a minefield of inflated numbers. We try not to add to it. Specific commitments we hold ourselves to:

• Pricing: every "from" price on every page is generated from a single data file and reflects what the order page actually charges that day. There is no separate "marketing price" anywhere on the site.
• Support response: we describe support as 7 days a week, including evenings and weekends, never "24/7". The data centre and platform are monitored 24/7 by our infrastructure provider; the human support team is not.
• Performance figures: any LCP, INP, or page-weight figure cited in an article comes from a real measurement (PageSpeed Insights, Chrome DevTools, or our own server-timing logs) on a real site, not a generic marketing claim.
• Migration outcomes: "we cut their support tickets by X%" or "uptime moved from Y to Z" figures come from actual client engagements. We do not invent representative numbers.
• Data centre locations: we describe our footprint as UK, US & Asia (Singapore), with UK as the default. Articles do not say "UK data centres" as if UK were the only location.

If you spot a hosting claim on this site that does not match what the order page or the platform actually delivers, treat it as a bug and report it via the form at the bottom of this page.

Every published article carries a visible byline and an "Editorially reviewed by" line beside the publication and last-reviewed dates. Reviewer name and review date appear in both the article body and the article's structured data, so they are visible to readers and to search engines.

Editorial review at 365i is led by Mark McNeece, founder and managing director. Mark personally signs off on every article before publication, checking factual claims, link integrity, code samples, schema, and tone against this standards document. Where a specialist reviewer (technical, security, or legal) signs off on a particular article, that reviewer's name appears alongside Mark's.

See Mark's profile and credentials.

When an article is substantively revised (a factual correction, a pricing change, a new section added, an outdated claim removed) we add an entry to the article's visible Update Log with the date and a description of what changed. Typo and formatting fixes are not logged.

When a correction changes the meaning of a previously published claim, the original wording is preserved alongside the correction so readers can see what changed. If the correction is significant enough to affect search results, we update the schema's dateModified field to match the visible Last Reviewed date.

Every article on this site starts with Mark McNeece's lived experience: a real client case, a real hosting incident, a recurring support pattern, or a measurement taken from a live site. Mark sets the angle, supplies the anecdotes and figures that give the piece its non-commodity grounding, decides what the piece is for, and decides where it should land.

From that brief, the legwork of research, verification, and audit is handled by a multi-agent AI orchestration system Mark has built for the editorial workflow. Anthropic's Claude is the orchestrator. It dispatches parallel sub-agents in Google Gemini, OpenAI Codex, OpenAI's image and language models, and additional Claude agents for specific sub-tasks: web research, claim verification, image production, and code generation. Claude itself runs every quality gate before the piece leaves the workflow. That includes the E-E-A-T audit (Experience, Expertise, Authoritativeness, Trustworthiness), the non-commodity content check we call The Receipt Test, schema validation against the Google Rich Results Test, source citation verification, the AI fingerprint sweep, and the link integrity check that confirms every external URL responds 200 OK.

Mark then reads the piece line by line before publication and rewrites wherever the wording, tone, or technical phrasing does not match how he would say it to a customer on the phone. It is rare for an article to publish in the exact form the workflow produced.

We disclose this openly because being honest about how content is produced is part of trustworthiness.