Know What You Already Have Before You Write Anything New

Writing more first repeats the same mistake

Most local businesses respond to weak content by writing more of it. Another blog post, another service page, another page for the next town over. If the site underneath already has a couple of pages competing for the same search, or a service page nobody links to from anywhere else on the site, the new page gets built on top of that same foundation. It inherits the overlap instead of fixing it, and it gets the same thin internal linking, because there was never a map of what the site already owns. Publishing volume goes up. Rankings stay flat, because the structure underneath never changed.

An audit is what makes that map. It is not a separate project that delays the writing. It is the first step of doing content marketing properly: know what exists before you add to it. Businesses that jump straight to how often to publish without knowing what they already have end up publishing into the same gaps and around the same weak links every time.

Build one inventory: every URL, its query, its job

Start with a complete list of every URL on the site. Pull it from the sitemap, the site's own navigation, or a crawl, whichever gets a full list rather than the pages you remember writing. A partial inventory just repeats the blind spot the audit is supposed to fix.

For each URL, record two things. First, the one query it exists to win: the specific phrase a real person would type that this page, and only this page, should be the answer to. Second, the one job it does for the business: answering a beginner's question, moving someone closer to calling, capturing a specific long-tail question nothing else on the site answers, or supporting a hub page by linking up to it. If a page cannot answer both in a sentence, that gap is itself useful information. A page with no clear query and no clear job is usually the one that gets a fix, merge, or remove verdict, not a keep.

This does not need special software. A spreadsheet with one row per URL and columns for the query, the job, and the verdict is enough to see the whole site at once, which is the point. A structured audit does the same work with more rigor once the list runs into the hundreds of pages.

Four verdicts: keep, fix, merge, remove

Once every page has a query and a job attached to it, assign exactly one verdict.

Keep and fix are usually the easy calls. Merge and remove take more judgment, because getting them wrong costs more than getting them right saves.

When merging two pages is the right call

Merge is the right call when two pages are genuinely trying to be the answer to the same question. The signs are consistent: similar titles, overlapping headings, both pulling a trickle of traffic instead of one page pulling a solid amount, both linked from the same spots on the site because whoever wrote the second one wasn't sure the first one existed. Splitting one answer across two thin pages is weaker than one page that actually covers the question. It is the same reasoning behind building a topic around one strong page instead of several competing ones.

To merge well, pick the page with more history, the better URL, the older publish date, or any existing links pointing to it, and treat it as the page that survives. Fold the useful content from the other page into it, then redirect the old URL to the survivor so the links and history pointing at it land somewhere instead of dead-ending.

Not everything that looks similar should be merged. A page built to answer a buying question and a page built to walk through a process can share a topic without doing the same work. Merging those blurs both jobs instead of strengthening one. The query and job columns from the inventory settle this. If the query is the same, merge. If the two pages are chasing the same query but doing separate jobs, keep both and link them to each other instead.

What makes removal safe

Removal is safe when a page has no real query attached to it, earns no organic traffic, and has nothing else on the site or off it linking in. A page like that is not helping anyone find the business. It is just another URL to maintain.

Removal gets risky when a page has any of those things even in a small amount: a trickle of traffic, a handful of external links, or a query it half answers that nothing else on the site covers. In those cases the better move is a redirect to the closest page that does cover the ground, not a flat deletion. The inventory is what tells the difference. A page with a blank query column and a blank job column, sitting at the bottom of the traffic list, is the safe one to take down outright.

The inventory becomes the writing queue

The audit is not finished when the spreadsheet is full. The fix and merge verdicts, sorted by how close each page already is to working, become the actual list of what gets written next. A thin page one good section away from answering its query correctly moves faster than a brand new page starting from nothing. A pair of overlapping posts waiting to be merged is worth doing before either one gets a single new paragraph.

New pages still get written, but only after the inventory shows a real gap: a query with a clear job behind it and no existing page anywhere on the site claiming it. That is a genuinely new page, not a guess. Everything else on the list, the keep, fix, merge, and remove verdicts, is the queue for everything that already exists. A refresh done from an inventory like this outperforms one done by scrolling through old posts and picking whichever one looks stale, because it works from what the whole site actually needs instead of what happens to be visible that day.

Frequently asked questions