Comment on Stallion Responsive WordPress SEO Theme by SEO Dave.

Stallion WordPress SEO Package The Stallion Responsive WordPress SEO Package version 8.1 is almost ready for release. Had it ready a week ago, but as I triple checked new features found performance issues I wasn’t happy with and fixed them, think I’m done now, so will test on some of my domains for another week and if no issues release the update.

Checkout the latest Google Pagespeed Insights Tools results for this domain:

Mobile User Experience: 99/100
Mobile Speed: 88/100
Desktop Speed 95/100

Happy with these results because most of the issues are not on the site per se, they are related to social media like buttons. Main issue I have control over is “Eliminate render-blocking JavaScript and CSS in above-the-fold content”. It’s one css file (would be three without a minify plugin like W3 Total Cache) and though in theory could take out the important CSS rules and have them inline and load the not so important CSS files in the footer, it would be serious overkill for the gain.

It’s interesting on desktop I have 5 issues and loose 5 points, on mobile I have 6 issues (one additional image issue due to a resized image) and loose 12 points. Looks like on Desktop for each issue you loose one point, but on mobile it’s two points for each issue. Other than the image optimization issue, the pagespeed issues of Desktop and Mobile are identical. I suppose it makes sense with mobile devices bandwidth could be more limited meaning page speed is more important: twice as important according to Google :-)

Further improvements would mean turning off social media like buttons, think that would get me:

Mobile User Experience: 100/100
Mobile Speed: 96/100
Desktop Speed 99/100

Hmm, or maybe not look at which has no social buttons (archive part of site)

Mobile User Experience: 100/100
Mobile Speed: 91/100
Desktop Speed 97/100

Have the same two issues for mobile and Desktop which account for 9 points for mobile and 3 for desktop.

Makes even less sense now!!!

Far from an extensive list of improvements this week.

Stallion Photo Navigation Menu no longer uses javascript, the accordion style image menu used to require two javascript files (mootools js files) for the sliding effect, have rebuilt the feature using CSS styles to output an almost identical feature. See an example at it’s the photo menu near the top, only change is it’s a little wider and I removed a right border from the image bit.

The SEO performance benefit of the new code is no need to download two javascript files sitewide for a fancy image menu. Overall a saving of around 37KB no longer downloaded and the two calls to get the resources. Overall faster site speed. Also smoother sliding as device width decreases, before if you flipped a mobile phone to landscape view because the width was set using javascript it ideally needed a page refresh, now it doesn’t.

Had performance problems with Akismet 3 recently, they added the need to use Jquery for their SPAM honeypot! Also because I run over 100 domains my Akismet IDs (the free ones) kept getting cancelled, dealing with too much comment SPAM, so was a pain having to get new Akismet IDs and add them to dozens of domains! Not been running Akismet on this domain for about a month (just using Stallion), the site can see around 1,000 SPAM comments a day and Stallion is marking almost all of them SPAM (correctly, not had a false positive yet). With Stallion responsive 8.1 no longer need Akismet or any other comment SPAM plugins.

Stallion includes 5 SPAM protection measures:

1 – HTTP_REFERER check.
2 – Adds a nonce to stop comments being submitted remotely.
3 – Two SPAM HoneyPots, these are form fields real users can’t add content to, but bots tend to fill them tripping the SPAM honeypot. Thinking about adding the option for webmasters to set the name of the honeypot fields so even more likely not to be avoided by SPAM bots: spammers can avoid a honeypot if the spammer knows the hidden field name so they can set their bot not to add content to it. Giving webmaster the option to periodically rename them means if a bot avoids the pot it can be renamed, would be even better to rename it randomly (just had an idea :-)).
4 – SPAMMERS tend to post long URLs in the author URL box, if a URL is longer than X characters (you set X: default 60) it’s marked SPAM.
5 – 10 duplicate field checks, if a SPAM bot adds the same content to two fields it’s marked SPAM.

Had the last idea recently (not seen this SPAM blocking concept used before) because comment SPAM bots tend to copy the author URL field into the Stallion comment title field. When I see a URL as the comment title it’s always SPAM, so made sense to add a check for when content is used more than once in two or more comment form fields. Added 10 checks which covers everything possible, if the author URL is all that’s copied onto the main comment text it’s SPAM.

Should only leave manual SPAM comments, not much you can do to block them without using a service like Akismet that maintains a database of email addresses that’s had other users mark it as a SPAMMER. Problem with this approach is you’ll find in a niche like Internet marketing real commenter’s who aren’t SPAMMING are false positives.

WordPress core has a minor SEO issue with the reply to comment links: partially my fault, it was my suggestion that resulted in WordPress core removing the rel=”nofollow” attribute from the reply to comment links that resulted in this minor SEO issue :-)

The SEO issue is the reply to comment link URLs that are generated when a Reply to Comment link is clicked


are indexed by Google. There’s a correctly set canonical URL that let’s Google know the correct URL for indexing is


but you will still find in Google Webmaster Tools URLs listed with the above type of URL (under Crawl >> URL Parameters) and some indexed in Google. Pop the code below in a Google search:

site: ?replytocom=

Although it’s not causing SEO damage, Google is transferring the SEO benefit to the main URL it’s been irritating me, so have made a fix. Stallion for years has used form buttons for login links and comment author URL links for SEO reasons, have used the same SEO code for the Reply to Comment links. With Stallion 8.1 Google won’t ‘see’ the replytocom URL because it will be part of a form button and Google doesn’t treat them as links. Will take some time, but the currently indexed ?replytocom= links (Webmaster Tools says I have over 8,000 links with that parameter!) indexed will reduce since Google won’t have the links to reindex.

There’s also quite a big SEO benefit to this new feature, before the Reply to Comment links had anchor text “Reply to Comment” which isn’t very helpful SEO wise, now the button ‘links’ have a button with text “Reply to Comment”, but it’s not anchor text so doesn’t have any major SEO value: like everything on a page there’s an SEO impact, but now it’s insignificant.

While working on this code found I’d missed a rel=”nofollow” attribute (thought I removed them all). If you have comment posting only available to logged in users (so only those who register can comment) Google was getting a nofollow link to the register to comment link on every comment (not good!). Since it didn’t make sense to have a “Register to Reply” link on every comment removed the link completely leaving the one link where the comment form would be to register (that’s not nofollow): so users still have a route to register, just not dozens of links saying register to comment.

Added Pinterest verification option on the Stallion Promotions page and added a register any webmaster like service that uses a meta tag to verify. The Russian search engine Yandex for example uses a meta tag to verify, pop their meta tag in the Stallion “Full Verification Meta Tags” form and the meta tag will be added to the head of the home page only. Any service that uses a meta tag verify tag can be verified easily.

Been working on a lot of features I’ve not mentioned previously, so have fun when I release Stallion 8.1.

BTW been developing in WordPress 4 beta 2 (nightly cutting edge builds) and WordPress 3.9.1 which just updated to WordPress 3.9.2 and not had any issues, don’t see any issues when WordPress 4.0 is released, but you never know for sure until it’s actually released.