Add a Spelling and Grammar Check to Your Pre-Publish QA Workflow

Most teams review a new page before it goes live.

Someone reads the draft, checks the links, and approves it.

But spelling and grammar often get a quick skim at best, and errors slip through on the pages nobody re-reads.

A structured check catches what a skim misses, and it can run at scale across a whole site, not just the page in front of you.

This article shows how to add a spelling and grammar check to your pre-publish QA workflow.

It covers what to check, which tools fit the job, and how to handle false positives.

It also explains where an automated check should and should not block publishing.

Why a Skim Is Not a QA Step

A human reader is good at meaning and bad at surface detail.

When you have written or edited a page yourself, your brain fills in what you intended rather than what is on the screen.

That is why writers miss their own typos, and why a page that reads smoothly can still contain repeated words, agreement errors, or inconsistent spelling of a product name.

There is also a scale problem.

A pre-publish review covers one page.

Over a quarter, dozens of pages ship, and older pages get edited by different people.

Without a systematic check, the quality of your published copy depends on who happened to review each page.

A repeatable check makes the standard consistent.

The goal is not perfection.

It is catching the errors that damage credibility with buyers, especially on high-intent pages such as pricing, product detail, and checkout-adjacent content.

Two Layers: Page-Level and Site-Level Checks

A useful QA setup has two distinct layers, and they answer different questions.

Layer one: check the page before it ships

Before a new or edited page publishes, run a focused check on that page alone.

This is fast, and it fits naturally into the review step someone already performs.

Most writing tools and browser extensions can flag spelling and grammar in a draft.

The key is making the check a named step in your QA checklist rather than something that happens only if the reviewer notices.

What this layer catches: typos introduced in the latest edit, broken sentences from cutting and rearranging paragraphs, and inconsistent terminology against your style guide.

Layer two: crawl the whole site periodically

Page-level checks do nothing for the hundreds of pages already live.

A site crawl fills that gap.

Screaming Frog's SEO Spider includes an automated spell checker (Screaming Frog).

It identifies spelling and grammar errors across a crawled website in 39 languages.

It covers page titles, meta descriptions and page copy, and it can also spellcheck PDFs.

Using the feature requires the desktop application and a paid licence (Screaming Frog).

A crawl answers a different question than a page review: which live pages have accumulated errors, and which errors appear most often across the site?

That second part matters, because one misspelled word repeated on many pages is a bigger fix priority than many unique one-off typos.

For a deeper comparison of the two approaches, see our guide to site-wide spelling and grammar checks on live pages.

Running a Crawl-Based Check

If you use Screaming Frog's SEO Spider, the documented workflow looks like this (Screaming Frog):

1. Enable spell check and grammar check under Config, then Content, then Spelling & Grammar. You can run either check alone or both together.
2. Set the language if needed. The tool reads each page's HTML lang attribute to pick the right dictionary. If your pages use a generic 'en' attribute without a region, the tool cannot tell UK from US English, so you can set a default such as English (United Kingdom). A manual override forces every page against one chosen dictionary, which helps when lang attributes are wrong.
3. Crawl the site and wait for it to finish.
4. Review error counts in the Content tab using the Spelling Errors and Grammar Errors filters, which show how many errors each page contains.
5. Open the Spelling & Grammar Details tab for a specific URL to see each error, its type, and a suggested correction alongside the page text.
6. Use the right-hand window, which lists the most common errors across the site and how many URLs each one affects, to prioritise fixes.

That last step is where the crawl becomes actionable.

Fixing the highest-frequency errors first removes the most visible problems with the least effort.

Handling False Positives Without Losing the Signal

Every automated language check produces false positives, particularly on marketing sites.

Product names, team names, brand spellings, and intentional stylistic choices will all get flagged.

Screaming Frog documents this directly: false positives are expected online (Screaming Frog).

Unique product names, team names, and branding and formatting choices shape written content.

The tool offers three refinement options: ignore a specific grammar rule, ignore all instances of a word, or add a word to the dictionary.

You can apply these from the top-errors list or from the per-page details view (Screaming Frog).

Use them deliberately.

A practical routine:

