Automated blog publishing needs a quality gate: 7 pre-publish checks and a 28-item checklist (2026)

When businesses ask us about automating their blog, the conversation quickly turns to how fast AI can write. Yet the trouble after launch rarely comes from writing speed. It comes from not having decided who looks at a finished article, what they check, and who says it may go live.

Automate the writing and the number of articles grows. If checking still relies on one person's attention, mistakes grow with it: wrong figures, dead links, misleading snippets, missing alt text, tables that break on phones.

This article treats the path from draft to publication as one pipeline and explains how to build the quality gate (the set of checks content must pass before publishing) inside it. How to audit your operations and decide what to automate is covered in our earlier piece, "Automating website operations starts with an audit". This one continues from there and focuses on article publishing.

Main sources for this article: Google Search Central's spam policies (updated 28 August 2026) and people-first content guidance (updated 5 October 2026), Pew Research Center's link-rot study (May 2024), the WebAIM Million 2026 and web.dev's Web Vitals.

1. What is changing: action against mass content, and a decaying web

Over the past two or three years, search engines and the web itself have moved away from "publish more and you will be found". Three shifts stand out: action against mass-produced content, decaying links, and accessibility problems that are not shrinking.

Google reported 45% less low-quality, unoriginal content

On 5 March 2024 Google announced a core update and new spam policies. It expected to reduce low-quality, unoriginal content in results by 40%, and in an update on 26 April 2024 reported a 45% reduction.

The same announcement introduced the "scaled content abuse" policy, which targets producing large amounts of content to manipulate rankings, whether by automation, people or both. Automated publishing has to be designed to stay on the right side of that line.

38% of pages from 2013 are gone

A Pew Research Center study published on 17 May 2024 found that 38% of web pages that existed in 2013 were no longer accessible. Even 8% of pages from 2023 had already disappeared.

Links inside articles fare no better: 23% of news pages and 21% of government pages had at least one broken link, and 54% of Wikipedia pages had a dead reference link. The more carefully an article cites sources, the more broken links it collects.

Accessibility problems are increasing

WebAIM runs automated tests on the home pages of one million sites each year. In February 2026, 95.9% of pages had detectable WCAG 2 failures, with an average of 56.1 errors per page, up from 94.8% and 51 in 2025.

The most common issue is low text contrast, found on 83.9% of pages. The six most frequent errors are shown below.

Apart from low contrast, these errors can slip in with any article update, and they are errors a pre-publish gate can stop mechanically.

2. What to automate in article publishing, and what not to

Splitting each stage of publishing into "work for machines" and "judgement for people" shows where the gates belong. The criteria are the same as in our earlier article: is the correct result defined from outside, and can a failure be undone? Whether a link returns 200 is defined from outside. Whether a figure is still correct cannot be settled until someone looks at the source.

No stage has an empty right-hand column. The point of automation is to give people more time for judgement.

Why we don't recommend fully automatic publishing

A system that publishes AI-written articles untouched can be built in a few hours. Beyond Google's statement that manual fact-checking and review before publishing is critical, wrong information can be picked up by search engines and AI answers the moment it goes live, and rolling back the page does not roll that back. It also helps to treat every article, figure update and typo fix as one kind of thing, "a change to the site", so they all pass the same gates and software tools such as version control, tests and rollback apply directly.

3. What a quality gate is: the seven gates at a glance

A quality gate is a set of checks content must pass before it is published. Software teams use the idea widely: if the tests fail, nothing ships. Applied to articles, it becomes seven gates.Links and tests are almost entirely automated; fact-checking and approval are almost entirely human.

The right-hand column is what matters. A check with no defined consequence is information, not a gate. If a warning still lets content through, people eventually stop looking at warnings.

Separate "blocking" checks from "advisory" checks

If every check blocks publication, operations grind to a halt. Checks with clear results and few false positives (dead links, structured data syntax errors, failed builds) become blocking checks. Checks that need interpretation (visual diffs, slight speed regressions) become advisory checks and feed the approver's decision.

4. Gate 1: fact-checking (figures, names, dates, sources)

The first gate is the hardest to automate. AI-written text can contain plausible but wrong figures and sources that do not exist. Google itself explains that generative AI predicts likely word sequences rather than retrieving facts, so its output can be wrong.

