Monthly AI content audit for your WordPress library

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.