I came to content audits from technical writing, not the other way around. My background is in documentation — user guides, API references, in-app help, the occasional release note that nobody reads until something breaks. And if I’m being truthful, I used to think of content audits as a marketing-adjacent activity. Something people did to web pages about brand voice and conversion funnels. Not my world.
Working through chapters 8 through 13 of Paula Land’s Content Audits and Inventories this week — really sitting with the qualitative audit criteria, the rubric design, the team dynamics, the pilot process — I’ve had to revise that opinion pretty significantly. The more I read, the more I kept thinking: this is just technical writing, seen from the outside. These are the same problems I deal with every time I open a new doc project, just reframed as evaluation criteria instead of authoring decisions.
That realization feels important, especially as I think about where I want my career to go. Technical writing and content strategy are often treated as parallel tracks. But the skills that make someone good at one — precision, audience awareness, systematic thinking, an almost constitutional discomfort with vagueness — are exactly the skills that make someone good at the other. And a well-executed content audit, it turns out, is one of the best arguments for why technical writers should be at the strategy table.
The Criteria Are Just the Documentation Standards You Already Know
Chapter 8, on selecting and defining audit criteria, lays out a framework for evaluating content across four domains: business purpose and value, user value, content presentation, and usability. Land goes methodically through each one — accuracy, currency, consistency, audience-appropriateness, discoverability, readability.
Reading that list, I started mentally checking off which of those criteria I’d already been applying informally in my documentation work, without ever having named them as evaluation criteria. Accuracy? Every technical writer is, functionally, an accuracy auditor. Currency? That’s just keeping docs in sync with product releases. Consistency? That’s the style guide, the terminology database, the long arguments in Slack about whether to use “click” or “select.” The structure was always there. I just hadn’t thought of my daily work as audit practice.
What Land’s framework adds is the rubric — the part where you stop making gut-call judgments and start measuring systematically. She’s fairly insistent that criteria need to be defined well enough that a team of auditors can apply them consistently, not just one person who “knows it when they see it.” That’s a meaningful shift. Good/fair/poor or a 1–3 numeric scale sounds simple, but it forces you to answer the question that intuitive evaluation lets you skip: what specifically makes this content poor, and how is that different from what makes it merely fair?
For technical writers, this is an uncomfortable question in the best way. We have strong instincts. We can read a procedure and know within a few seconds whether it’s going to frustrate a user. But can we explain that judgment rigorously enough that someone without our instincts could reproduce it? The audit process demands that we can.
Style Guides Are Audit Inputs, Not Just Writer Tools
Chapter 13, the qualitative audit chapter, goes deep on audit inputs — all the reference materials you need to have in hand before you can actually evaluate content. Brand guidelines, voice and tone documentation, editorial style guides, content models. Land mentions DITA specifically, noting that organizations using structured markup will have detailed guidelines around information types and semantic structures, and that audit findings in those environments might surface back-end authoring issues as much as surface-level quality problems.
That sentence stopped me for a minute. Because it’s exactly right, and it’s something that gets missed when audits are scoped as pure content quality reviews without technical writing expertise in the room. A procedure that’s hard to follow might not be poorly written — it might be the result of a content model that forces writers into a structure that doesn’t match how users think. A reference topic that’s incomplete might reflect a DITA constraint that nobody questioned when the architecture was first set up. The writing is the visible surface of a system, and evaluating the writing without understanding the system underneath it gives you a partial picture at best.
This is where technical writers have a genuine advantage as auditors. We tend to understand the relationship between content architecture and content output in a way that not everyone on a cross-functional audit team will. We know why certain patterns keep appearing — not because writers are lazy or careless, but because the template or the component model makes certain things easy and other things nearly impossible. That institutional knowledge is real value, and it changes what you look for when you’re evaluating content.
“If you allow poorly written, unclear, inconsistent content to stand, you risk leaving the reader with a bad impression of the company. It distracts from the task at hand and can subtly undermine the brand.”— Paula Ladenburg Land, Content Audits and Inventories, 2nd ed.
Land is talking here about brand and marketing content, but the same logic applies to technical documentation with almost no modification. A poorly written installation guide doesn’t just frustrate the user who’s trying to set up your software — it communicates, implicitly, something about how much the company values the user’s time and intelligence. Technical content is brand content. It’s just that we rarely frame it that way.
The Expert/Novice Problem Is Essentially Our Entire Job
One section of chapter 13 that I’ve been thinking about a lot is the discussion of audience expertise — specifically the challenge of writing for sites that serve both expert users and people who are just getting started. Land frames this as an audit consideration: you’re looking for places where novices hit dead ends in content written for experts, or where expert users are slowed down by explanatory scaffolding they don’t need.
This is the central problem of technical writing, stated plainly. Every document I’ve ever written has lived somewhere on the expert/novice axis, and the interesting cases are almost always the ones where the intended audience doesn’t match the actual audience — where the content was written for someone with three years of domain experience but is being read by a new hire trying to get their environment set up on day one.
What the audit framing adds to this is a systematic way to surface that mismatch. Instead of relying on individual writers to calibrate their own work, you’re building into the evaluation process a specific question: does this content appropriately serve the audience who will actually encounter it, at the stage of the journey where they’ll encounter it? That’s a different question than “is this content well-written,” and it’s a more useful one.
As someone who wants to grow beyond individual contributor work — eventually into a role where I’m shaping content systems, not just producing content — this feels like a key reframe. The question isn’t just “is this doc good?” It’s “does this doc serve the right person, at the right moment, in the right way?” And the only way to answer that systematically, across a content set rather than one document at a time, is through something that looks a lot like an audit.
The Pilot Is Where Honest Calibration Happens
Chapter 11, on conducting a pilot audit, might be the most practically useful chapter in this section for someone new to audit work. The argument is straightforward: before you apply your criteria to hundreds or thousands of pages, test them on a small sample. See where team members disagree. See where the definitions break down. See how long it actually takes, so you can scope the work honestly.
Land describes a specific exercise — auditing a few pages together as a group and talking through the disagreements — that sounds almost exactly like a peer review process in a writing team. The goal is calibration: making sure everyone is working from the same understanding of what “good” means before they go off and make hundreds of individual judgments that will need to be reconciled later.
I’ve been on writing teams where we skipped this step — where everyone just trusted that we’d all internalized the style guide the same way — and the downstream costs were real. Inconsistent voice across a doc set, redundant content nobody caught because different writers were applying different thresholds for what counted as “duplicate,” terminology drift that accumulated slowly until suddenly we had three names for the same feature and no clear way to decide which one was canonical.
The pilot process is the structural answer to all of those problems. It slows you down at the start in order to speed you up for the rest of the project. For a technical writer trying to build audit practice into ongoing documentation work — rather than treating it as a one-time remediation effort — that habit of upfront calibration is probably the most transferable skill in these chapters.
Where This Leaves Me
I’ve been thinking about technical writing and content strategy as a Venn diagram for a while now. The more audit work I do — and the more carefully I read books like this one — the more I think the circles overlap more than either community tends to admit.
Technical writers are trained to think about accuracy, consistency, audience, structure, and usability in ways that content strategists often come to later, through frameworks like the ones Land is describing. Content strategists are trained to think about business goals, content ecosystems, analytics, and governance in ways that technical writers often pick up only incidentally, if at all. The audit is one of the places where those two ways of thinking have to coexist, because a good audit requires both.
That’s a pretty compelling argument for technical writers to get more involved in content audit work — not just as contributors who review the docs section of the spreadsheet, but as full participants who help shape the criteria, run the pilot, interpret the structural findings, and connect surface-level quality issues to the underlying systems that produced them.
It’s also a compelling argument for me to keep reading. There’s more in this book I haven’t gotten to yet.