The goal of this gate is to list every verifiable claim in the article and match each one to a source.

Let a machine extract what needs checking

Finding what to check can be automated: extract numbers, dates, percentages, amounts, names, laws and "according to" sentences into a list.

Recording the next check date for prices and rules reduces articles left with outdated figures.

Trace sources back to the primary source

News stories about research often round figures or omit the survey year. Trace back to the original (research firm, authority or standards body) and cite its URL. If you cannot find it, drop the figure or attribute it ("…has been reported by…"), and record who decided and when.

Ask an AI to "fact-check this article" and you get text that sounds checked, but it is not a record of checking. AI may help extract claims and compare wording; the person who actually opened the source decides whether it is right.

5. Gate 2: links (dead links, redirects, internal links)

The second gate is the easiest to automate: request every link and check the status code. Because links decay, you also need regular scans of published articles.

What to do with each status code

Google's documentation says all 4xx errors except 429 are treated the same and indexed URLs are removed. A 301 (permanent redirect) is a strong signal; a 302 (temporary) is a weak one.

429 and 5xx are advisory so another server's temporary problem doesn't stop you; block after two consecutive failures.

Tools and internal links

Free tools are enough to start. For manual checks, the W3C Link Checker works well; for automation (CI), lychee checks links file by file; and Google Search Console reports 404s and "soft 404s" (pages that return success but show an error) on your own site.

Internal links count too. Before deleting an article, list the articles that link to it, and when a URL changes, redirect the old one with a 301.

6. Gate 3: structured data and metadata

The third gate covers what appears in search results, social previews and AI answers. Titles, meta descriptions, structured data and image alt text are seen by more people than the article body. Google's guidance on generative AI content explicitly includes this metadata in fact-checking and review.

Structured data needs both machine syntax checks and a human check of the content.

What Google's general guidelines require

Google's general guidelines say: don't mark up content that is not visible to readers, include the required properties for each type, and test with the Rich Results Test and URL Inspection tool, although some incorrect markup still passes. Violations can lead to a manual action that removes rich result eligibility.

Article markup and dates

Articles use Article or BlogPosting (Schema.org types). Google's article structured data page lists no required properties and recommends headline, image, datePublished, dateModified and author. Each author should be a separate author entry, without job titles or company names in the name field.

Take care with dateModified. Google asks for visible and structured dates to match, and its people-first content page lists changing dates to seem fresh when the content has not substantially changed as a sign of search-engine-first content. Make sure your pipeline does not rewrite the date just because a file was saved.

The sitemap lastmod works the same way: Google uses it only if it is "consistently and verifiably accurate". Updating a copyright year is not a significant change, and priority and changefreq are ignored.

What to do about FAQ markup

Google limited FAQ rich results to well-known government and health sites in August 2023 and stopped showing them from 7 May 2026 (the documentation was removed on 15 June 2026). There is little reason left to add FAQ markup for appearance. If you still add it, mark up only questions and answers visible on the page, word for word.

7. Gate 4: accessibility

The fourth gate checks that everyone, including people with disabilities, can read the article. As Figure 1 shows, errors are not falling, and automated checks only cover part of the problem.

Automated tests find just over half the issues

Deque, which develops axe-core, analysed more than 13,000 pages and nearly 300,000 issues and found that 57.38% of issues could be detected by automated testing. The W3C's Web Accessibility Initiative (WAI) likewise says evaluation tools can only assist, not determine accessibility. Zero errors is not a pass.

The contrast requirement is WCAG 2.2 success criterion 1.4.3 (level AA): at least 4.5:1 for normal text and 3:1 for large text (18 point, or 14 point bold). Ratios are not rounded, so 4.499:1 fails.

Four errors that come in with articles

In DevNJ's experience, four errors account for most of those introduced by articles: alt text that is empty or a file name, headings jumping from h2 to h4, link text such as "click here", and figures where the text is part of an image. That last one is why the figures in this article are SVG with descriptions.

8. Gate 5: rendering and page speed

The fifth gate checks how the article looks on real screens: something fine in the editor can overflow on the live page, or a heavy image can slow it down.

