What Happens to a URL After You Delete a Blog Post?

What happens to a URL after you delete a blog post?

Whatever you decide, and if you decide nothing it returns a 404 and everything pointing at it now points at nothing. The deletion is the easy half. The half that matters is choosing between a redirect, a 404, and simply not deleting, and that choice depends on what a person arriving at that URL was hoping to find.

I care about this because pruning has become fashionable advice, and the advice usually stops at which posts to remove. Removing is one decision. What the old address does afterwards is a second decision, and it is the one that shows up in your inbox six weeks later.

After more than 350 published articles I have made every version of this call, including the lazy one, so the framework below is mostly a list of things I would rather you not have to learn the way I did.

When should the answer be a redirect?

When a genuinely equivalent page exists. Equivalent means a person who wanted the old thing would be satisfied by the new thing, not merely that the two are about similar topics. That is a higher bar than it sounds and it is where most bad redirects come from.

The test I use is whether I could put the old title and the new page side by side and feel comfortable. If the old post promised a tutorial and the new page is a category listing, the answer is no. A reader who clicked expecting steps and landed on a list of links has been sent somewhere, not helped.

Consolidation is the clean case. If you merged three thin posts into one thorough one, the three old URLs should point at the new one, because the new page genuinely contains what each of them promised. That is the situation where a redirect is not a workaround, it is the correct description of what happened.

What does Google actually do with a permanent versus a temporary redirect?

It treats them as answers to different questions, and Google's documentation is unusually crisp about it. Permanent redirects show the new redirect target in search results. Temporary redirects show the source page in search results.

The mechanism behind that is about canonicalisation. Google says permanent redirects, meaning 301 and 308, signal that the redirect target should be canonical. For temporary redirects, meaning 302, 303 and 307, the indexing pipeline does not use the redirect as a signal that the target should be canonical.

So if you are consolidating permanently, use a permanent redirect, because a temporary one tells Google to keep showing the old address for something you have deliberately retired. I am not going to tell you how long the change takes to appear, because the documentation I am quoting does not say and I would be guessing.

When is letting it 404 the right answer?

When nothing equivalent exists and you are comfortable saying so. A 404 is not a failure state, it is an accurate answer to a question, and accuracy has value. The page is gone. Pretending otherwise by shunting the visitor somewhere irrelevant is worse for them than an honest dead end with a good way forward.

This is where I part company with the instinct to redirect everything to the homepage. Google's documentation on redirects, at least the page I am quoting, says nothing about that practice either way, so I will be clear that this is my judgement rather than a rule: a homepage redirect converts a specific unmet need into a generic landing, and the visitor is now further from an answer than a 404 page with a search box would have left them.

Which is why the 404 page itself deserves real design attention rather than a shrug. If your removal strategy produces dead URLs on purpose, the page those URLs land on is part of the strategy, not an afterthought.

Why is noindex not the same as deleting?

Because noindex is an instruction about search results, not about the page. The page still exists, still resolves, still accepts visitors, and still carries whatever links point at it. All you have changed is whether Google lists it.

That is sometimes exactly what you want. A thin post that a handful of existing customers still reference does not need to be in search results and does not need to disappear. Noindex is the precise tool for that, and it is underused because people reach for deletion instead.

What it is not is a removal mechanism, and treating it as one leaves you with a growing pile of pages nobody maintains and nobody can find. I have written about the related distinction between noindex and a robots disallow, and the confusion between those two is the single most expensive misconfiguration in this whole area.

What is the single most common mistake here?

Blocking the URL in robots.txt and adding noindex at the same time, believing that two measures are safer than one. They are not. They cancel out, and Google says so directly.

Google's documentation states that for the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and has to be otherwise accessible to the crawler. It then explains the consequence plainly: if robots.txt blocks a URL, the crawler will never see the noindex rule, and the page can still appear in search results, for example if other pages link to it.

Read that twice if you have ever done it. The belt and braces approach produces the opposite of the intended result, and it fails silently, which is the worst combination. If you want a page out of results, let the crawler reach it so it can read the instruction you left.

What about unpublishing rather than deleting?

It is the reversible option, and on a CMS it is usually the right first move. Deleting an item destroys the content. Unpublishing takes it off the live site while the record survives, which means a decision you regret costs you a click rather than a rewrite.

My rule is to unpublish first, wait a cycle, and only delete when I am certain. Content decisions made in a pruning session have a habit of looking different a month later, particularly when somebody emails asking where an article went.

What you should not assume is what your platform does to the URL when you unpublish or delete, because that varies and it is worth knowing rather than guessing. Check Webflow's own documentation for the behaviour on your setup, and then do the thing that settles it definitively: load the old URL in a private window and see what actually comes back.

How do you decide across a hundred posts rather than one?

By writing rules rather than making a hundred judgements, because a hundred judgements is how a pruning project dies halfway through. Sort your list into three buckets and let the bucket decide.

Bucket one is merged into something specific, which gets a permanent redirect to that specific page. Bucket two is genuinely obsolete with no successor, which gets a 404 and a good 404 page. Bucket three is still useful to somebody but not worth surfacing, which gets unpublished or noindexed and left alone.

Do the sorting in a spreadsheet with the old URL, the bucket, and the target where one exists, then execute the whole batch from that sheet. It is the same discipline as auditing and pruning low performing posts, and it pairs with the structural work I described in crawl depth on a large blog, because every removal changes the link graph you just finished mapping.

What should you do next?

Before you delete anything, find out what currently links to it. Internal links are the ones you can fix and the ones you will otherwise forget, and a post removed without updating the posts that reference it leaves broken links in articles you still care about.

Then pick the bucket, write the rule down, and check the live URL after you execute rather than trusting the interface. A redirect that exists in a settings panel and not on the live site is a fairly common and entirely invisible failure.

And if you are looking at a large archive you know needs thinning and you would rather not guess at the URL decisions, reach out. Sorting the list is usually quick once someone has done it before.