Follow me: @D_mitar

Most read posts recently



Jul 28th 2010 × using mootools pseudo selectors to SEO check for hidden page elements

This is an interesting one. Basically, there’s a school of thought in SEO that says, you should not apply a display: none CSS property to elements without a valid reason. By valid, it is understood that the hidden content it is somehow interacting with the user based upon events. For example, flyout / foldout menu systems, mouse tips and so forth are acceptable. Hidden text for the purposes of increasing keyword density and SEO relevance is NOT ok.

There are some sites that claim to check what is detectable and what is not but the bottom line is, only one thing will give you a 100% guarantee and control over what your page is hiding and that is reading it from the DOM directly.

I wrote a little snippet through mootools (as all my sites use mootools) that uses a pseudo selector to search for particular style settings.

*UPDATE* if you found this through some SEO tag/search, you should know that this will only work on pages that utilise the mootools javascript framework (link is on the right handside) and in a browser with a console (chrome, safari or firefox with the firebug plugin). With my “usual” type of readers being web developers, I tend to take this for granted.

// for mootools 1.2
Selectors.Pseudo.style = function(key) {
    var styles = key.split("=");
    return styles.length == 2 && this.getStyle(styles[0]) == styles[1];
};

// output all elements with display: none to console
$(document.body).getElements(":style(display=none)");

Just open your page, open up firebug and the larger command line console and paste (or make a bookmarklet).

Neat or not? You can also look for visibility: hidden or other tricks you can think of (positioning and so forth may need some changes to the code).

note: for mootools 1.3 and slick (still in beta), you need to change this to:

Slick.definePseudo('style', function(key) {
    var styles = key.split("=");
    return styles.length == 2 && this.getStyle(styles[0]) == styles[1];
});

I hope it helps you – it’s a useful trick anyway, you can use this to select all elements with color: red, for example.


Jun 3rd 2010 × beware: googlebot understands javascript, mootools and ajax now

This came as a complete shock to me: due to the Google Mayday update, I have been monitoring how the bot accesses our sites in a futile search for clues as to the page rankings changes. Very surprised to discover googlebot fetching URLs that are _strictly_ available through Ajax only.

Here is a sample request from earlier today that fetched a small worker thread that produces additional product images:

66.249.65.25 - - [03/Jun/2010:11:25:43 +0100] "GET /angles.php?id=102257&version=Brown HTTP/1.1" 200 801 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

We have all spoken of Google’s increased capability of following and deciphering javascript logic but it goes beyond the scope of reasonable effort, in my opinion. Is the scraping done based upon URLs detected in the javascript blocks or does it actually evaluate, run and monitor the calls? If the scraping works based upon regex that catches URLs, would obfuscation / base64 encoding help? Does googlebot support XHR via POST or only via GET? Too many questions without an answer at this point, I will update this post as more info becomes available to me.

Such fetches can often be undesirable–certain AJAX calls we do are tied in with sessions and can cause errors / notifications when being requested w/o due cause, session or event. I am currently trying to find if there is a plausible way to apply a “nofollow” to such calls at all that does not involve a lot of editing and blocking of googlebot from any scripts that it has no place reading. If it comes to it, I will revert all ajax handling to a /xhr/ folder and disallow it in robots.txt, wonder what the best practice is…

As for the Mayday Update, the less said about it, the better. I have never seen Google SERPs get things so very wrong – for instance, ranking disabled products with 0 links anywhere on the net that redirect their traffic instead of what used to be the landing pages. Longtail relevance? With 2k organic in-links to the landing page, PR4 and quality content built over 2 years, this is not bizarre enough…


Feb 6th 2009 × CSS for layout? Nonsense, says table loving expert…

The old fable of tables vs “pure” CSS is at the centre of a heated flame war (I mean, a discussion) again. This time, due to Ron Garett’s post on his blog. Naturally, the story got picked up on ajaxian and the CSS ‘know-it-alls’ jumped at the chance to rubbish it all without giving the bloke a chance. And a chance he deserves for what he essentially says–and illustrates via examples–is that CSS for layout is too flawed, quirky and not-that-semantic, whereas tables are can be used to organise your data more reliably and easily as the ‘framework’ upon which you build the site, leaving CSS for styling on top.

Worth the read anyway. Like I always say, the best tool for the job. Never shy away from using tables when your project / data structure justifies it. To be fair – I used to prefer table based design until not so long ago when I discovered the benefits of shuffling content via CSS for SEO in order to get the more relevant text further up the source code of the page. And that’s just not something you can muster via tables…


Oct 21st 2008 × An interesting concept: CSS frameworks and SEO source ordered content shuffling

It makes sense to standardise your CSS layout and styles development just as you come to rely upon frameworks for javascript and PHP, I guess. I came upon Elements V2, a nice and tight CSS framework that does not try to do too much but does it well.

I you are in a hurry to produce a new site, it can help you get started on the right path by literally laying down the framework for your content. There is always the danger of such projects to try and be too-helpful at times–the included Lightbox/prototype is overkill. But the mass CSS reset seems to standardise and level the playing field for all browsers so it’s worth grabbing just for that feature alone. Naturally, not a first: css reset.

