wordpressmike
Forum Replies Created
-
@arnaudbroes I appreciate your attention to this.
FYI: I searched Google for web sites that are part of the spam ( goo/678 DOT com and tbr/11 DOT com- delete the slashes and add .com).
It appears there are a number of prominent web sites using All in One SEO that are the targets of these spam attacks, though at least one site was using a different SEO tool.
Thanks @andrew1977. I was able to comment out the code I added to the functions.php and check the “no” box for “show in search results” under search appearance –> Search Page.
That resulted in the following: meta tag for. So adding code doesn’t seem necessary.
<meta name="robots" content="noindex, max-snippet:-1, max-image-preview:large, max-video-preview:-1" />Also, I noticed that clicking “Use Default Settings” under the “Advanced” tab reverts the setting back to “yes”.
Another thing is that the above meta robots tag lacks “follow” and there doesn’t appear to be a way to add it. I’m unsure if the “follow” is necessary or not.
Google’s documentation says:
By default, Googlebot will index a page and follow links to it. So there’s no need to tag pages with content values of
indexorfollow.- This reply was modified 3 years, 4 months ago by wordpressmike.
- This reply was modified 3 years, 4 months ago by wordpressmike.
- This reply was modified 3 years, 4 months ago by wordpressmike.
@andrew1977, I basically combined the code from the original wordpress core work with the All in One SEO documentation.
You’ll see that it only sets noindex if
is_search()is true. So yes, it’s only for search. (see is_search() documentation)I couldn’t figure out @arnaudbroes’s instructions.
Apparently this spam vulnerability was fixed long ago in WordPress core but All in One SEO plugin is reverting the desired behavior.
I noticed I’m getting the spam today, for the first time. So maybe this is a new bug.
Using the All in One SEO documentation, I was able to add the following to my functions.php file, which I think should solve the problem until it can be fixed in the main plugin:
add_filter( 'aioseo_robots_meta', 'aioseo_filter_robots_meta' ); function aioseo_filter_robots_meta( $attributes ) { if ( is_search() ) { $attributes['noindex'] = 'noindex'; $attributes['nofollow'] = 'follow'; } return $attributes; }Forum: Plugins
In reply to: [BulletProof Security] Linkchecker and other legit bots are brokenWow that is an amazing analysis.
Forum: Plugins
In reply to: [BulletProof Security] Linkchecker and other legit bots are brokenI don’t think the solution should be to continue to block Facebook but not log the blocking. That sounds like a recipe for trouble.
Forum: Plugins
In reply to: [BulletProof Security] Linkchecker and other legit bots are brokenMy development install that I can do rewrite logging on doesn’t have traffic from facebook, so I can’t help with logs.
Forum: Plugins
In reply to: [BulletProof Security] Linkchecker and other legit bots are brokenFrom the rewrite log, do you know which line of the htaccess file is causing the 403 redirect?
Forum: Plugins
In reply to: [BulletProof Security] Linkchecker and other legit bots are brokenAre you familiar with rewrite logging? I can try to get you a rewrite log this weekend.
Forum: Plugins
In reply to: [BulletProof Security] Linkchecker and other legit bots are brokenOk I’ve run my other site for about 12 hours with Bulletproof turned on, except for HEAD removed.
I’m still encountering the Facebook problem and am also seeing that it looks like wordpress has been blocking itself- See the following, which has been anonymized.
Any progress?
>>>>>>>>>>> 403 Error Logged – February 7, 2013 – 11:05 pm <<<<<<<<<<<
REMOTE_ADDR: 123.123.123.123
Host Name: myserver.myhost.com
HTTP_CLIENT_IP:
HTTP_FORWARDED:
HTTP_X_FORWARDED_FOR:
HTTP_X_CLUSTER_CLIENT_IP:
REQUEST_METHOD: GET
HTTP_REFERER:
REQUEST_URI: /wp-admin/post-new.php
QUERY_STRING:
HTTP_USER_AGENT: WordPress/3.5.1; http://www.mydomain.comFacebook problem:
>>>>>>>>>>> 403 Error Logged – February 8, 2013 – 12:05 pm <<<<<<<<<<<
REMOTE_ADDR: 173.252.110.112
Host Name: 173.252.110.112
HTTP_CLIENT_IP:
HTTP_FORWARDED:
HTTP_X_FORWARDED_FOR:
HTTP_X_CLUSTER_CLIENT_IP:
REQUEST_METHOD: GET
HTTP_REFERER:
REQUEST_URI: /wp-content/uploads/2011/08/icon.gif
QUERY_STRING:
HTTP_USER_AGENT: facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)Forum: Plugins
In reply to: [BulletProof Security] Linkchecker and other legit bots are brokenI wonder if facebook falls back to GET if HEAD fails- Thus we’d record a block but also one would be passed through.
Forum: Plugins
In reply to: [BulletProof Security] Linkchecker and other legit bots are brokenI’d be curious to know if the facebook problem stops if HEAD is removed- I will hopefully be testing this later tonight.
Forum: Plugins
In reply to: [BulletProof Security] Linkchecker and other legit bots are brokenSide note re caching plugins- I’d love to use one but I had problems with certain dynamic content.
Forum: Plugins
In reply to: [BulletProof Security] Linkchecker and other legit bots are brokenIt looks like the broken link checker plugin is indeed using HEAD requests- I haven’t had a 403 error since removing HEAD checking-
If the log incorrectly characterizes a HEAD as a GET, then that’s a problem- Really was a head scratcher.
this is from broken-link-checker/modules/checkers/http.php
if ( $nobody ){ //If possible, use HEAD requests for speed. curl_setopt($ch, CURLOPT_NOBODY, true); } else { //If we must use GET at least limit the amount of downloaded data. curl_setopt($ch, CURLOPT_HTTPHEADER, array('Range: bytes=0-2048')); //2 KB }Forum: Plugins
In reply to: [BulletProof Security] Linkchecker and other legit bots are brokenNo caching plugins.