Removing a Guest Post: 404, 410 or 301

Taking down a guest post comes down to one question: does a page exist that serves the same reader need? If yes, a permanent redirect (301) to that page. If no, let the URL return 404 or 410. The choice between 404 and 410 matters far less than people expect, because Google's documentation treats them alike. What does matter is telling the author before the post disappears and cleaning up every place on your site that still points to it.

If you run a blog that publishes contributed articles, you are the target reader. The advice below separates the technical choice from the editorial one, because a retired guest post has an author, an agreement and possibly links from other sites, none of which a product page has.

How Google reads the status codes

Google's page on HTTP status codes and network errors (Opens in a new tab) states that all 4xx errors except 429 are treated the same. A URL that was in the index and returns a 4xx is removed from the index, and crawling of it gradually decreases. The page does not give 404 and 410 different behavior. A claim that 410 removes a page faster than 404 therefore does not come from this documentation.

The same page describes the soft 404: a response with a 2xx status whose content looks like an error, which Search Console can flag. If you take down a post, do not show a "not found" message on a page that answers 200. Return a real 4xx. Our article on soft 404 errors and how to fix them shows how to find these.

Choosing 404 or 410

The difference between 404 and 410 is in what you communicate, not in what Google does. A 410 says the page was removed on purpose. A 404 says it was not found. Practical suggestion: if your platform returns 410 easily, use it for deliberate removals and write down your rule. If it only returns 404, that is not a flaw. Consistency across removals is the point.

Status codes side by side

Google's removal guidance (Opens in a new tab) adds context. The Removals tool can take a page out of results within about a day, but the effect lasts around six months, so it is not permanent on its own. A noindex tag keeps a page out of Google results while it stays available to visitors. All of these statements can change, so check the current pages before relying on them.

When a permanent redirect fits

Google's redirects documentation (Opens in a new tab) says to use permanent redirects when you are sure the redirect will not be reverted. Googlebot follows them and treats the target as the canonical URL. The page lists removing a page and merging URLs among the situations for a permanent redirect, prefers server-side redirects, and names 301 and 308 as permanent codes. It does not say how long a redirect must stay in place and does not directly address redirecting to an unrelated page.

Why the target must be relevant

The documentation is silent on unrelated targets, but the practical reasoning is simple. A redirect exists for the reader. Sending someone who wanted a guide to email subject lines to your home page tells them nothing. If no related page exists, a 404 or 410 is the more honest result.

Keeping redirects tidy

• The target covers the same subject.
• The redirect reaches the target in one hop, with no chain or loop.
• The target itself returns 200.
• Internal links are updated to the new address instead of relying on the redirect.

For chains and loops, see redirect chains and loops: how to fix them. For the broader picture of codes, our HTTP status codes guide is a useful companion.

What the visitor sees at the old address

Whatever you choose, some visitors will still arrive at the old URL, from a bookmark, a newsletter or another site. What they see in that moment is part of your editorial quality.

With a redirect in place

The reader lands on the replacement. Make sure its opening lines make clear that it covers the subject they were looking for. A reader who clicked a title about one thing and lands on a page about another will leave.

With a 404 or 410

The reader sees your error page. A useful one says in plain words that the page is no longer available, offers a search box and points to the main sections of the site. It must still answer with a 4xx status. A friendly error page that answers 200 would be a soft 404, the very problem described earlier.

With noindex and the page still open

The reader sees the full post. Consider adding a short banner when the reason for noindex is that the content is outdated, so that nobody mistakes it for current advice. The noindex tag only affects search results, and the visible text of the post stays exactly as it was.

Choosing the method at a glance

The rule in short

Decision rule: replacement exists, use 301. No replacement, use 404 or 410. Page must stay reachable but leave search, use noindex. Only one paragraph is the trouble, edit instead of removing. Whatever you pick, never serve a 200 page that says "not found".

Questions before the removal

Retiring a post is easy to do and annoying to undo. Work through these questions first.

1. What is the real reason: a factual error, a policy breach, a withdrawn byline, a lost source or plain upkeep cost?
2. Can an edit solve it?
3. Is there a related page where the reader would want to land?
4. Which pages on your site, and which other sites, link here?
5. Has the author been told, and do they want the text back?

