Content Audits

The basic premise behind auditing your content is to better understand both the structure and the content itself. Conceptually the idea seems simple enough, but in reality performing a content audit can be fairly boring. However, whether you are conducting the audit as part of a single source conversion project, or if you have recently inherited a large documentation set, I’d suggest that it is an excellent way to gain an understanding of what already exists and, with little guesswork on your part, start to understand what may be missing.

Content Audits are usually one of the early tasks undertaken by a team moving towards a single source publishing model but they can also provide a clear indicator about whether you need to single source or not. For many teams the primary driver of a move towards single source comes when an additional product platform or customer is introduced, or perhaps through a requirement to translate and localise. However, a thorough audit of your content will show whether what you believe to be true is valid and may indicate that you don’t need to start single sourcing your documentation at all (you might just need to change your working practises).

As I mentioned, the act of auditing, in any form, can be repetitive, onerous and very much a chore, so my first piece of advice is to break it up into short manageable chunks and most certainly don’t try and do it all at once. Perhaps aim to do a couple of chapters a week, thus leaving you time to do fulfill other duties, keeping the documentation up-to-date for example.

For me, the aim of a Content Audit is two-fold, on the one hand you will end up with a very detailed breakdown of the structure of your documentation, and on the other you should also be able to extrapolate the types of information that your documentation holds (e.g. procedures, concepts, and so on). A key benefit, which almost comes as a bonus, is that having spent time looking at your content, you will also have a good plan of which parts of the documentation can be reused and which parts may need rewritten before reuse is possible.

If you’ve done any research into this area, you probably have a good idea of what is involved and what the aims are. But what is a Content Audit, what does it look like?

Well it’s fairly simple and the easiest way to get started is to use your existing Table of Contents. Pull that out into a spreadsheet and you have an excellent starting point, particularly if your documentation has been written in short sections. Then you need to get into the content itself, and analyse the structure in a bit more detail. Again there are obvious chunks of information that can very easily be pulled out, or broken down, into discrete chunks. Procedures, illustrations, tables of data, anything that is of a similar type and is repeated throughout your documentation is easily identifiable as a distinct unit (you probably have unique paragraph formats for these too, another quick way to check!).

A simple example for you.

All of our product guides and online help have “Overview” sections. They are, typically, very very similar. The product guide Overview is longer than that in the online help.

With a small amount of re-writing, we can create chunks for “Overview” and an “Overview Extension”, with the former being used in the online help, and the latter appended when used in a product guide.

Ultimately a content audit will involve a lot of time reading, cross-checking, double-checking, and I’d advise you grab a nice big desk (in the boardroom perhaps?) so you can layout printed copies of your documentation. I’d also advocate that you don’t try and do the entire process, across all of your documentation, in one fell swoop. Pausing between batches, and discussing the findings with your co-workers, will stop you missing potential re-use opportunities AND stop you trying to re-use (re-write) chunks of information that need to be kept discrete.

Once you understand your own content, then you can start the process of seeing how it stacks up against the content created in the other areas of your company. More on that another time.

Written By

Long time blogger, Father of Jack, geek of many things, random photographer and writer of nonsense.

Doing my best to find a balance.

More From Author

You May Also Like

Photo of me and quote from the article

Some more about me

1 year at Allied

Reasons to work


From what I can determine, the term “content audit” was coined many years ago by Ann Rockley (The Rockley Group) and Hillary Marsh (Content Company). Correct me if I’m wrong, but I don’t see any recent buzz about this concept, and I get the distinct impression that it is more of a specific’s consultant’s approach rather than an open discipline. It doesn’t seem to rest on any theroetical foundation or have any reasonable body of knowledge associated with it.

Of course you have to understand what you have and refactor it. This is part of the analysis phase (and subsequent phases) of any development project, whether or not it’s a CMS or single-source publishing deployment. There are many analytical formalisms that can be brought to bear in this kind of effort. But a “content audit,” as it is explained here and in some of the earlier works seems rather vague and ad hoc.

Ann Rockley wrote a book in 2002, which I admittedly have not seen, in which the entire 6th chapter is dedicated to “content audit.” Does it have any meat?

–Gary Kopp (

Yes, that term comes directly from the book you mention (which I’ll happily recommend).

Not sure why you think I’m suggesting there is a ‘buzz’ about this… I don’t make that claim in my post and I’m perfectly aware that there are other ways to do such things.

Can you give some pointers to these other “analytical formalisms”? And is what I posted wrong? I was merely posting about my personal experience, but I’m always open to new ideas Gary.

Comments are closed.