Welcome to WebmasterWorld Guest from 18.104.22.168
Type #1 just has a long laundry list of links down the left hand side (and often across the footer) and Type #2 uses a CSS hover menu so the page LOOKS neater, but the code still holds many, many links - especially if the menu goes into a second or third level.
Why could this create a problem? I have two ideas. First, we know that anchor text is a heavily weighted element in the algorithm. All that opportunity to go over the top with keywords in anchor text cannot be a good thing. And second, Google reps keep repeating the advice not to go beyond 100 links on a page. Even if more links are now spidered, just think of the pile of semantic confusion that this can throw at the relevance calculations.
So I started looking at the client sites that are really cooking - and guess what, they often are between 30 to 40 links on the home page, no more.
On one well ranked site I was called to help with, we improved even further by dropping from about 60 links in the template to only 22.
Using their analytics program we discovered that one of the home page links got over 60% of the clicks, and 10 of them got 99%! The other were there for "SEO" purposes, but the customers apparently could care less. So we dropped a ton of that anchor text from the site template, and saw rankings get even better on the best terms.
On another site, there was a 3-level hover menu that, even before any content area links, offered 130 anchor tags. We re-thought the Information Architecture and moved the site into a classic "inverted L" format, dropping down to about 45 links per page. Again, everything about the site started to perform better, rankings, stickiness, conversions, you name the metric.
VISITORS LIKE IT TOO
Even without SEO concerns, hover menus can be a problem for visitors. For one thing, they cannot see all their options at any one time. For another, it's easy to end up with several links that have the same anchor text but point to different pages. Now that's confusing both for people and for algorithms!
It can be mind-bending work to to generate a good Information Architecture -- and even harder work to choose optimal menu labels. It's much easier to grow a site by just slapping more links onto the menu. However, from what I've seen, slim and trim is the way to go with menus. Google seems to like it a lot, and a visitor's first impression of such a site is "I can deal with this", not "sheesh, where do I start?"
I'm not saying you can't succeed with a Mega Menu, only that it can be more problematic. Especially when you've been programmed with the SEO mantra of "links, keywords, anchor text, links, keywords, anchor text" for many years, it's easy to go wrong without even noticing.
Anyone else have experiences with different sizes of menu? Maybe you have results that run counter to mine, or may they support mine. I know that we each see our own particular slices of the total web and not others.
Whatever the case, I'm interested in how my Mega Menu idea looks across many markets.
[edited by: tedster at 3:18 am (utc) on July 2, 2008]
Just a note my left side menu had about the same number of links as Amazon so I can see the issue.
I do have some concern as to the PR flow as brought up by lorel. The page I am now linking to with all the links that was my Menu is not cached and and grayed out, but as ALbino says if this will get me out from under this filter it will be well worth it. I have a strong site link wise and all so this just may be the trick that will lift the filter.
Thanks Tedester will post back if something changes good or bad as I do have some really good rankings in yahoo and Msn and will be watching them for any changes.
[edited by: bwnbwn at 1:47 pm (utc) on July 3, 2008]
joined:Jan 3, 2003
mega menu, in a SEO point of view, would not be the same using a sitemap?
In essence, yes - for smaller sites, it is like putting an entire user's site map on every page. We're in the Google forum here, but as a side note, Yahoo once explicitly told a client of mine that this was the reason for a penalty they received.
Their current approach of changing the side menu depending on the category is a decent approach. when they first expanded beyond Books, they tried all kinds of approaches, including 19 categories on every page and a DHTML show/hide menu. By restricting the links to those within the category, they are getting a better semantic focus in various parts of their site.
20 http requests to the server. Oh, there were all sorts of neat little gadgets in that thing. How do you think this ties in with the Mega Menu mindset?
Excessive http requests may become the next big buzz, as Google ups the ante on measuring user experiece - and the content of all those gizmos cartainly can blur the metrics as well as slow the page load speed.
I used to think of search engines almost like dealing with a learning disabled child who also had a hearing problem. Now the learning challenge is still there, but Google's hearing became extremely sensitive. If you yell at it, or give it too much input at one time, you may stimulate a tantrum!
...treeview navigation system
Many times the programmer who creates these in a generic form has not given thought to any issues beyond just getting the thing to work! If the hidden menu links are spiderable, and the number gets too large, it can have the same kind of mega menu problems I mentioned above. Just because the extra links get displated with a click rather than a hover doesn't change the core risk.
Since the end user is often familiar with this kind of interface from Windows Explorer, it can be more comfortable from a usability point of view. Still, as a general rule, website menus are not like applications that a user will be involved with every day - and so they deserve a different mindset when they are being decided.
Sometimes a top level of categorization can be combined with an alphabetical system WITHIN each category to give a much more informative and manageable approach.
Okay, now that we've discussed some of the challenges that Mega Menus present, what can we do to change? Lots of good advice in this topic and I want to bring the Wiki into this again. I'm really fond of the Wiki and that whole platform. I think it is a work of art technically. The Wiki has two primary things that "I like" and those are...
The Wiki have provided many access points to their content. I prefer using search most of the time but I've come to learn their taxonomy and I know I can usually find primary entrance points by using single word URI appendage...
And usually end up where I need to be. Once you've used the Wiki for a while, you tend to just switch to URI navigation or what I call Intuitive URIs. I see more and more invalid request like this on specifics types of websites. In some instances it may be a rogue bot, in others it might be someone trying to see if they can use a word at the end of the URI and get to where they need to be. They see that you use a short, single word taxonomy and can usually figure out the paths after a few browsing sessions, those are Intuitive URIs.
I'm sure there are many still wondering how to take a db of 2,500,000+ products and avoid the Mega Menu Madness. Its difficult. And to undo a Mega Menu is a task in itself. You could expect many man/woman hours in the undo process, I know. And, a lot of testing, testing, testing and more testing. And then some undoing after launch. It never fails, something gets missed when you have to traverse through years of programming layers. And, I don't want to hear the "Ah, that shouldn't happen!". Well, it shouldn't, but in the real world, it does. And, usually 9 times out of 10 something is overlooked, sometimes minor and in some instances, sometimes major. :(
I know we're going to get the crowd that says "my competitors are doing it" or such and such does it that way. Don't even get me started. I've found that your competitors and/or such and such, can cause you more harm just by following what they are doing. When the hammer comes down, your right there with them, doh!
If someone were to come to me today and say Edward, I have a db of 2,500,000 products and its a brand new website, I'd have a much different approach to the taxonomy. In fact, I think the menus would come last. I want my dynamic menus at that point. Okay, so where is the user? Then our menu should be this, this, and that, period. Remember, there are many other areas where you can provide navigation for users that don't require a menu system. Look at the Wiki! Inline Navigation, Multiple Access Points...
There would have been a world of difference in setting up the site architecture.
When I set the site up Mega menus were the only way to go so were many other things that have changed. I am really glad I started a complete overhaul on the site about 7 months ago this really is the last thing I retained I guess it's like the Book "Who moved My Cheese" and one of the old things I was hanging onto as a way to draw more kewords to the site.
Why? LOL, there is nothing ugly about Sa-Se compared to S-T.
If you use the alphabet, you aren't exactly aspiring to Shakespeare. Breaking the alphabet down into 50 units is easily understood and users would have no problem with it. It's not as ideal as "red widgets" and "green bodgets" but it's logical and Google would have no problems with it.
I guess I should mention that on our site the index page is literally just A-Z in large letters. That's how you navigate. It's not like it's just some small text at the top, it's the entire page. To go from 26 giant letters to 50+ giant letter-combos would clutter everything up aesthetically IMHO. But while we have no real problems getting our pages crawled, I do agree that maybe it's worth trying if it'll get us out of this stupid penalty.
Some will say that you could put them in an <iframe> which would probably produce the result you want. Yes? You can then do whatever you wish with the page in the src of the <iframe>. Maybe follow, noindex or something like that?
Menu's should be used to get people to a section of the site which has an effective summary (back to the Pyramid post of Brett).
That is good in theory, but it does not work well on mega sites and we end up with menu structures that are complicated and impossible to navigate at times. Some menus are almost like playing video games.. click, hover for 5 seconds, move the mouse quickly. Tires people out eventualy.
As observed by some of the people here, we looked at the click through rates on the various menu items and people were using 7 out of the 40 odd css / dhtml menu we had in place.
We looked hard at how users prefer to navigate (and looked at how they used Amazon). The conclusion was, an effective site search and page layout works FAR better than menu driven navigation on e-commerce sites.
If you're still a believer in the long tail sale, there is very little you can do to guide the user to product you're looking for. You have to let them FIND it.
If you're using the menu's to get people to find products on an ecommerce site.. forget it. Look at a good site search engine.
Think "Blink" from a customer's perspective. I am of the opinion they'd rather just type a search into your search box, find the product and place it in their cart in a minute, rather than play some warped version of web-tetris to navigate through menus to find a product 10 mins later.
Menus should be used to get people to a section of the site which has an effective summary... ...good in theory, but it does not work well on mega sites.
...If you're using the menus to get people to find products on an ecommerce site.. forget it. Look at a good site search engine.
I think the point of "effective summary" is a powerful idea. Even with site search, you still need to get people to a good jumping-off place for search. Again, it's a question of giving the visitor an understanding of what's available on the site. This is perhaps more easily done an ecommerce site... less easily done on sites where a site is offering information that's conceptually new. I tend to use what I call "plateau pages" or mini-sitemaps to provide points of summarization.
...change or add navigation by industry or application, rather than by product.
One of my least favorite words in the English language is "Solutions," but this is a category on many technology sites where I see industry or application targeting.
In the center section, a "bold headline" is a black colored internal link, followed by a very brief block of text, followed by a blue colored "more information" link. The "bold headlines" are 5 - 8 words long. Many of the words are repeats.
Anchor text may well be greater than content. It looks more like one giant menu cum links page than anything else.
The kicker, the domain name matches the key phrase.
If, however, a site is such that there are thousands of similar sites, I can understand where less is more and would not at all be surprised if it was true in SERPs and page ranking.
I think the bottom line is simply - what makes sense to a human makes sense to a spider. In the mad rush to insert as many keywords as possible to help ranking in the form of links, I believe developers have gone overboard and, in effect, have defeated their own purpose. I would say it rates up there with people abusing the meta keyword tag thus making it less important.
[edited by: Robert_Charlton at 6:32 am (utc) on July 6, 2008]
[edit reason] removed specifics [/edit]
After that, it comes down to making sure you are not repeating the keyword in the nav links themselves.
If the website is laid out in a well-defined hierarchical format, like siloing.
Hmmm, I just read the dictionary definition of that and I'm not too certain that would be the proper term here. I know, I know, someone in the industry created that but I'm not going for it. If you read the definition of Information Siloing, I don't think it applies theoretically in this instance.
The silo effect is a phrase that is currently popular in the business and organizational communities to describe a lack of communication and common goals between departments in an organization.
Hehehe, I wonder if siloing from an SEO standpoint does the same thing. Duh Edward, that's the purpose of it! ;)
Also, the above process leaves way too many footprints from what I've seen. In some cases it uses "new protocols" to perform what should be done via other methods that are "natural" and not forced.
I do believe the Mega Menu is all relative. The bigger the site, the bigger the menus, its a natural progression. But, at some point, you reach critical mass and navigation becomes a real monster. If its a monster for you, it is most likely a monster for the indexers.
I'm still working my way toward the Wiki Mindset. I really dig the Wiki and the W3 believe or not. Those two sites have an internal navigation mechanism that is truly a piece of work.
I think that there may be variance between the base term and the way we use the term, without getting off topic too much from this thread. Since you like Wiki:
"a management system incapable of reciprocal operation with other, related management systems. A bank's management system, for example, is considered a silo if it cannot exchange information with other related systems within its own organization, or with the management systems of its customers, vendors or business partners."
In many respects we do not follow this rule as webmasters, but it is an excellent guideline when creating a website and understanding themes and overall hierarchy.
The more varied the topics are, the more sense in my opinion it makes to follow a silo'ed approach, where the various institutions only perform 'limited talking' when necessary.
I know there are exceptions to the rule, such as Wiki, but imho in general those exceptions are found on massive, authority websites.
This might help in some mega menu websites. The reasons I've seen mega menus happen fall into a couple categories:
1. Fear that every visitor won't have every option
2. Loading up anchor text for the search engines
3. Wanting the website to be a good utility for the company's staff
4. Unwillingness to put in the energy/time/resources to develop a solid information architecture
None of these are good, user-oriented motivations.
Having a nav link on a "yarn" page to your "bazookas" page is not going to be anything more than clutter to a user on the yarn page. A link to a "weapons" page is far more useful, as presumably anyone looking for a bazooka knows it is a weapon. Likewise, people on the bazooka page will more likely like to see a "speargun" link than a "yarn" one, but wouldn't have a problem with a menu with a "crafts" link or soemthing like that.
If you have a site about lots of things, you should do your visitors a favor and organize your navigation to send them easily to the 99% of things they are likely interested in that are related, while making the unrelated stuff that 1% might look for (the yarn user bazooka owners) findable but with more difficulty. You end up with links from related stuff to related stuff, and with more links to your popular stuff and less links to your obscure stuff.
Many people worry about the ancient "3-click rule" that said a visitor should be able to go from any page to any other within 3 clicks. Well, that widely discussed "rule' from the '90s has been debunked in actual testing. the original rule was a nice guess, but unsupported by real data.
What matters to the user most is what Jakob Nielsen calls the "information scent". As long as the information scent for what they want keeps growing stronger, the user keeps clicking.
While I'm checking out the bazookas here, I should see if they have the cotton yarn my wife wants for her needlepoint. Let's see, Crafts [click]. Oh that's good, there's a Needlecrafts section [click]. Now i see Needlepoint [click]. And now there's a Yarn link [click]. OK, there's Cotton [click]. I'd better bookmark this page and ask her which colors she needs.
We all do it all the time - and so will most visitors if they have a purpose.
Maybe I was already below the optimal number of on-page links.