• Review the top errors list first. Anything genuinely correct, such as your product name, gets added to the dictionary once and stops appearing in future crawls. If a grammar rule consistently flags a style choice your brand makes on purpose, ignore that rule for the crawl rather than dismissing each instance one by one.
• Keep a short internal list of accepted words and ignored rules, so the reasoning survives staff changes.

The tradeoff is real: over-ignoring trains the check to stay quiet about real errors later.

Under-ignoring buries the signal in noise.

Review the ignore list occasionally, the same way you would review any filter in your analytics.

Should the Check Gate Publishing?

This is the decision the title asks, and the honest answer is: partially.

A hard gate, where a page cannot publish until the checker reports zero errors, sounds rigorous but breaks in practice.

Automated checkers flag correct words and intentional style.

If zero errors is the bar, reviewers learn to ignore everything the checker says, or the team adds exceptions until the gate is meaningless.

A softer gate works better in most teams.

Make the check a required step, but let a human resolve each flagged item with an explicit decision: fix it, or mark it as accepted.

The check's job is to force a decision, not to make the decision.

This keeps genuine typos from shipping while allowing legitimate brand language through.

For site-level crawls, gating does not apply the same way.

Live pages already exist; the crawl produces a prioritised fix list instead.

Treat the output as input to your content maintenance queue rather than as a pass/fail verdict.

One caution on scope: an automated check reveals specific kinds of errors, mainly spelling, agreement, and repeated-word problems.

It does not verify factual accuracy, tone, or whether the page answers the reader's question.

Those still need human review, and no checklist of automated checks replaces that judgement.

Fitting the Check Into Your Existing Workflow

The check only works if it happens reliably.

That means wiring it into the tools and steps your team already uses, not creating a parallel process nobody follows.

Practical placement options:

• Add a checklist item to your publishing template: 'Spelling and grammar check run, flagged items resolved or accepted.'
• If you use a CMS with a review workflow, make the check part of the review stage so it cannot be skipped silently.
• Schedule site crawls at a fixed cadence and assign the resulting fix list to an owner. Adjust the cadence to your site: a larger site or a high publishing volume justifies more frequent crawls, while a small, slowly changing site may only need a quarterly pass. If you already crawl for broken links, you can often run both checks in the same crawl session; our article on monitoring broken links with scheduled crawls versus manual checks covers that scheduling decision.

If your publishing runs through marketing automation, the same discipline applies to automated messages.

A typo in a nurture email ships to every new contact on the list, and unlike a blog post, you cannot edit it after it sends.

Our piece on AND versus OR logic in workflows covers another pre-publish decision for automated flows, and the same review-before-activation habit applies to both.

Common Failure Modes

Teams that add this check usually hit one of three problems:

• The check runs but nobody reads the output. This happens when the report is long and unfiltered. Fix it by reviewing the top-errors list first and refining the ignore list until the remaining output is small enough to act on.
• The ignore list grows unchecked. Every accepted word is a decision someone made once. Review the list periodically so stale exceptions do not hide new errors.
• Language settings are wrong. If your pages use generic lang attributes, the checker may apply the wrong regional dictionary and flag correct spellings as errors. Screaming Frog's default-language and manual-override options exist for exactly this case (Screaming Frog).

A Minimal Starting Checklist

If you are setting this up this week, start here:

1. Add a spelling and grammar item to your pre-publish review checklist, with an explicit fix-or-accept decision for each flag.
2. Pick a crawl tool and run a one-off baseline crawl of your live site to see the current error landscape.
3. Refine the output: add genuine brand and product terms to the dictionary, and note any grammar rules you intentionally ignore.
4. Fix the highest-frequency errors first, since they affect the most pages.
5. Set a recurring crawl cadence suited to your site size and publishing volume, and assign the fix queue to a named owner.

The exact tool matters less than the habit.

A check that runs every time, produces a short actionable list, and ends in a human decision will catch more over a year than any single thorough review.

For teams coordinating content, automation and revenue reporting, pre-publish QA is one part of a larger reliability question.

That question is whether the systems that publish and measure your marketing behave consistently.

That is the thread we follow across our articles on automating content refreshes from performance data and how often to check Google Search Console.

How Meshline can help. Connect automation, Organic Marketing (demand generation), and customer lifecycle management (Revenue Intelligence).

Bring topic planning, content publishing and performance feedback into the conversation about your workflow. Book a Meshline demo.