I'm having an issue with a particularly persistent unwantable that continues to use free email accounts and anonymous proxies to register new accounts every time we ban him. There's a seemingly endless availabiliyt of these IP's, so there doesn't seem to be a feasible way to block him permanently.
Anyone deal with the same issue before? If so, how did you solve it?
Hey I just noticed there's a /cache folder that contains a few years worth of seemingly worthless files. Most of them are labeled "sphinx_error_blah blah blah". Can I just delete these or do they serve some purpose? Is there an interface in the admin tool to clean out these old files?
77 pages of posts! Reason enough not to read through everything. So I'll ask the question that probably has already been answered: I'm using the 2.0 version, now things are all wonky (markers in the wrong place, some members getting blank pages, others not seeing markers, etc) - it's all due the Google maps issue. So, question is, when will a new version be available that fixes all this? (not beta, but release version)
If you think someting in your robots.txt file is causing 403 errors, then that's a strong signal you shouldn't be editing your robots.txt file. :)
The most likely scenario is you've blocked guests from viewing member profiles. In this instance the 403 errors are simply from the bots trying to "see" those links when they don't have permission to do so - hence the 403 response code.
Keep in mind that reported errors in GWT isn't necessarily a bad thing. If you've blocked guests from viewing some pages, then naturally you'll have 403 errors. Those are expected. I wouldn't worry about them.
Now before you guys get on your soapboxes and proclaim those will hurt your rankings, get out of your wayback machine and step up to 2013. Years ago, an exessive amount of errors would hurt your rankings. But now, Google and Bing are pretty smart. They know that sometimes "errors" are normal and expected, as part of the user experience. In the case of blocking guests from viewing profiles, 403 response codes are the correct response when trying to view profiles as a guest, and therefore, aren't "errors", meaning you won't get dinged. Instead, they view that as a properly configured site.
Bottom line, don't spend time chasing these "errors" for the sake of Google and Bing. It won't help or hinder your rankings.
But if seeing those 403's in GWT is annoying to you, and you want clean up your reports, then you could block the member's directory via robots.txt. But you need to know what you're doing, plus keep in mind it won't have any impact on your rankings. Depending on how many members you have, it MIGHT save a little on bandwidth and server resources because crawlers won't be wasting time hitting those 403's, but really all it will do is visually clean up your GWT reports.
You will not get any penalties or have any issues from the search engines, as a few folks believe above.
Showing content that ONLY the search engines can see is considered cloaking. If you're just showing content differently for different users - either via logged in states or via cookies - and allowing the bots to see one of them, that's fine.
It's all about intent. If a person is trying to game the search engines by showing them something different (presumably to give them higher rankings) than what visitors will EVER see, then that's cloaking. But showing different views based upon logged in status, then that's designed for user engagement; and search engines don't have an issue with that.
The key is that you're showing content to the search engines that human visitors can also see.
Again, cloaking is creating and displaying content that nobody will see except the search engines.
That said, in my opinion, it's not a good user experience to entice a user from a search engine who's expecting one thing and gets another. That's just a recipe for a high bounce rate and no return visitors. That, in turn, could potentially lower your search traffic (bounce rate is one of the many "signals" search engines use for ranking).