Website content audit: the key things you need to know

With CIPD thinking about re-designing it’s website, we started to ask ourselves, what content do we have already, what do we need or want to keep?

No one really knew what a website ‘content audit’ entailed, so I did a review of the literature out there (there’s a bibliography at the end of this post) and put together a guide for my colleagues. You may find it useful if you’re about to embark on a similar journey with your organisation’s website.

What is a content audit?

A content audit is an accounting of all currently published web content, with all the details recorded in a spreadsheet.

Karen McGrane and Melissa Rach, Content Strategy for the Web.

A content audit will tell us exactly how much content we have on A content audit falls into a number of classifications, an inventory – that is an organised list of all of the pages and the content assets (text, audio, video, images, documents – PDF, ppt, doc. etc.), and an audit – that is the content’s quantitative metrics and its qualitative values. For example the qualitative measures of a site’s content will tell us, amongst other things, how much is inaccurate, off-message (ie doesn’t align to brand and Tone of Voice guidelines), what is too wordy for mobile, and so on. Quantitative measures can tell us where the content sits, what assets we have in what formats, as well as when it was created/last updated, who the content owners are, and so on (assuming there is metadata to help with these).

To paraphrase Karen McGrane a content inventory will tell us ‘what’s there’ and the audit will tell us ‘is it any damn good?’

A content inventory tells us ‘what’s there’ and the audit tell us ‘is it any damn good?’

An audit also encompasses statistical analysis of page-level web traffic; in order that we can determine what content is high value for our visitors, what pages are people interested in visiting but bounce straight off, and what content is languishing unread (and is it unread because it can’t be found, or because its not relevant to our audience)?

Given the importance of optimising the site for mobile (see Appendix: The Mobile Network Through 2018) the content audit should also include qualitative and quantitative criteria that will enable you to evaluate the content’s appropriateness for mobile consumption and responsive site design. For example character counts of headings (quantitative) and editorial factors such as wordiness/succinctness, consistency of style (qualitative). It will help us to determine how search-engine optimised the content is, how accessible, and how usable.

A content audit will also form the basis of any content migration work from the current site to the new site, in terms of determining what is worth migrating, what can be migrated ‘as is’ and what needs re-work: updating, rewriting, re-structuring, re-tagging, etc. as well as tracking migration activities. The content audit can also help with a gap analysis; given that CIPD is undergoing large scale strategic change, and that mobile includes new capabilities (eg geo-location), what content do we not have that perhaps we should have on a new and responsive site?

The content inventory/audit also helps with the information architecture of the new site, by providing a map of what’s already there. And in the final stages of a web re-design and content migration project, the content audit forms the basis of a governance and maintenance strategy going forward.

A content audit is typically captured in an Excel spreadsheet. The audit is followed up by (and the ‘audit’ process should always include) an audit report where the micro-level findings are interpreted and communicated at a more general level.

It’s often in those deep-level pages that the content is less-than-perfect – most in need of deleting or updating.A content audit should be exhaustive. It is tempting to audit just the top-level pages, or a set of sample pages. Given that most people land on a website via a search engine, many visitors may never navigate through from the top-level hierarchy, but rather land on pages deep within the site architecture. It’s often in those deep-level pages that the content is less-than-perfect – most in need of deleting or updating. And given that the content audit forms the basis of the migration strategy, it is important to audit every page.

What can be automated, and what can’t?

The content inventory (ie the list of every page on the site) and much of the quantitative audit work can be automated.

However, the qualitative audit must be done manually.

Technology doesn’t replace the context provided by human review.

Karen McGrane, Content Strategy for the Web.

Format of a content audit

A content audit takes the form of an Excel spreadsheet, commonly with the quantitative metrics recorded in columns on the right and qualitative values recorded in columns to the left. Commonly – and most logically – the audit is organised by site structure and should include the following content valuation categories.

Quantitative categories