And of course, from a SEO standpoint – you can then take Elements V2′s layout, move main content div to the top of the source code and the header div to end of the file. You then reposition via CSS and some nested layers… The end result? First bit of text that Google sees on the page is the specific body content – H1/2, titles and so forth. Bits that are repetitive like header and side menus simply do not need to be there at all. This technique is also known as Source Ordered Content or content before navigation. Here is an example SEO content shuffle on a search engine optimisation project I am tinkering with.

A snippet of this non-linear approach to source ordered content content shuffling (takes a while to get your head around the idea):

...
</head>
<body>
    <!--Main Container - Centers Everything-->
    <div id="mainContainer">
        <!--Main Content-->
        <div id="mainContent">
            <div class="content" id="main">
                <h1>Welcome to <strong>ASAP Cleaners</strong>...
                ...
                ...
            </div>
            <!--Footer-->
            <div id="footer">
                ...
                ...
            </div>

        </div>
        <!--Header-->
        <div id="header">
            ... links here
            ... more links
        </div>
...

and here is what it looks like in reality:

after SEO shuffle: reversed layer order

I am not going to go into details and bore you with tedious explanations on how to float elements. Just visit the source ordered content example and view the source.

To an extent, I already do this on the http://fragged.org blog itself – what you see as left side menu actually follows behind all the posts in the source code. I cannot really measure how this works in comparison to a normal linear source. I guess some experimentation will be required but that’s for another post :)

Word to the wise: if your pages’ source code gets to be quite big in size, you may consider not using the “content before navigation” method as your page links may be disregarded by some crawlers (with a 100k or so limit for source size on each page). Also, there is an accessibility consideration–some say source ordered content is being harsh on people with disabilities (er, blind) who use reader software (it cannot find the menus, allegedly) so be careful.


Sep 15th 2008 × Ecommerce platforms: BossCart JV

As I am pushing on in my quest to find a perfect free e-commerce platform that has great SEO, ease of product, brand, stock and category management with industrial strength order management. Not an easy task, to be sure… The latest package I’d like to talk about today is BossCart JV by BossCart

What I had presumed to be a lightweight version of their bespoke commercial product is actually quite different. For starters, it uses mootools (1.11) and the “commercial” cart is under jQuery but let’s not draw any conclusions on the strength of the frameworks based upon this just yet, heh :) . It also seems to lack one very important facet of trading: brands/manufacturers (this has been left for the ‘full’ version once again). Other than that, first impressions as a user: it appears to have been coded within the spirit of Web 2.0 in mind – search tags, lightbox imaging, product ratings, the chunky yet slick looks…

Since this IS fragged.org, we write about what we don’t like first and assume the rest is fine or dismiss it as boring… With that in mind, let’s pop the bonnet and see if this baby can organically give good SERPs. n.b. you can always fix the css/theme so this is very superficial

I picked http://jv-cart.bosscart.com/golf-iron-supplier as the page to disect first.

I always wondered what JV stood for and some light got shed here:

<img src="http://jv-cart.bosscart.com/components/com_virtuemart/shop_image/product/0a2d9237bb75f96c09db6f5d91de7287.jpg"  width="135" border="0" alt="Titleist Pro V1 Premium Refinished Golf Balls" style="float:left"/>

Seems that at least in part, the jv-bosscart are based on Joomla / Virtuemart. This explains a lot – mootools 1.11 and not 1.2, for starters (Joomla have yet to move over).

The URL is SEO friendly enough, although the title does not appear to be even remotely relevant. We find this:

<meta name="description" content="" />
<meta name="keywords" content="sample Boss Cart JV golf shop,http://jv-cart.bosscart.com" />

It may seem like a little thing to simply go and set it manually – but the last e-commerce site i worked on had 1200 products and 50+ categories. Today’s e-commerce software needs to try and back the site owners up and fill in wherever possible…

The default theme seems to have a topbar and a side menu element floated to the left, with the body of the page that follows. Obvious disadvantage of that is that repetitive text (categories, site pages, header bits) will always precede the real important page headings and body texts that will determine the page relevance.

The page also appears to be using a mix of css-driven-design and tables, as well as plenty of inline css.

Also stuff that you can clean up as you customise it. Links not having title tags is yet another hindrance that will need fixing.

The first real page-relevant bit of code in the source is at line 228 (a bit too far down for my tastes). The most important dynamic content, keywords, heading tags, descriptions – they should be as close to the top of the page as possible and without too much markup. This may be a semantic view but it works.

The questions here is, are there good enough framework templates to get you started re-skinning the default one?

How effective is the organic SEO out of the box? I decided to search on google for the products in the test shop – obviously w/o any proactive marketing as examples: Bay Hill Plasma irons comes as no. 1, Bay Hill Irons as the 4-th site down. This may be due to the number of inbound links to the BossCart site but it’s also no fluke. The product descriptions are explicit and help matters also. Titleist Golf Balls comes up also on page 2.

The provisonal verdict for BossCart JV: There are a lot of areas that need work – messages here and there, visual glitches, optimisations and other bits. We’ve not looked at the admin interface yet — but it has potential. I would say, as an out-of-the-box free solution, it probably does more for a startup business than oS Commerce or CubeCart.

I will post updates here as soon as I find more about it.