Visual checks: screenshot diffs

Visual checks compare a screenshot with a stored reference image, for example with Playwright's toHaveScreenshot. But rendering differs by operating system, browser, settings and hardware, so Playwright advises creating and comparing references in the same environment.

For articles you do not need to compare every page. Capture the new article, the article list and one representative article with many tables and figures, at phone width (375px) and desktop width. Whether a diff is intended or broken is for a person to decide, so this is an advisory check.

Speed checks: Core Web Vitals thresholds

Speed is judged with the Core Web Vitals defined on web.dev. "Good" means LCP (time to render the largest element) of 2.5 seconds or less, INP (responsiveness) of 200 milliseconds or less and CLS (layout shift) of 0.1 or less, assessed at the 75th percentile of real page loads, separately for mobile and desktop.

Before publishing you only have lab data. Lighthouse measures LCP and CLS but not INP, using Total Blocking Time (TBT) as a proxy. Use lab data to stop large regressions before publishing, and confirm with real-user field data afterwards.

Most speed regressions from article updates come from oversized images. A per-image file size limit (for example 300 KB) that blocks publication prevents much of the damage. The limit is a DevNJ rule of thumb and depends on how your site is built.

9. Gate 6: tests (build, HTML, existing features)

The sixth gate checks that a new article has not broken the rest of the site. Even a single file affects the article list, tag pages, sitemap and language switcher.

Tests to run for content

For DevNJ's own columns, scripts check required fields, the Japanese–English pairing and whether figure labels overflow before anything is published. Each is a few dozen lines, yet far more reliable than checking by eye every time.

The automation platform and its cost

Running tests automatically is called continuous integration (CI). GitHub Actions, a common choice, is free on standard runners for public repositories; private repositories get 2,000 free minutes a month on GitHub Free and 3,000 on Pro and Team. Beyond that, a 2-core Linux runner costs $0.006 a minute. Content checks take a few minutes, so dozens of updates a month usually fit in the free tier.

DORA's "change fail rate" (the share of deployments needing immediate intervention) also applies: count the share of articles that needed a fix or withdrawal after publishing.

10. Gate 7: approval and rollback

The last gate is human judgement. Even after six gates, a person decides whether to publish. The other half of this gate is being able to revert quickly.

Scale approval to risk

The same approval for every change turns a typo fix into a day's wait and approval into a formality.

Urgent changes may skip some gates, on condition that the skip is logged and the change goes through the full gates within 24 hours. Without a defined exception route, every rush job bypasses the system.

Make rollback a button, not a procedure

Rollback cannot wait while someone looks for instructions. If articles are in version control such as Git, reverting the last change and redeploying restores the previous state. DevNJ's target is to restore within 15 minutes of deciding to roll back. This corresponds to DORA's "failed deployment recovery time"; recording actual times shows where the weak spots are.

The final review is drawn as a dotted circle because it is the first step dropped when people are busy. Logging why items were sent back is the best clue for improving the gates themselves.

11. How Google's policies relate to the quality gate

Now to the question most people worry about: how Google treats automated content. The conclusion is that using AI does not change how content is evaluated, but mass production without added value is a problem. A quality gate is also a way to stay on the right side of that line.

The definition of scaled content abuse

Google's spam policies (updated 28 August 2026) define scaled content abuse as generating many pages "for the primary purpose of manipulating search rankings and not helping users", however it is created. Examples include generating many pages with AI without adding value, mass-producing scraped content through automated transformations such as synonymising or translating, and stitching content from different pages together.

If you run a multilingual site, note that translation is named as an automated transformation. Publishing English versions that are only machine translations of Japanese articles moves you towards this example.

The people-first questions

Google's "Creating helpful, reliable, people-first content" (updated 5 October 2026) suggests asking who created the content, how and why. "Why" is the most important: the main purpose should not be attracting search visits.

Where AI substantially generated content, it suggests disclosing that when readers would want to know, and calls fake authors with AI headshots or invented credentials deception.

Turning the policies into gates

Google says it has no preferred word count and lists writing to a particular word count as a search-engine-first warning sign. Padding content to reach a length backfires.

12. Cost and effort ranges

