: Is making a catch-all page for HTTP status 410 errors practical? I run a website with photo galleries. Each photo gallery contains at least 100 to 500 photos on their own individual pages and
I run a website with photo galleries. Each photo gallery contains at least 100 to 500 photos on their own individual pages and If I delete a gallery then without creating any special configuration, Google Webmaster Tools will naturally print out 404 status codes about the pages related to the gallery I deleted in the crawl errors section. If I delete a few photo galleries then that's well over 1,000 links that will become 404's, and I'll have to wait at least 24 hours to deal with all of them since Google only allows me to see up to 1,000 links at a time.
I would like to know which of these approaches are better to handle the problem:
Do I Map error URL's to one central page?
Currently, I map all non-existing URLs that I don't plan to have exist in the future to a common URL which returns an HTTP 410 error page. The upside to this is that I won't have to wait weeks for Google to list every individual page, but the drawback is that the common error page keeps reappearing in the crawl errors even tho I indicated to Google that I fixed the error and another drawback is minor performance hits by literally redirecting guests from the error URL to the common error page.
Or do I just issue errors as they happen?
My other option is to forget about the common page and when a URL is a problem URL, then just show the default status 410 error page instead of redirecting URLs to a URL that represents the error page. The upside to this is that the server takes less of a performance hit, but for every URL that results in an error, Google will print it in the crawl errors section of Webmaster tools, and waiting weeks just to clear errors with HTTP status 410 is a waste of time.
My question is which approach is better and why?
I'm not asking for opinions here. I'm asking for an answer that would give me an overall positive impact (including adsense income).
More posts by @Harper822
1 Comments
Sorted by latest first Latest Oldest Best
You are half way there.
I would suggest that any page that does not exist should error out.
I have a "removed" page that issues a 404 and any page that is deleted would 301 redirect any deleted page to the "removed" page. But in the end, I found that it was far better if the page I deleted would 404 without the 301. I changed this a bit, and please know this is a bit of trickery, any page that is deleted page would still return the "removed" page and issue a 404 without the 301. There is no real problem with this except that Google keeps the page in the index. So instead, I just let the deleted page just 404- not from code, but though Apache natively. This is much better.
I was researching lately why I still get a ton of search traffic for pages I deleted over a year ago. Oh! I still show the "removed" page for these with a 404. Google handled the native 404's just fine removing 280,000 pages from the index, but these two remaining pages still exist in the search index. So I will fix this problem by deleting the alias allowing Apache to issue the 404 natively as it would have without intervention.
Issuing a 410 is superior to a 404. Either error is far better if your web server serves the error. A 404 is fine, but takes a number of attempts before Google treats the error as a 410.
Your biggest mistake is "marking as fixed" any 404 or 401 error. Google is confusing people left and right on this.
Do not fix any 404 or 410 error that is not a mistake. You are telling Google that these pages should exist and that they should try again. The error notice in Google Webmaster Tools will continue to reappear as long as you "mark as fixed" a situation which is actually what you want. Please know that not everything you see in this list is really a problem. If you delete a page and Google tells you the page does not exist, you should be saying "No **** Sherlock!" and move on.
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.