Keep a low-traffic SaaS post if it still gives the right reader a useful, accurate answer. Improve it if that answer is worth keeping but needs work. Consolidate it only when another page genuinely serves the same reader; remove it when its content is no longer useful and there is no answer worth preserving. Low traffic tells you which post to review, not which URL to delete.
Review the answer before judging the traffic
Start with the published page, not a traffic threshold. Record the question it promises to answer, who needs that answer, whether its instructions and product claims still hold, and what a reader could do after reading it. Note any other page that might replace it—but open that page before calling it a replacement. A product page that merely mentions the topic may not answer the question in the old guide.
Ranks’ product reference says article activity can be viewed alongside performance, and its connected Search Console overview shows clicks, impressions, average position, and top queries by clicks. That makes it a useful place to spot posts for review. For evidence about one URL, use Search Console directly: inspect its page data and the queries associated with it over a comparable period. Search Console warns that filtering by URL or query can change report totals because data is truncated and anonymized queries are omitted; its query table does not show every search. An empty or short query list therefore cannot, by itself, establish that nobody needs the answer.
For each post, write down the reader question, current accuracy, evidence of search interest, related pages, and the reason someone would still want this answer. Treat clicks and impressions as context for prioritizing the review. The decision rests on what the page does for a reader today.
Choose a disposition, not a traffic cutoff
Apply the same test to every candidate: is the answer accurate, is it still useful to a relevant reader, and does another page actually provide that answer? The resulting choice also determines whether the current URL should remain available.
Improving a post means repairing an answer that still belongs on its existing page; the outdated-post refresh guide covers the editing work. Consolidation is a different decision: the destination must satisfy the old page’s readers, not simply be the nearest page by topic. If two published posts compete for the same question, use the overlapping-posts guide to work through that overlap.
| Choice | Reader value and accuracy | Search evidence and related pages | Action |
|---|---|---|---|
| Keep | Accurate answer for a real, if narrow, reader need | Few visits do not negate its distinct purpose | Leave the page and URL available; record why |
| Improve | Useful question, but the answer is incomplete or partly stale | The post still owns a distinct answer | Correct it on the existing URL |
| Consolidate | Useful material remains, but another page can serve its readers better | A specific destination answers the old question | Preserve useful material there, then retire the old page |
| Remove | Obsolete or misleading, with nothing useful to retain | No genuinely similar replacement exists | Take down the content and handle the old URL |
Two quiet posts can deserve opposite decisions
Consider this fictional review of two published posts with few visits. The first, https://example.com/blog/connect-crm-to-billing, explains a niche CRM-to-billing integration. Its steps still work, it answers a question that customers occasionally ask, and no other page provides those steps. Even if its Search Console query evidence is sparse, the worksheet points to keep: retain the URL and note the verified use case. If the integration still exists but one setup step has changed, the same inputs point to improve instead.
The second fictional post, https://example.com/blog/legacy-export-setup, instructs readers to enable a discontinued export feature. Its answer is inaccurate. Suppose a current migration guide at https://example.com/blog/export-migration explains how those users can now complete the task. Verify that the migration guide covers their question, transfer any still-useful explanation, then consolidate into that destination and retire the old instructions. If the feature is gone and no current page can help those readers, remove the obsolete guide without inventing a replacement. The two posts have similarly weak traffic; accuracy, reader value, and the destination determine different outcomes.
Handle the old URL according to what replaced it
Before taking down a public page, confirm its chosen destination is published and answers the old question. Prepare changes to site links that point to the old URL. If the release cannot publish everything together, make the destination live first; then release the old-page change and revised links. This is a site-owner publishing handoff, not a disposition control in Ranks.
Google recommends a 301 permanent redirect when a moved page has a clear replacement, so request one from the retired URL to the specific replacement—not to a generic homepage. If the content is gone without a similar replacement, have the old URL return a real HTTP 404 rather than showing an error message on a page that still returns a success status. Do not redirect an obsolete answer to a page that cannot fulfill its promise.
After release, open the old URL and check where it lands or which response it returns; open the destination to confirm the promised answer is visible. Check revised links on the live site as well. For a kept or improved post, check that its original URL still serves the intended answer. That final check closes the archive decision without treating a future traffic change as proof that the decision succeeded or failed.