Cost depends on how much you automate. All figures are DevNJ estimates, not measured statistics, and vary with how your site is built and how much you publish. Yen amounts use €1 ≈ ¥176 (European Central Bank reference rate, 22 October 2026).

Three levels

Monthly costs cover CI time, preview environments and monitoring tools; level 2 often fits in a free tier.

If you outsource, the hourly rate drives the total. At €80 an hour, level 1 costs €320–640 (about ¥56,000–113,000), level 2 €1,280–2,560 (about ¥225,000–451,000) and level 3 €3,200–6,400 (about ¥563,000–1.13 million).

Checking time per article

The next table estimates checking time per article for a model site publishing four articles a month in Japanese and English (DevNJ estimate).

The savings come from gates machines can judge; fact-checking and approval time barely changes. With four articles in two languages, about 7 hours a month are freed (55 minutes × 8 pages). Decide as a matter of policy whether that time goes into more articles or deeper fact-checking.

13. Common failures

These are the failures DevNJ has seen most often. In each case, the cause was not the system but the rules around it.

The first is the most common. Making sure someone responds to every warning matters more than adding checks.

14. Japan and Europe compared

Businesses publishing for both Japan and Europe need gates that fit both. This comparison covers only article operations; consult a specialist for specific decisions.

Under the AI Act, AI-generated text on matters of public interest need not be labelled when a person has reviewed it and someone holds editorial responsibility (see section 8 of our audit article). Recording who checked and approved at gates 1 and 7 documents that review.

In Japan, articles that promote products or services fall under the stealth marketing rules of the Act against Unjustifiable Premiums and Misleading Representations (in force since 1 October 2023). When you commission articles or have AI write comparisons, add a clear disclosure that content is advertising to your gate checks.

15. Worked examples (three fictional companies)

Three fictional companies, invented for illustration, show how the right level depends on size, volume and risk.

For A, the quickest route is to run the 28 items by hand for one or two months and automate the items that actually stopped articles. For B, a wrong price turns straight into complaints, so prices are the top fact-check item, and while nobody can read Dutch, pausing the Dutch version is a valid option. C classifies every article as high risk with two approvers, and weighs the level 3 investment against the cost of publishing one wrong article.

16. Steps to introduce a quality gate

Here are eight steps. The first four need no tools.

1. Map the current flow. Write down on one page who checks what, in which order, before publishing
2. Collect past corrections. List articles fixed after publication in the last six months and why
3. Cut the 28-item checklist to fit. Remove irrelevant items and add missing ones
4. Decide blocking versus advisory. For each item, decide whether failure stops publication
5. Run it by hand for one or two months. Tick the checklist per article and record what stopped it
6. Automate items with a track record of stopping articles. Links, structured data and builds are safe starting points
7. Define approval and rollback. Write risk-based approvers and the revert procedure, then rehearse once
8. Review the numbers monthly. Send-backs, post-publish fixes and recovery times

Step 6 exists so you don't build checks nobody uses.

17. Checklist (7 gates × 4 items = 28 items)

These are the 28 items to check before publishing. Remove what doesn't apply and add what is missing.

Gate 1: Fact-checking

• Figures, dates, names and laws are listed
• Every figure has a primary-source URL
• The checker's name and check date are recorded
• A next check date is set for prices and rules

Gate 2: Links

• Every link returns 200 (redirects updated)
• 404 and 410 links are replaced or removed
• Internal link targets exist
• A monthly scan of all published articles is running

Gate 3: Structured data and metadata

• JSON-LD shows no syntax errors in the Rich Results Test or similar
• Structured data matches what is visible on the page
• A person has read the title and description; no exaggeration
• dateModified changes only when content changes

Gate 4: Accessibility

• Every image has alt text that conveys its meaning
• Heading levels don't skip
• Contrast is at least 4.5:1 (3:1 for large text)
• Link text alone tells you where it goes

Gate 5: Rendering and page speed

• Layout checked at phone width (375px) and desktop width
• Tables and figures don't overflow the screen
• Each image is within the file size limit
• Lighthouse LCP and CLS haven't regressed significantly

Gate 6: Tests

• The site build completes
• Front matter fields and formats are correct
• The HTML validity check shows no errors
• Language pairs and hreflang are correct

