On an ordinary public website, the user's profile is always publicly visible to all visitors (such as Stack Overflow), where they can limit certain pieces of information via privacy settings or just removing the information. Now the user has decided to delete their account (in my case deactivate) so that their account doesn't technically "exist" anymore. The way my system is set up, when their account is deactivated, their username for any content connected to them just becomes "Anonymous User" as if it were a guest that posted.

I feel like this could cause some confusion for other users. I'm also concerned about what kind of error to display when someone attempts to view their profile page. My gut tells me to just display a standard 404 page to hide the fact that they ever existed, but then you also have to consider that, since usernames must be unique, anyone can go to the register page and type in the username to see if it really exists or not.

I have a similar problem with another website, which gives users the ability to hide their profiles from the public and only allow registered users to view it. Again it's with the dilemma of what kind of error message to display when an unregistered users attempts to view their profile with invalid permissions.

So, would it be acceptable to display basic errors such as "user has been deactivated" or "you must be logged in to view this profile" in order to give other visitors some idea of why the page can't be displayed, or should I attempt to cover the user's privacy a little and just display a standard 404 without indicating in any way that the user might exist? Are there any other issues that I'm not realizing about either route?

To go back to the beginning, should I even bother changing the user's name to "Anonymous User" when their account is deactivated? Would it be acceptable to just display a non-linked version of their username in place of the normal linked display name?

3 Answers 3


I would not go with a 404 page. A 404 page is not just page, but also a response. It lets the client know that the page was not found. That it was somehow deleted or the url is wrong.

If you are using some sort of session to hide information that is availabe only to logged in users, then you can use your server side scripting language of choice, (asp, coldfusion, jsp, php) to display the page according to the session's rights to view information.

If a profile has been deleted, do not delete it from your datastore. Instead add a column for isdeleted and check it yes. When someone reaches a delete profile then simply have your site generate the user is no longer on our system, and give them some more options. Example, someone closes their dating profile on a dating site, but you suggest other matches.

It is very important not to delete data. Say a user deletes, then comes back 6 months later. Storing their profile gives you the ability to get back users you lost through email campaigns and more. I dont think even facebook actually deletes your profile.

Make sure your terms state how long you will store this information before it is purged and deleted permanently.


I wouldn't publicly state an account was deactivated or deleted. A notice as you said "you must be logged in to view this profile" is good or "You do not have permission to view this content", or "You must be logged in to view this content". Something generic along those lines


I've found a decent way to conquer all these different issues with a single message. Simply displaying a generic message such as "You can't view this page" will solve the privacy issues, but not the confusion. So, I'm also going to list out all the possible reasons for receiving the error. It would go something like this:

There was a problem displaying this page to you.

Possible reasons:

  • The user specified does not exist in our system.

  • The user does not allow anonymous users to view their profile.

  • The user has deactivated their account.

Since it also covers the cases for the user not existing to begin with, there's no way for a user viewing that page to know if the user did exist or not (unless they knew they existed prior). If they were expecting the user to exist, it suggests the alternatives for why they don't.

The problem with this is it combines three status codes:

  • 401 Unauthorized for "Must Login to See"

  • 403 Forbidden for "User Deactivated"

  • 404 Not Found for "User Never Existed"

Since using a 401 or 403 would make absolutely no sense for the other two (respectively), I'm going to stick to a 404 status code. Sending a 200 OK response is absolutely unacceptable because it allows search engines to freely cache the page because they think it's an actual page. As well, if a user previously existed and is cached, it will cause even more confusion. Sending a 404 will hopefully encourage search engines to clear the cache they have to erase the history of that user (if they deactivated their account or later decided to make it private). As per its description:

The requested resource could not be found but may be available again in the future. Subsequent requests by the client are permissible.

Even though the page may be technically "found", it's the closest thing. It will properly indicate that the page requested doesn't exist, at least for the moment, but doesn't forbid them from continuing to make requests in the future to check on its existence.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.