How to Run a Content Audit That Ends in Briefs

Somewhere in your shared drive there is a spreadsheet called something like "Content Audit Q2 FINAL." It has four hundred rows and eleven columns, color-coded, with a tab of pivot tables nobody has opened since the week it was built. The audit happened. Nothing changed.

That spreadsheet is the most common outcome of a content audit, and the guides that rank for the topic mostly lead you straight to it. They cover goals, inventory, categorization, analysis, and an action plan, which is all correct and stops one step short. An action plan is still a document about work. Writers need assignments. This guide runs the standard audit quickly and then spends its real effort on the part the others leave as "slot it into your schedule": converting each verdict into a brief someone can actually start on.

What a content audit is for

A content audit is a page-by-page judgment of what a site already publishes, made against a goal. The judgment part matters more than the inventory part. Listing your URLs is a crawl. Deciding what each one should become is the audit, and the decision has to be specific enough that a person other than you could act on it next Tuesday.

Pick one goal and a scope you can finish

Audits die from scope before they die from anything else. "Audit the whole site" sounds thorough and produces exactly the spreadsheet above, because by row two hundred the person doing it is tired and the verdicts get vague.

Choose a single goal and let it cut the scope for you. Recovering organic traffic means you audit the blog and the guides, and you ignore the legal pages. Fixing a confused topic structure means you audit one cluster at a time, starting with the one whose pages compete with each other. Retiring thin pages before a redesign means you audit everything, but you only need two columns of data. A goal that cannot tell you which rows to skip is too broad.

Build the inventory with only the columns you will use

Pull the URL list from a crawler like Screaming Frog or from your CMS export, then join it against Search Console for clicks, impressions, average position, and the top queries per page. Twelve months of Search Console data smooths out seasonality; three months tells you where a page is heading. Use both if the goal is traffic recovery.

Then stop adding columns. Every column you add is a column you have to fill for every row, and the ones that feel responsible (word count, reading level, image alt coverage, social shares) rarely change a verdict. Add the column you will actually argue from: the primary query each page is supposed to own. Without it you cannot see two pages chasing the same search, which is the most expensive problem an audit finds.

Give every URL exactly one verdict

A row with two verdicts has none. "Refresh or maybe merge" means someone will have to do the audit again for that page later, probably under deadline. Force a single call from this set.

Keep. The page earns traffic or links, matches its intent, and nothing on page one has leapfrogged it. Most of a healthy site lands here, and the work is close to zero.

Refresh. The intent still fits and the URL still has history worth protecting, but the substance aged or a competitor now covers more. Pages sitting at positions four through fifteen are the best candidates on most sites; they are close enough to move.

Merge. Two or more pages split the same query and neither wins. One URL survives, the others redirect into it, and their best sections move over.

Delete. No traffic, no links, no intent the site still cares about. Remove it, and redirect it if anything points at it.

Gap. This verdict has no URL. It is a row you add when the audit shows a query your cluster should own and nothing on the site answers it.

The step every audit guide skips: verdicts become assignments

Here is where the spreadsheet usually stalls. "Refresh" is a category, and a writer handed a category will make up their own assignment. Each verdict needs its own kind of handoff, and they differ more than people expect.

Keep rows produce no writing work, but they are not free. Scan them for internal links to the pages you are about to change. When a merge moves a URL, every keep page linking to the old address needs its link updated, and that task belongs to whoever owns the CMS.

Refresh rows get a refresh brief, which protects as much as it changes: a keep list, a change list, a cut list, and a one-line diagnosis of why the page slipped. The full field set is in how to brief a content refresh. Most of the research is already sitting in your audit row, so these are the fastest briefs you will write all quarter.

Merge rows get the hardest brief of the set, and it is the one most teams never write. Name the surviving URL. List, section by section, what migrates from each retiring page and what gets dropped. Write the redirect map into the brief itself so the writer and the developer work from the same document. Then give the merged page one angle, because a merge that staples two articles together ends up ranking for neither query. Read the cluster strategy guide before you decide which page survives; the answer depends on where the page sits in its cluster as much as on its traffic.

Delete rows go to a developer as a ticket with a redirect target, or a deliberate 410 if nothing should replace the page. No writer is involved. Teams that route deletions through the content queue tend to watch them sit there for months, because nobody on that queue feels authorized to remove anything.

Gap rows become new-article briefs, built from scratch with SERP analysis like any other brief. The one thing the audit adds is a list of existing pages that must link to the new one when it ships, which you already know because you just read all of them.

The test for whether the audit is done is blunt. Every row has a verdict, a named owner, and a brief or a ticket attached. A row that genuinely needs neither gets one written sentence saying why. If a row has a verdict and nothing else, the audit is still in progress, whatever the file name says.

The delete column

An audit that deletes nothing was an inventory with extra steps.

Order the work by what each assignment protects

Run the merges first. They change which URLs exist, and a refresh brief written for a page that is about to absorb two others will be wrong by the time the writer opens it. Deletions and their redirects can ship alongside the merges. Refreshes come next, starting with the pages closest to page one. New gap articles go last, so their internal links point at the post-audit site instead of at pages that are about to move.

Put all of it on the content calendar next to new production, with dates. Audit work kept in a separate tracker loses every scheduling fight to new content, because new content has a launch date and the audit has a spreadsheet.

How often to run it

A full-site audit once a year is plenty for most teams. The useful habit is smaller and more frequent: a quarterly pass over the pages ranking four through fifteen, plus a cluster-level audit any time two of your own pages start trading positions for the same query. Small audits finish. Finished audits produce briefs, and briefs are the only output of this whole exercise that changes what a reader finds when they land on the site.