Gate 7: Approval and rollback

• The risk level is set and the required number of people approved
• The approver knows which parts AI drafted
• A revert procedure exists and can restore within 15 minutes
• Owners are assigned for the 15-minute, 24-hour and 7-day checks

18. Summary

• Start automating publishing by deciding the pre-publish gates before automating the writing
• Automate and block on what machines can judge; keep decisions about correctness, publishing and rollback with people
• Google doesn't penalise AI use itself, but mass production without value, automated translation at scale and date-only updates are problems
• Setup ranges from 4 to 80 hours across three levels. Checking time falls from about 95 to around 40 minutes per article, but fact-checking and approval time should not shrink
• Run the 28-item checklist by hand for one or two months, then automate the items that actually stopped articles

Sources

Google policies (Google Search Central and Google)

• Spam policies for Google web search — Google Search Central: definition and examples of scaled content abuse (updated 28 August 2026)
• Creating helpful, reliable, people-first content — Google Search Central: who, how and why; dates; word count (updated 5 October 2026)
• Guidance on using generative AI content on your website — Google Search Central: manual fact-checking, metadata and structured data review
• New ways we're tackling spammy, low-quality content on Search — Google: March 2024 announcement, 45% less low-quality content
• General structured data guidelines — Google Search Central: visible content, testing, manual actions
• Article structured data — Google Search Central: recommended properties and author markup
• Influence your byline dates in Google Search — Google Search Central: visible and structured dates
• Build and submit a sitemap — Google Search Central: lastmod and sitemap limits
• How HTTP status codes, and network and DNS errors affect Google Search — Google Search Central: 4xx, 5xx and redirects
• Changes to HowTo and FAQ rich results — Google Search Central Blog: the August 2023 FAQ and HowTo changes
• Latest Google Search documentation updates — Google Search Central: end of FAQ rich results (7 May 2026)
• Rich Results Test — Google: structured data testing

Web quality and accessibility (web.dev, W3C, Schema.org)

• Web Vitals — web.dev: LCP, INP and CLS thresholds, 75th percentile, lab vs field
• Understanding Success Criterion 1.4.3: Contrast (Minimum) — W3C: 4.5:1 and 3:1 ratios
• Selecting Web Accessibility Evaluation Tools — W3C WAI: limits of evaluation tools
• BlogPosting — Schema.org: the article type definition
• W3C Link Checker — W3C: link checking
• Nu Html Checker — W3C: HTML validation

Research and statistics

• When Online Content Disappears — Pew Research Center: 38% of 2013 pages gone, 23% of news pages with broken links (17 May 2024)
• The WebAIM Million — WebAIM: 95.9% of home pages failing in 2026, 56.1 errors on average, error types
• Automated Accessibility Testing Coverage — Deque: 57.38% of issues found by automated testing
• DORA's software delivery metrics — DORA: change fail rate and failed deployment recovery time

Tools

• Visual comparisons — Playwright: screenshot diffs and environment differences
• GitHub Actions billing — GitHub Docs: free minutes (2,000 and 3,000 a month) and per-minute prices
• lychee — GitHub: file-based link checking
• Lighthouse CI — GitHub: running speed checks in CI
• axe-core — GitHub: automated accessibility testing

European and Japanese rules

• Transparency obligations under Article 50 of the AI Act — European Commission: labelling AI-generated text and the human-review exception
• European Accessibility Act — European Commission: application date and microenterprises
• Directive 2005/29/EC (Unfair Commercial Practices Directive) — EUR-Lex: identifying paid editorial content (Annex I, point 11)
• Stealth marketing regulation under the Act against Unjustifiable Premiums and Misleading Representations — Consumer Affairs Agency (Japanese): in force since 1 October 2023
• Promoting the elimination of disability discrimination — Cabinet Office, Japan (Japanese): reasonable accommodation required since April 2024
• Euro foreign exchange reference rates: Japanese yen — European Central Bank: rate used for yen conversions (22 October 2026, ¥175.97)

All sources were checked on 22 October 2026. Policies, rules and prices change, so confirm the latest version on the official sites before making decisions. Effort and cost figures are DevNJ estimates, not measured statistics, and vary with site size and team.