The first two questions decide whether removal is needed at all. The third picks the technical route. The fourth shows the cleanup list. The fifth protects the relationship.

Cases where a rewrite is enough

One wrong paragraph, one dead link or one outdated screenshot does not justify taking a post down. Fix it with the author, add an update note and keep the URL. Removal fits when the whole piece rests on wrong claims, breaches your policy or has been withdrawn by its author.

Options short of removal

Retiring is the last resort. Keep the others in the log as options, because one reason can be solved in more than one way.

Rewriting

When the subject is still valuable but the text has weakened, offer the author a rewrite. The URL stays, the log updates and the relationship survives.

Merging

If two similar posts split one topic, improve the stronger one and redirect the other to it with a 301. Record the rationale and the authors of both.

Keeping the post, changing the link

If the trouble is a single link, deleting the whole post is out of proportion. Changing the attribute or removing the link may be enough, which is a separate process.

Retiring many posts at once

When many posts go at once, plan the batch: list every URL with reason, replacement and method, group them by method, notify authors with their own lists, deploy the change in one window and sample the result. Practical suggestion: test redirect rules on a small sample first, because one badly written pattern can redirect pages you meant to keep.

When to hold off

Not every removal should happen the same day. In some situations a short delay produces a better result.

• The author has objected or asked for an explanation and a reply is pending.
• The replacement page is not live yet. Publish the target first, then set the redirect.
• Many pages on your site link to the post. Plan the link updates before the URL changes.
• The person who writes redirect rules is unavailable. A faulty rule can cause more trouble than the removal itself.

Google's redirects documentation prefers permanent server-side redirects and includes implementation examples for PHP, Apache and NGINX. Have someone who knows your server environment apply the change. Once it is live, open the old URL in a browser and in a header checker and confirm that it answers with 301.

Trying a rule on a sample first

Practical suggestion: for a batch, test the rule on two or three URLs that should redirect and two or three that should not. Check that a retired post reaches its target in one hop, that a live post is untouched and that the target itself answers 200. A rule that is wrong in the first direction sends readers to the wrong page; a rule that is wrong in the second direction takes live pages offline.

Messier removals and how to handle them

The author's site no longer exists

You cannot deliver a notice to a dead domain. Record the attempts you made, the dates and the channels, then act under the written policy. Do not wait indefinitely for a reply that cannot come.

Part of the post is still useful

If one section answers a real question, move it into an existing page that serves the same reader, and redirect only if that page does the job. If no such page exists, return 410 and keep the useful section for a future piece.

The post carried a sponsored link

Removing the post does not change what you promised the sponsor. Check the agreement, note the rel value that was in place and the dates, and tell the sponsor before the change goes live.

Two people claim the text

Freeze edits, ask both for evidence and decide from the publishing agreement, not from who writes the louder email. Record the outcome in the same row as the removal.

Writing to the author

The technical decision comes first, the notice follows, and the timing of that notice shapes the relationship. News that arrives after the removal feels like a surprise. Practical suggestion: write before the post comes down.

What the notice contains

• The URL and publication date
• The reason, tied to a written policy
• The method (redirect, 404 or 410) and the target if there is one
• The date it takes effect
• Whether the author wants the text back, and how long they have to say so
• A reply address that is monitored

Rights in the text depend on your agreement, and nothing here makes a claim about ownership. If it is unclear, offer to return the text and ask. Google's documentation says nothing about how long to give an author, so notice periods are a matter of your own policy. For non-urgent removals, allow time for the author to make plans and put the date in writing. For urgent cases such as wrong information or a policy breach, the period can be shorter, but the notice still comes before removal.

A notice you can adapt

Hello, we are retiring "[title]" on [date]. Reason: [policy-based reason]. The page will [redirect to the updated page / no longer be available]. If you would like to publish the text elsewhere, reply by [date] and we will send you the file.

Avoid language that belittles the work. "No longer matches current sources" is a statement you can check; "poor quality" is a judgment that starts arguments. If the reason cannot be tied to a written rule, reconsider the removal.

Cleaning up after the removal

Removal takes a click, but its consequences travel around the site. Clean up in this order.