Some of this data may be automatically retrieved. Talk to your web administrators.

  • Unique ID – assign one to every line in the inventory
  • Site section – where it sits in the site hierarchy
  • URL
  • Page type – landing page, research report, contact page, Factsheet, etc.
  • Page title (title – text that appears at the top of the browser window; appears [in bold and underline] in search engine’s result page)
  • meta tag contents and character count (What’s displayed on the search engine’s result page is taken from the title tag, the URL and the first 150 characters in the meta name="description content=" " tag.)
  • Character/word counts for Headings h1 and other structural tags (eg body, h2)
  • Format and downloadable media assets (eg text only; podcast only; text and video; text and pdf, Word doc, ppt., etc.)
  • Source – in house, content partner, users
  • Technical home – which WCMS, fed via API?
  • Metadata, particularly related to search

And qualitatively is that metadata useful, appropriate?

  • Date created and/or last updated

And qualitatively is it still current/relevant/appropriate?

  • Expiration date assigned to the page (if any)
  • WCMS template used
  • WCMS location – for migration purposes
  • Technical constraints – any Flash or other technology that won’t work on some mobile devices?
  • Member only, open, registration required?
  • Content owner – and/or who last updated the page
  • Traffic and usage stats
    • No. of page views (page rank)
    • Date last visited
    • Bounce rates
    • Absolute unique visitors
  • Duplicate content – so as not to be competing with ourselves in search results

Qualitative categories

Qualitative factors are often categorised on a rating scale, for example poor, satisfactory, good, excellent, or 1–5, etc. Audit criteria, in particular ratings, must be articulated and agreed up front in measurement guidelines before the audit begins.

  • Mobile optimisation requirements
    • Identify content types that may require re-formatting/re-sizing for mobiles, eg tables; large images or complex infographics; columned text; lists etc.
    • Identify text that does not observe good web writing practice (eg short, simple, ‘inverted pyramid’ style, consistent and optimised headings that support ‘skimming and scanning,’ etc.) See my forthcoming blog post on Great Web Writing for details.
  • Search engine optimisation requirements – does the content (and assets, eg image file names) include keywords (and in the right places)? See my forthcoming blog posts on Great Web Writing and Search Engine Optimisation for more on this.
  • Accessibility – in order to meet the requirement of the Equality Act (2010) it is recommended that CIPD’s website meets WCAG 2.0 Priority 2 (AA). In qualitative terms this involves auditing:
    • Use of plain English
    • Support for auditory ‘skimming and scanning’ of headings and links
      Tagged foreign words, terms and definitions
    • Tables and non-text data such as infographics, bar/pie charts provided in HTML
    • Use of transcripts and closed captions for audio/video assets.
      (See my forthcoming blog post on Accessibility for more on this.)
  • ‘Actionability’ – how clear is the call to action (be it ‘buy’ or ‘share’)?
  • Audience – which customer personas does this content serve/address?
  • Business value – are there any KPIs that we might want to measure the content against?
  • Brand/Tone of Voice guide – is the content in line with the new guidelines?
  • Style guidelines – tense, punctuation, grammar, spelling, consistency of terminology, etc.

There may of course be other criteria to include; in fact the list of qualitative and quantitative evaluation criteria must be determined by the business as a whole, in line with the web requirements as well as the business’s strategic objectives.

Audit report

The spreadsheet represents the ‘deep dive’, but the findings need to be analysed, tailored and communicated to stakeholders. To that end the audit is condensed and interpreted in an audit report and/or presentation.

The audit report should comprise of three parts:

    1. Audit overview – goals, process, scope, audit categories and criteria for evaluation (particularly for qualitative measures)
    2. A path to the raw data – for those who want to see the spreadsheet, provide an explanation of how the spreadsheet works
    3. Findings
      • Summary of overall conclusions and recommendations
      • Major findings (often best communicated visually)
      • Data summaries for all categories

Category-based suggestions for improvement (with examples)

Paraphrased from Content Strategy for the Web, Karen McGrane.


  • Scott Abel and Rahel Anne Bailey, The Language of Content Strategy
  • Margot Bloomstein, Content Strategy at Work
  • Erin Kissane, The Elements of Content Strategy
  • Karen McGrane, Content Strategy for Mobile
  • Karen McGrane, Content Strategy for the Web
  • Sarah O’Keefe and Alan S. Pringle, Content Strategy 101

Appendix: The Mobile Network Through 2018

Research by cisco (taken from Mobile Mythbusters, Rachel Johnston and Joe Pairman of Mekon.)

Mobile data traffic will reach the following milestones within the next five years.

  • Monthly global mobile data traffic will surpass 15 exabytes by 2018.
  • The number of mobile-connected devices will exceed the world’s population by 2014.
  • The average mobile connection speed will surpass 2 Mbps by 2016.
  • Due to increased usage on smartphones, smartphones will reach 66% of mobile data traffic by 2018.
  • Global mobile data traffic will increase nearly 11-fold between 2013 and 2018.
  • Mobile data traffic will grow at a compound annual growth rate (CAGR) of 61% from 2013 to 2018, reaching 15.9 exabytes per month by2018.
  • By the end of 2014, the number of mobile-connected devices will exceed the number of people on earth, and by 2018 there will be nearly 1.4 mobile devices per capita. There will be over 10 billion mobile-connected devices by 2018, including machine-to-machine (M2M) modules—exceeding the world’s population at that time (7.6billion).
  • Mobile network connection speeds will increase two-fold by 2018. The average mobile network connection speed (1,387 Kbps in 2013) will exceed 2.5 megabits per second (Mbps) by 2018.

Tables – a responsive design solution

Recently I’ve been thinking about tables a lot. Not just the wooden kind, although I’m thinking about those too, as I need a dining room table (oh, and a dining room). But mostly the tabular kind of table. We have a lot of tables at CIPD (the tabular kind). As we move away from just publishing reports in PDF, to HTML on a responsive web site, and e-books, we need to find a way to display the tabular data in a more readable format.

Why tables are a pain

Tabular data presents unique presentational challenges on smaller screens: tablets, ‘phablets’, and especially smartphones.

The reader can zoom out and see the whole table, but the text is too small to read. Visual relationships between headings and cells, and between neighbouring columns, are crucial to understanding tabular data, so readers must zoom in to the point of readability, and then scroll vertically and horizontally to understand the context. Tabular data presents unique presentational challenges on smaller screens: tablets, ‘phablets’, and especially smartphones.

To control the often chaotic reformatting of HTML tables on websites and in eBooks, tables are often provided as image files. However, this creates an accessibility issue. Tables as images (in fact all images) can’t be read by screen reader software. It is unlikely that the fallback of alt text (image alt=" ") is sufficient to fully explain the context of the table. (See my forthcoming blog on Web Accessibility for more on this subject.)

Why tables are a pain for CIPD

Tables are a particular problem for CIPD’s reports, in that they rely heavily on them to present data. The example below is taken from Absence Management Survey 2013 and is typical of the use of tables in CIPD reports.

typical page of tabular data from a PDF report

Responsive design

Responsive design is a web design approach aimed at crafting sites to provide an optimal viewing experience – easy reading and navigation with a minimum of resizing, panning, and scrolling – across a wide range of devices (from mobile phones to desktop computer monitors) Wikipedia

Responsive design provides a solution for optimizing websites according to the screen size (see my blog post Responsive Web Design: the basic principles for more on this issue) but until very recently still struggled to come up with a suitable solution for the presentation of tables.

The best solution out there

Over the last couple of years web designers have been experimenting with the best way to use responsive design techniques to come up with a way of presenting tables that display comfortably at a wide range of screen sizes and preserves the table structure so that data can still be compared across columns.

There are a number of experimental solutions out there, but this, from Zurb, I think is the best (I recommend you view this page on a smartphone and/or a mini tablet.) The code is a combination of CSS3 and JavaScript and the code template is freely available. This solution allows for desktops to display the full size table but smartphones (or otherwise smaller screens) get a version where the left hand ‘key’ column is fixed and the columns to the right can be viewed by scrolling across the touchscreen.

… most of the time, the first column is the unique key for a table. That provides the reference for the other columns, while the column headers provide the legend for what everything means. With that in mind, we wanted our responsive tables to have that first column available at all times.

a drawing of Zurb's responsive table design

This is a schematic of how the table changes from a larger screen to a small one. Basically, we take the first column and pull it out of the table element, positioning it over the table in its own element. Then we allow the table itself, minus that first column, to scroll under it horizontally.

From (

Device Compatibility

Zurb have tested the code on the following browsers: iOS, Android and Windows Phone 7, Chrome, Safari and Firefox. “One caveat is that because Android 2.3 doesn’t support scrollable divs on the page, the scrolling won’t work on those devices. Android 3 and up does support this, so it’s not an issue on newer Android phones.” Currently this means that this functionality is not supported on around 14% of phones, however, this will continue to decrease as older models are replaced. (Android’s market share is [Sept 2013] 55%; Android 2.3 and lower currently represents [as of Dec 2013] 25% of Android devices.)

Other notable solutions

Alternative responsive table design solutions can be found at:
This solution shows only the essential data on small screens; shows the essential data plus some optional data for larger screens; and shows the full data on desktop/laptops. But this does mean that SmartPhone users do not get the full set of data; it also means that editorial decisions need to be taken as to the relative importance of each of the columns.
This solution abandons the grid layout of the table altogether on smaller screens and makes each cell its own line.
This table builds a pie chart from the table data when it is displayed on a smaller screen. Clever, but not all tables are suitable for this kind of treatment.
This solution hides the non-essential columns on smaller screens, but also provides a dropdown menu, where the reader can choose which columns to re-enable, should they so wish.
Some of these solutions may be appropriate in particular circumstances and for particular types of data.

Responsive design: the basic principles

So, as CIPD embarks on its website ‘re-design’ project we’re planning on building a ‘responsive’ site. But what does ‘responsive’ actually mean? I thought I’d better find out.

Ethan Marcotte coined the term ‘responsive web design’ in his A List Apart article in May 2010 and further expanded the technique in his book Responsive Web Design (2011, A Book Apart).

Up until Marcotte’s new approach, web designers generally ‘fixed’ their designs (with fixed-width layouts and fonts), providing them with “certainties that help[ed] quarantine our work from the web’s inherent flexibility” (Marcotte) and enablled them to preserve the designer’s original vision.

And then smartphones came along. Fixed designs – optimised for desktops – didn’t work on smaller screens, where the text and images become impossible to read and the navigation impossible to navigate with ‘meat pointers'(!) instead of a mouse.

Small screens have unique constraints, including ‘Meat pointers’ instead of a mouse!In order to solve the problem of smaller screened devices, many companies opted for native Apps or mobile sites; but this doubles the work – two sites to maintain. (In fact more than doubled! Marcotte: “Even if you build a native mobile application for one platform, chances are you won’t be able to create one for every platform. Apple’s iOS requires Objective C; Google’s Android needs Java; Microsoft’s Windows Phone 7 relies on Silverlight; Samsung’s Bada requires C++; And even if you can create native applications for each platform, the cost of maintaining them can quickly make it prohibitive.”)

To provide a different ‘device-optimised’ experience for every platform, every device, and every screen size is – with the current explosion in internet-enabled devices – simply impossible.

Then tablets arrived; then Smart TVs… and the number of devices and screen sizes exploded. To provide a different ‘device-optimised’ experience for every platform, every device, and every screen size is – with the current explosion in internet-enabled devices – simply impossible. Another solution was required.

Marcotte took three web technologies that already existed – fluid grids, flexible images, and media queries – and united them under a single technique that is revolutionising web design.

Fluid Grids

The typographical grid system was borrowed from print and graphic design. The typographical grid system (see Grid systems in graphic design by Müller-Brockmann, 1961) was introduced from print and graphic design to web design around 2007. Grid generators and downloadable templates were developed to help web designers build sites according to the principles of the grid system. Sites were built with fixed-width grids (usually based on an average screen size of 960 pixels) to preserve the design across different sized monitors, and with fixed width elements set in absolute units.

the grid system

The flexible grid technique simply takes designs based on the standard grid system and makes all of the elements proportional rather than fixed width, by setting CSS measurement values in percentages or ems, rather than pixels or points.

Flexible Images

Text reflows using the fluid grid technique, but images and other media resources do not. Setting the max-width property on the img selector in CSS to 100% ensures that the image is contained within the width of the container. Modern browsers will resize the image proportionally; “as our flexible container resizes itself, shrinking or enlarging our image, the image’s aspect ratio remains intact” (Ethan Marcotte). This rule can also be applied to video.

A word of caution about infographics

If the image is particularly information-rich, for example data-intense infographics, simply scaling the image down on smaller screens may make them difficult to understand. Providing (via media queries, see below) multiple versions of the infographic – for example a full version for desktop and a simplified version for smaller screens – may be one solution to deliver the most appropriate image for the screen size.

Media Queries

Although fluid grids and flexible images allow for the web page to re-size according to changes in screen size and resolution, often the integrity of the design is lost.

…Even slight changes to the size and shape of the browser window will cause our layout to warp, bend, and possibly break outright … [there are] areas where our design breaks as it reshapes itself

Ethan Marcotte

To reclaim control over the design as it re-sizes, media queries allow web designers to optimise the page to respond to the various browsers and devices that will access it.

With CSS3 came the introduction of the media queries module: @media. Media queries allow the page to use different CSS style rules according to the characteristics of the device the site is being accessed from. Marcotte writes: “think of a media query like a test for your browser”. For example if the screensize matches a particular size (e.g. @media screen and (min-width: 1024px)) the correct styles and features for that device size are rendered. The query can test for minand max width and height, as well as a host of other things, including orientation, aspect ratio and resolution. Multiple queries can be linked together to create sophisticated and targeted tests.

To fully optimise the power of media queries, web designers must thoroughly research the target devices and browsers for the appropriate resolution ‘breakpoints’ and build queries accordingly.


Responsive design advocates generally encourage using HTML5 rather than the older HTML 4.01. HTML5 is a leaner, more semantic code, which supports accessibility (see forthcoming post on Web Accessibility for further information) and faster loading (due to bandwidth considerations).

HTML5 might be ‘easy going’, but best practice markup standards are important for fast loading and SEO.

Although HTML5 is ‘easy going’ and does not enforce strict markup, best practice markup standards are important for fast loading and for search engine optimization (see Building Findable Websites, Aaron Walter).

(Additionally EPUB3 requires XHTML5, HTML that follows XML’s strict, well-formed syntax. Unless your organisation is to maintain two versions of the same code – one sloppy for web, one well-formed for eBooks – you should consider always following strict markup conventions.)

Older browsers and polyfills

Older versions of Internet Explorer do not support all of the new features of HTML5. For example, IE6 and lower do not support the max-width property, described in Flexible Images above.

There is widespread and growing support for CSS3’s media queries among modern browsers and devices, but it is not yet universal. And again, Internet Explorer in particular has poor support before IE9 (released March 2011).

However, there are numerous “Polyfills” (tools that “cover the cracks” of older browsers) that can retrofit newer HTML5 and CSS3 functionality for older browsers. Polyfills are generally written in JavaScript (many Polyfill fixes are available free for download) but the code overhead can be high, with performance implications.

Mobile first: taking a cautious approach

I work for CIPD. Our website is great. Well, it’s not exactly great. But it has a lot of great content on it. It’s just that it’s very hard to find anything on the site. And if you try to access it on a tablet, or heaven forbid, a mobile phone, you could find your eyes bleeding with the effort pretty quickly.

We’re currently embarking on a website re-design. I’ve been thinking about this for a while, having read Luke Wroblewski and the great Karen McGrane earlier this year.

This is very much my personal response to the original proposal that CIPD should embark on a ‘mobile first’ approach to its website re-design and is written from a content strategy perspective. I wanted to know what was meant by ‘mobile first’ and where the term came from. The more I read, the more I realised that a ‘mobile first’ approach has certain limitations.

And the more I investigated, the more I realised we should be looking to a responsive web design as a way to deliver a single site that will respond to the increasing array of screen sizes (including mobile). But responsive design is only part of the solution, the other part being adaptive content, which will require a carefully thought-out content strategy.

We need to be careful about creating separate ‘satellite’ mobile sites, and make sure we don’t use ‘mobile’ as an excuse for a ‘contextualised’ experience, or the wholesale decimation of useful content that currently resides on our website.

Responsive web designs are increasingly used by content-rich organisations, a selection of examples are provided here – for viewing on a modern, resizable browser as well as on various devices.

First use of ‘mobile first’

Luke Wroblewski first advocated for a ‘mobile first’ approach to web design in late 2009 and expanded his position further in his book Mobile First (A Book Apart, 2011).

…things have changed so dramatically over the past few years that starting with the desktop may be an increasingly backward way of thinking about a web product. Designing for mobile first now can not only open up new opportunities for growth, it can lead to a better overall user experience for a website or application.

Wroblewski says that by designing primarily for mobile, rather than the desktop, web designers (and by extension the businesses they work for) must streamline the navigation, simplify the design, improve performance, and focus the content and services delivered to the user. Mobile first ‘has a laser-like focus on what customers need’ when they’re using their mobile phones. And by focusing on the mobile experience, that experience is improved for all users; no matter what device they are using to access the site.

Just because users are on their mobile phones…

Wroblewski argues that because people often use their smartphones in shorter bursts, mobile usage can be characterized by particular interaction types:

  • Lookup/Find: I need an answer to something now—frequently related to my current location in the world.
  • Explore/Play: I have some time to kill and just want a few idle time distractions.
  • Check In/Status: Something important to me keeps changing or updating and I want to stay on top of it.
  • Edit/Create: I need to get something done now that can’t wait.

and that mobile experiences should be structured and organised to meet those needs.

…You can’t assume you know what they’re doing

Karen McGrane however, in her book Content Strategy for Mobile (2012, A Book Apart) argues that we cannot infer anything about the behaviour of the user from the fact that they are accessing a site from a smartphone.

‘Mobile’ doesn’t necessarily mean you’re on the move. …People use every device in every location, in every context. Knowing the type of device the user is holding doesn’t tell you anything about the user’s intent. Knowing someone’s location doesn’t tell you anything about her goals. You can’t make assumptions about what the user wants to do simply because she has a smaller screen. In fact, all you really know is: she has a smaller screen.

One of the common misconceptions about mobile is that users only want task-based functionality:

Do people want to look it up? They’ll want to look it up on mobile. Do people need to search for it? They’ll want to search for it on mobile. Do people want to read it, deeply and fully? They’ll expect to read it on mobile. Do they need to fill it out, document it, and enter it into the system? They’ll need to do it on mobile. Think of any piece of information people may want to access on the internet. They will need to access it on a device that isn’t a desktop website.

I think McGrane is correct: we cannot guess at what our users, readers, customers want from a site simply because they are accessing it from a smartphone. Designing for the ‘mobile context’ mustn’t be used as an excuse to make mobile an inferior experience.  Smartphones are the truly ‘personal computer’ of the early 21st century and we are using them for every kind of interaction that we had on the desktop as well as a whole host of new interactive transactions that are unique to the smartphone (e.g. augmented reality using the camera; location-specific information and services based on data from GPS and phone mast triangulation).

Responsive web design is only part of the answer…

Responsive web design – Ethan Marcotte’s revolutionary amalgam of fluid grids, flexible images, and media queries – is a powerful technique to optimise the design at the front end (i.e. as it is delivered) to the device’s size, resolution and capabilities. See my forthcoming blog on Responsive design: The basic principles for more information.

Responsive web design can make a single site accessible, usable, navigable and beautiful across all devices – from oversize Smart TVs, through laptops, tablets, ‘phablets’, and smartphones. Having a single site is also a way of ensuring that separate ‘mobile’ sites (or Apps) are not built: unloved satellites of the ‘main’ (i.e. desktop) site.

There is no reason why a responsive website cannot support content-rich web experiences, as is demonstrated in the examples listed at the end of this post.

It is adaptive content that is the other piece of the puzzle that will help CIPD and other content rich organisations to optimise and deliver content to whatever device the reader finds is appropriate to their particular circumstances.

The best marriage, then, is between adaptive content and responsive design. Responsive design, working with adaptive content, seamlessly displays content on whatever device the user chooses to view it on.

Rahel Anne Bailey and Noz Urbina, Content Strategy: Connecting the dots between business, brand and benefits, 2013

…Adaptive content is the other

Anne Rockley coined the phrase ‘adaptive content’ in Managing Enterprise Content, 2012:

Adaptive content is format-free, device-independent, scalable, and filterable content that is transformable for display in different environments and on different devices in an automated or dynamic fashion. [It] automatically adjusts to different environments and device capabilities to deliver the best possible customer experience by filtering and layering content for greater or lesser depth of detail.

And for CIPD that means ensuring that we have a robust strategy in place that can deliver and sustain adaptive content.

Examples of content-rich responsive sites

The following examples should be viewed on a modern, resizable browser to demonstrate responsive design in action:

Higher Education

Government and Health
Conferences and events
Publishing eCommerce site


We must ensure that ‘mobile-first’ doesn’t become an excuse for a separate, satellite mobile site, where the ‘contextualised’ content and functionality resides (i.e. what a user might need when she’s ‘on the go’!), but the main (desktop) site remains pretty much status quo.

Nor should it be an excuse for a ‘slash and burn’ approach to our web content to make it more ‘mobile friendly’. Instead, the content that is currently hosted on the site should be carefully evaluated as part of a content audit to check for what is current, useful, well written (or otherwise) and relevant. Content that is quantitatively valuable should be assessed for its fitness as ‘adaptive’ content and re-worked/marked up accordingly. (See my forthcoming post on website content audit.)