You are looking at a page that is not pulling its weight. Maybe a client asked why it never shows up. Maybe you just noticed it while you were in Search Console for something else. Either way, you have to make a call: does this page need more content, does it need to be folded into another page, or does it need to go away. This piece walks you through an underperforming content audit you can run by hand, on any page, for any client, and it tells you exactly when to fix thin content by expanding it versus when a rewrite would be wasted effort.
Before you touch the page, get one thing straight. Thin content and underperforming content are two different problems, and mixing them up is how agencies end up rewriting pages that were fine and leaving broken pages alone.
Thin content and underperforming content are not the same thing
A page is thin when it fails to give the reader it was written for a useful, trustworthy, distinctive answer to the question it exists to answer. That is a judgment about the content itself. A page is underperforming when it is not getting the clicks or rankings you would expect. That is a judgment about an outcome. A page can be short and still complete an answer. A page can be three thousand words long and still say almost nothing new. Length is a clue at best, not a verdict. Google has said outright that it has no preferred word count, so a rule like "under 500 words means thin" is not coming from them and you should not be the one who invents it.
Traffic works the same way. A ranking drop on its own does not prove a page is bad, because other results might just be serving that query better right now. So before you decide anything, you are really answering two separate questions for each page: is the content itself doing its job, and is the page even getting a fair shot at showing up. Once you can answer both, the decision usually sorts itself into one of four buckets: expand a page with a real gap, consolidate two pages answering the same question, prune a page with no purpose left, or retain a page that is already doing fine even if its traffic is modest.
Keep a simple record as you go: the URL, who it is for, what job it is supposed to do, what you found, and what you decided. That one row per page is what makes this reviewable later, by you, by a client, or by whoever picks up the account after you.
The checks below are ordered so you rule out the fast, mechanical explanations before you spend time on the slower editorial ones. Work through them for one page at a time.
Check whether the page can even appear
Before you decide a page's writing is the problem, confirm the page is actually eligible to show up at all. A page with almost no impressions in Search Console might be thin. It might also be blocked, uncrawlable, or quietly folded into a different URL's numbers because of canonicalization.
Pull up the individual URL in Search Console's URL Inspection tool and check its indexing status. Google's baseline requirements are that Googlebot can reach the page, the server returns a 200 response, and the content is actually indexable text. Meeting those requirements makes a page eligible to be indexed, not guaranteed to be. If the tool tells you the page resolves to a different canonical URL, that is your answer: go look at the canonical version instead, because the missing numbers on this URL are not a verdict on its content.
If the page is genuinely blocked or missing from the index, fix that first. Do not write more copy for a page nobody can see yet.
Check whether people see it and pass on it
If the page is indexed and showing up, look at what happens once it appears. Open the Performance report in Search Console, filter to that URL, and look at the Queries tab. You are looking at impressions, clicks, click-through rate, and average position together, not any one of them alone.
A page with decent impressions but a low click-through rate is telling you something specific: people see it in the results and decide it is not what they want, before they even click. Search Console's own guidance points at the title, description, and how well the page seems to match the query. Pull the actual queries the page shows for and compare them honestly against the page's real content. Sometimes the mismatch is shallow, a title or meta description that undersells or misdescribes what is on the page. Sometimes it is not shallow at all: the page answers a slightly different question than the one people are actually asking, and no amount of title tweaking fixes that.
If the underlying answer is solid and complete for its intended reader, this is not a thin content audit criteria failure, it is a framing problem, and it deserves a narrower fix than a rewrite. If the queries reveal a real, missing piece of the answer, that belongs in the expand bucket. Either way, resist the urge to add words purely to try to move the click-through rate. That is not what it measures.
Check whether the page actually answers its own question
This is the core editorial check, and it is where most of the real thin content audit criteria live. Read the page the way its intended reader would, cold, and answer three questions in writing. What question does the title or headline promise to settle? Can someone finish that job using only what is on the page, without opening another tab? What does this page add that the other results for that query do not already say?
A page fails this check when it promises an answer and leaves out a needed distinction, condition, or conclusion. It also fails when it mostly restates what other sites already say without adding anything of its own, when it makes claims a reader could not verify or trust, or when a reader would still need to search again to finish their task. None of that requires the page to be short. A long page built out of repetitive, unsupported generalities can fail this check just as easily as a two-paragraph stub, and a short page that resolves a narrow question completely can pass it outright.
To fix thin content properly, you expand it rather than pad it: if the page has a real, distinct purpose and you can see exactly what is missing, that is an expand. If the missing piece more naturally belongs on a different, already-existing page, that is a sign you are actually looking at the next check, not this one. If you cannot identify a credible answer or a distinct purpose for the page at all, hold that thought and keep reading rather than jumping straight to deleting it.
Check whether another page already answers this
Two pages competing for the same reader question is a common finding once you start reviewing a site in earnest, especially on accounts that have had several writers over several years. Do not assume overlap just because two pages share a broad topic. A definition, a full comparison, and a step-by-step guide can all sit on the same subject and still serve genuinely different intents.
To confirm real overlap, put the two pages side by side and write down, for each one, who it is for, what it promises to answer, and what unique material it holds that the other page does not. In Search Console, check which pages show up for the same queries. If both pages promise essentially the same outcome to essentially the same reader, and neither one holds material the other truly needs, you are looking at a consolidation.
Pick the surviving URL based on which one best fits the reader's actual task, not just which one currently has more traffic. Fold in whatever genuinely useful material the weaker page had, then send that weaker URL to the stronger one with a permanent redirect. Do not retire a page into an unrelated destination just to avoid losing the URL entirely. A redirect target has to meet substantially the same need the old page did, or you have just traded one broken page for another.
Check whether the traffic is simply small on its own
Sometimes you reach the end of the first three checks and the page is indexed fine, its click-through rate is unremarkable rather than alarming, and the content genuinely answers its question. It just does not get much traffic. That is a real, separate outcome from thinness, and it deserves its own decision rather than getting folded into either of the other two.
Compare the page's intended question against the actual queries it shows for and the kind of result being served for those queries. Some questions are simply asked by fewer people, or a stronger competing result currently wins the more common phrasing of the query. Also ask whether the page serves a purpose beyond organic search. A client's own customers, a sales team, or a support workflow might link to that page constantly even though Google Search sends it very little.
If the page is adequate and distinct, retain it even with modest numbers. Low search demand for a topic is not the same finding as low value, and it is not a license to prune. If your review turns up a substantive question the page never addresses, treat that as an expand. If a better existing page already covers the same ground, that is a consolidation candidate after all.
Check whether the page has any reason left to exist
This is the last check, and it should be the last one you reach, because pruning is meant to be a last resort, not a first instinct when traffic looks weak. A page belongs here when it cannot credibly answer the question it promises, adds nothing a reader would miss, duplicates a stronger page elsewhere on the site, or exists mainly to catch search traffic rather than to help anyone who lands on it.
Before you recommend removing it, document what would be lost, check whether any other page needs to absorb material from it first, and confirm there is no reasonable successor page already covering the same ground. It is also worth asking the client directly whether the URL earns its keep outside of organic search, since an internal team sometimes relies on a page that looks dead by search metrics alone.
If a genuine successor exists, consolidate into it with a permanent redirect rather than a plain deletion. If there truly is no successor and the page is being retired, let it go rather than forcing an unrelated page to stand in for it. And be honest with the client about what pruning will and will not do. Removing a handful of weak pages is not a guaranteed rankings lever for the rest of the site, even when it is clearly the right editorial call for those specific pages.
When none of the checks give you a clear answer
Some pages will not sort cleanly into any of the buckets above on a first pass, and that is a legitimate outcome, not a failure of the process. Record it plainly as undetermined, retain pending investigation, rather than forcing a verdict to close out a report.
From there, go back over what might still be unresolved. Does Search Console's canonical attribution explain the missing numbers better than anything about the content itself. Is there a technical access or indexing issue that belongs with whoever manages the site rather than whoever writes for it. Is the disagreement really about how much a niche page is worth to the client, in which case that call belongs to the client or the account owner, not to a content checklist. Escalate the right question to the right person and move on to the next page rather than sitting on one URL indefinitely.
Build this into something you repeat, not a one-off cleanup
The value of this process for an agency is not any single page you fix. It is having one worksheet you can run the same way across every client's site, so a junior team member can produce a defensible recommendation and a senior strategist only has to review the judgment calls, not redo the whole audit. Keep the same fields for every page you review: the reader and their job, the actual answer on the page, what it distinctly contributes, whether it can be trusted, whether it fits the query, whether it is even visible, whether it overlaps another page, and the disposition you landed on with your reason for it.
Run this underperforming content audit on five or six pages this week rather than trying to audit an entire client site in one sitting. That is a realistic weekly chunk, and it is usually enough to tell you whether the approach is working before you commit to running it across a hundred pages. If you are managing this kind of review across a lot of client accounts at once, the part that gets expensive fast is keeping each client's voice, product facts, and decisions straight while you move between sites all day. That is the kind of repeatable, per-client structure DeepSmith's Content Studio is built to hold, so the worksheet travels with the account instead of living in one person's head.