1. Open the old URL and confirm it returns the response you intended.
2. Take the URL out of the sitemap, because that is where you list the URLs you want to appear in results.
3. Find and fix or remove internal links to the old URL.
4. Check category, tag and author archives, related-post boxes and the home page.
5. Look at the URL in Search Console a few days later.
6. Update the log with date, method, reason and notice date.

Where traces of the post linger

Google's sitemap documentation (Opens in a new tab) says to include the URLs you want to appear in search results, and calls submitting a sitemap merely a hint that Google may not use for crawling. A retired URL has no place on that list. Links from other sites to the retired post stay outside your control. With a redirect they resolve to the replacement; without one, visitors meet a 4xx page. A custom 4xx page with a search box and links to main sections can help visitors, as long as the HTTP status stays 4xx.

A check timetable after the removal

A removal is not finished when the status code is right. You also have to show that the old address is not alive anywhere else on the site. The documentation sets no timetable for these checks, so the intervals below are a practical suggestion.

If a check fails, fix the cause and add a line to the log. A check that fails twice for the same reason points to a gap in the procedure, so fix the written checklist rather than the single page.

Keeping a removal record

A removal happens once, but its record helps for years. If a similar pitch arrives or a reader asks about an old address, the record answers in seconds.

Fields worth recording

• Removed URL, publication date and removal date
• Author name, the date and channel of the notice
• Reason and the written rule behind it
• Method chosen: 301, 404, 410 or noindex
• Redirect target, if any, and why it counts as relevant
• Places cleaned: sitemap, internal links, archives, author page
• Date and result of the post-removal check

Patterns the record reveals

Group the reasons after a while and patterns appear. Many removals caused by vanished sources suggest adding a step before publication that asks whether a cited source is likely to stay online. Many removals requested by authors suggest the publishing agreement does not match what authors expect. A record also supports fairness: when a similar pitch comes in, you can review earlier decisions, but the new pitch is judged on its own merits.

Example scenario: two posts, two outcomes

Example scenario: a personal finance blog retires two guest posts in the same week. The first describes a promotion that has ended, and the site has a current page on the same subject. The second praises a service that has closed, and nothing on the site covers it.

For the first, the editor sets a 301 to the current page, emails the author with the new address and updates internal links. For the second, no replacement exists, so the URL returns 410, leaves the sitemap and the category list, and the author is told they can take the text back. The two decisions sit in the log as separate rows with reason, method and dates. What decided the method was not how good the post was, but whether a replacement existed.

Pre-close checklist

1. Did you write the reason and try an edit first?
2. Is there a relevant replacement page?
3. Is the method chosen and recorded?
4. Was the author told before removal?
5. Does the old URL return the intended code?
6. Are the sitemap, internal links, archives and author pages updated?
7. Is there no soft 404?
8. Is the log complete?

Frequently Asked Questions

Is there a difference between 404 and 410 for Google?

Google's status code page says all 4xx errors except 429 are treated the same. It describes no separate behavior for 404 and 410. The choice is about consistency and what your platform supports.

Can I redirect a retired post to my home page?

Google's redirect page does not address irrelevant targets directly. Practical suggestion: redirect only to a page that covers the same subject; otherwise return 404 or 410.

Should I tell the author before or after?

Practical suggestion: before. Include the URL, reason, method, date and the option to take the text back.

Does noindex replace removal?

No. According to Google's removal page, noindex keeps a page out of Google results but the page stays available to visitors.

Is the Removals tool enough?

Per Google's documentation it can take a page out of results within about a day, but the effect lasts around six months, so a permanent method is still required.

How long should a redirect stay?

Google's redirect page gives no duration. Practical suggestion: keep it as long as pages or visitors still use the old address.

Conclusion

When you retire a guest post, ask first whether an edit would do, then whether a page exists that serves the same reader. Use a 301 when it does, a 404 or 410 when it does not, and noindex only when the page must stay reachable. Because Google treats 4xx codes alike, consistency matters more than the number. Tell the author in advance, clean the sitemap, internal links and archives, and log the decision with its reason.

If you want guest post placements backed by clear editorial records and ongoing upkeep, see our guest post service.