# Monthly AI content audit for your WordPress library

> Every month we scan a fresh slice of your published posts for machine-written content and build a prioritized cleanup list your team can actually work through.

- Workflow type: agent
- Services: Pangram, WordPress, Airtable, Slack
- Categories: Marketing, Operations
- Published: 2026-08-13

## What it does

- Works through your back catalogue a slice at a time each month, starting with the pages that matter commercially, so you get answers on your money pages long before the long tail
- Checks the full text of each published post for signs it was machine written and scores how likely that is
- Files every audited post in Airtable with its title, link, publish date, author, score and a high, medium or low risk band, so you end up with a cleanup backlog instead of a one-off report
- Posts a monthly Slack recap covering how many posts were checked, how many look high risk, how much of the library you have covered so far, and the worst offenders

## What you'll need

- A WordPress site with published posts, and a login that can read them
- A Pangram account on a paid plan, since AI detection through their API requires one
- An Airtable base with a table ready to hold the audit results
- A Slack workspace and the channel where the monthly recap should land

## Prompt

On the first of every month, audit a slice of my published WordPress library for AI-generated content and turn what you find into a remediation backlog in Airtable. I inherited years of posts from past agencies and freelance writers and I have no idea how much of it is machine written. This workflow is strictly read only against my site: never edit, update, unpublish, delete, retitle or otherwise change any post, and never create drafts. It reads posts and writes results elsewhere, nothing more. Any cleanup is a human decision my team makes later from the backlog.

Start by reading the existing audit table in Airtable using List Records. Collect the post IDs and URLs that previous runs already audited, plus the total number of records in the table. This is the resume state: every run must cover a new slice of the archive rather than rescanning posts that have already been scored, so anything already present in the table is skipped. If the table is empty, this is the first run and the whole archive is still open.

Next, pull published posts from WordPress using List Posts, filtered to published status only. Page through the archive to build the candidate pool, and capture the reported total count of published posts, because that total is the denominator for the running progress figure reported in Slack. Exclude anything already audited.

Do not work in pure date order. Prioritize the pages that carry the most traffic and commercial weight so the valuable content gets answers first and the long tail waits. Rank the remaining candidates using the signals available to you: commercial intent in the title and slug, such as pricing, best, top, versus, comparison, review, alternatives and buying guide language; posts in money-making categories or tags versus news and general blog filler; posts that are clearly service, product or landing pages rather than incidental updates; and engagement signals such as comment volume. If my team keeps a traffic or revenue value column in the Airtable table, read it during the List Records step and let real numbers override these heuristics. Recency is a tiebreaker at most, never the primary sort.

Size the slice from the detection budget rather than a fixed post count. A single Pangram bulk request is capped at 1,000 billable units, where one unit is one started 100-word block per item on Pangram 4, or one started 1,000-word block per item on Pangram 3, with a minimum of one unit per item. Full blog posts consume units quickly, so a 1,200-word post costs about 12 units on Pangram 4 and roughly 80 such posts fill a single request. Estimate the word count of each candidate post body, walk down the ranked list adding posts until you approach the cap, and stop there. If I want a larger monthly slice, split the work across several sequential bulk jobs rather than trying to exceed the cap in one request.

Submit the post bodies with Create Bulk AI Detection Job, stripping HTML markup, navigation, boilerplate and shortcodes so the detector sees the actual prose. Keep a mapping from each submitted item back to its post ID, title, URL, publish date and author, because the results come back keyed by item and you need that mapping to write meaningful records. Poll the job until it reaches a terminal state, then read the scores back with Get Bulk Job Results, paging through until you have every item.

Write the records to Airtable in the same run. Bulk results are only retained for 48 hours after the job completes, so there is no option to defer this to a later run: if the results are not persisted now, they are gone. Use Create Records, and note that it accepts a maximum of 10 records per call, so chunk the writes into batches of 10 and keep going until every audited post has a record. Write one record per audited post containing the post title, the post URL, the publish date, the author, the AI likelihood score, a risk band, and the month the audit ran so progress is traceable over time. Band the scores as High for 0.8 and above, Medium for 0.4 up to 0.8, and Low below 0.4, and treat those cutoffs as adjustable defaults. Also record the priority tier you assigned during ranking so my team can sort the backlog by value rather than by score alone, and work the high-risk, high-traffic pages first.

Finish with a Slack summary using Send a Message. Cover how many posts were scanned this month, how many landed in the high-risk band, the running percentage of the library audited so far calculated as total records in the audit table divided by total published posts, and the worst offenders by score with their titles linked to their URLs. Keep it short enough to read in the channel, lead with the high-risk count, and say plainly how many posts are still unaudited and roughly how many months remain at the current pace.

Handle the edges honestly. If an individual item fails detection, for example because the body had too little extractable text, skip it rather than guessing a score, and mention the count of skipped posts in the Slack summary so they are not silently lost. If the whole archive has already been audited, do not rescan: post a short Slack message saying the library is fully covered and note the oldest audit month, so my team can decide whether to start a fresh pass. Never invent a score for a post that was not actually scanned.

## How to customize

- Change the timing. The first of the month is the default, but weekly or quarterly works exactly the same way
- Change how big each monthly slice is, and the order it works through the archive: top revenue pages first, one category at a time, or a particular freelancer's back catalogue
- Move the cutoffs for what counts as high, medium and low risk, and choose who gets the Slack recap

## FAQ

### Will this change, unpublish or delete any of my posts?

No. It only reads your posts. Nothing is edited, unpublished or deleted, and no drafts are created. The results are written to Airtable and Slack, so your site is never touched. Any cleanup stays a human decision.

### Why does it only check part of my library each month?

Detection is priced by volume, and full blog posts add up fast, so scanning an entire archive in one go gets expensive and slow. Each run takes a fresh slice, skips anything already audited, and picks up where the last run left off. The Slack recap tells you what percentage of the library you have covered so far.

### What does the AI likelihood score actually mean?

It is how confident the detector is that the text was machine written, not proof that it was. Treat a high score as a signal to put that page in front of a human reviewer, not as a verdict. That is why every post lands in a backlog rather than being actioned automatically.

### Can it handle a big archive, say 5,000 posts?

Yes. That is the point of the slice-based approach. It tracks which posts have already been audited, so a large library gets covered steadily over several months instead of in one expensive batch, and you see progress each month.

### Why does it not just start with the oldest posts?

Because age is a poor proxy for risk. A five-year-old post nobody visits matters far less than a pricing or comparison page bringing in customers today, so the audit works through the commercially important pages first.

Use this prompt in General Input: https://www.generalinput.com/prompts/monthly-ai-content-audit-for-your-wordpress-library