Mega Menus and SEO Concerns and Solutions (Mega Menus Part 2)
- Mega Menus: SEO Concerns and Usability Pros and Cons (Intro)
- Usability Advantages and Disadvantages of Mega Menus (Mega Menus Part 1)
- Mega Menus and SEO Concerns and Solutions (Mega Menus Part 2)
I’ve already reviewed some of the usability problems with mega menus, but the SEO problems are another source of concern. There are a variety of solutions thrown out around the web, but most of them are aimed at masking the problems rather than truly solving them. So first let’s look at the nature of those problems, then we’ll look at some solutions to the mega menu problem. In brief, though, this is ultimately not a design or technology problem, but an information architecture problem, so the best solutions lie with better architecure.
Mega Menus and Search Engine Optimization Problems
Ultimately, it wasn’t the usability questions that brought me up short with respect to mega menus. It was the SEO concerns. Mega menus end up putting lots of links at the top of the page, sometimes hundreds. Google itself says in its Webmaster Guidelines that webmasters should “Keep the links on a given page to a reasonable number.” Google’s official Search Engine Optimization Starter Guide (PDF) recommends that webmasters should avoid “creating complex webs of navigation links, e.g. linking every page on your site to every other page” (p. 12). When the mega menu gets truly large, it effectively ends up doing just that or very nearly.
Few voices in the Search Engine Optimization community are more respected, experienced, and authoritative than Ted Ulle. Back in 2008, Ted had a number of clients with -950 penalties and one of the common characteristics that jumped out was a tendency to have site navigation with tons of links. In internet years, 2008 is a while ago, but Ted continued to see this problem in 2010 and 2011, as we’ll see. Also, in 2010, Jane Copland of SEOMoz said that in her opinion “massive drop-downs certainly aren’t adhering to SEO best practices.”
So why would a large collection of links in the page templage create problems? There are a number of possible reasons. Unlike some of the usability issues, none of these are unique to menus formatted as classic mega menus. Instead, they are a simple function of the number of links, but I do believe that once the mega menu tool is available to the design team, the number of links tends to explode. So it is more an enabler than a cause per se.
- Confused Relevancy Signals. It helps the search engines determine what a page is about if you keep it laser-focussed on the topic at hand. Normal navigation adds a handful of keywords that can confuse the signal a bit, but it compensates by helping focus the search engine’s understanding of overall site content and spotlight the most important pages. Mega menus, on the other hand, can add hundreds of keywords that confuse the signal. In information theory, the keywords in the mega menu are “noise” and it make it harder for the search engines to figure out the “signal” (page topic) and therefore figure out relevancy of the page to a given search.
Google is getting better at ignoring navigation and boilerplate content. Some people contend that, therefore, this is not a problem. But Ted Ulle stated in January 2011 that he still believed that a large number of links in the page template is problematic for relevancy. In brief, you are challenging the search engine by adding this much noise to the signal and you have to ask whether or not you really want to depend on the strength of the Google or Bing algorithm to sort out your “semantic chaos” as Ted calls it.
- Link Equity Dilution. This is similar to the semantic confusion caused by the forest of anchor text in your navigation. Each page has a certain strength and each link passes some of that page rank to the pages it links to. You can stop passing that equity by using the nofollow attribute on your link, but you can’t preserve the link equity this way. When you add a nofollow attribute to the link, it still leaks equity from the source page, it just doesn’t add it to the target page. So no matter how you cut it, they massive number of links are diluting the link strength of the page and tending to make it harder for the engines to figure out which parts of the site are important.
- Crawl Challenges. This was more of an issue in the old days when search engines crawled only the first 100KB of code or so, but even with improvements, you’re putting a bigger challenge before the search engine.
- Page Load Times. Again, this is a minor issue, but a massive collection of links in the navigation will slow down load times and rendering. Of course, one decent image or a large CSS file will quickly outweigh this, but we do know that load times are or soon will be taken into account in the Google algorithm at least, and we can expect other engines to follow suit.
Fixing the Mega Menu Problem
So what is an enterprising webmaster to do? You have a number of options, some better than others.
- Reduce the number of links.good results with clients by reducing navigation from over 60 links down to 22. By tracking click patterns, Ted and his team found that a single link accounted for 60% of the clicks from the front page and the top ten links accounted for 99% of all clicks. So with some serious thinking about information architecture and some good analytics, you can simply reduce the number of links which will also improve usability. If you can get buy in, this is the preferred solution of course, but buy in will be difficult in any large organization unless you have the data and a strong case. And even then, some doorkeeper with a love of the current layout may block any and all arguments, no matter how reasonable.
- Source-Ordered ContentIt is quite possible to put your menu at the end of your code and get your main page content at the top, but then display the page with the header (and thus the navigation) at the top. This is relatively easy to implement and I used to do it systematically (less so now), but of course, the links are still on your page. So though it mitigates the effects of having all that anchor text and links high on the page, the noise is still there.
- iframe for navigation. I’ve never actually done this, but some people recommend it for boilerplate content in the site footer. The problem with doing this for the navigation is that you’ve entirely removed the navigation as an on-page factor for relevancy and so forth. So yes, you get rid of the noise in the signal, but you also get rid of a lot of the signal and your ability to build link flow throw the site. It seems like a collossally bad idea.
- Use HTML 5 and hope the search engines understand. The HTML 5 spec includes the ability to specifically denote part of your document as navigation using the nav element. Of course, this is bleeding edge, so it’s rather early to expect the search engines to be smart enough to understand this and act appropriately. But let’s just assume it’s 2015 and they all “get” this. You still have the fundamental problem that your navigation is a key tool in telling the search engine what your site is about, and by including a massive number of links, you’ve given up your chance to provide signal to help the search engine cut through noise. In other words, at a certain number of links, you’re still adding noise rather than adding signal. So, again, it may mitigate the ill effects of the design, but it still misses out on a great opportunity.
- Lazy Loading. Lazy loading is where delay loading content until the user wants it. So you images that are low on the page, for example, don’t get loaded until the user scrolls down. There are some excellent JQuery lazy loader plugins that let you implement this simply enough. So that would keep it out of the search engines, but the navigation needs to be responsive and readily available to the user, so load on demand seems like a terrible solution in this case.
So in short, it seems like the best alternative is to use your navigation like a lens to focus the search engine on the main points of your site, and you do that by making hard choices. As I mentioned at the outset of this series, in the end, I found great solutions for mega menus in Drupal , but for all the reasons detailed here, have tended to avoid mega menus if possible.
Tagged with: mega menus
Filed under: SEO • Web Development
Like this post? Subscribe to my RSS feed and get loads more!
I’ve visited several pages where people criticize mega-menus from an SEO standpoint. I don’t find the criticisms convincing.
Yes, if you implement mega-menus poorly, it’s a bad idea. If you implement anything badly, it’s a poor idea.
My thoughts: Use some graphics and text in the drop-downs: Don’t just have a list of 4,000 links – that’s bad for bots and bad for people. If you have a top nav bar with widgets as a item, include some text in the drop-down to explain what widgets are. Help the visitor to select which of the limited number of links are provided by the drop down. Maybe offer thumb-nail graphic links of the different widgets.
There are fixes for iPads. Use them. iPads challenge all web developers; we are stuck with them, and we’ll just have to accomodate.
Thanks for your thoughts Karl.
That’s certainly true. Without cars, we don’t have high-speed crashes on the highway, but that doesn’t mean the car is an inherently bad tool, just one that needs to be used properly.
That’s more or less how I feel about Mega Menus and I see most implementations done poorly and few done well. I agree that with proper implementation, Mega Menus can be a decent tool, but I guess I see them used most often because ten departments all think they need 3-5 links each in the navigation and there’s no navigation czar on the team who gets to enforce an intelligent information architecture. So the designer says, “No worries, you can all have your links” and poof! A worst-practices Mega Menu, but it still looks nice, so everyone is happy.
And as for the iPad issue, I emphatically agree that the fact that something currently might have a few issues on this platform or that one is not a reason to take it off the table.
Thanks, Tom,
Actually, all of the jquery (or similar technology) sliders and menus seem to enhance SEO if done right.
Search engines have always loved mountains of text (a 10-page text-only essay is great for long-tail SEO). People tend to enjoy a cleaner design centered on graphics, and free of scrolling. Mega menus (especially if you don’t simply think of it as a pure menu, but as a sort-of AJAX way of offering a mini-page on a subject) let you include far more text on a page and keep the clean layout centered on pretty pictures.
Hey thanks so much for stopping back in Karl with the additional thoughts.
[As an aside to this discussion. I love your company name - Sastrugi Marketing. I've always loved the word and it marks you as a kindred (I skied at least once every month in 2011)].
I think we basically agree, but in different language. At the risk of putting words in your mouth, I’m reading you to say that the Mega Menu as a design element is fine, but implementations that go hog wild with the number of links are the problem. Is that fair?
I can definitely see that and I can imagine very effective menus designed using the space effectively while still keeping the number of links reasonable (albeit some of the usability problems of very large menus will not go away no matter what).
Just curious on a technical point. When you say JQuery menus and sliders, do you mean AJAX or non-AJAX implementations? In other words, most JQuery menus (and to a lesser extent sliders) load everything and then use JQuery to hide it, so from an SE perspective, that text is all still there. It’s just a design enhancement.
Only a small number of the implementations I’ve seen use JQuery to do lazy loading, which is to say only top-level menu items are loaded on first request, and the requests for the rest are sent only when triggered by the user (on hover for example). So the second-level menus available to the user are actually not there until the event is fired (and so unavailable to the SEs). Only when the trigger is pulled, say by a hover even, does the AJAX or JSON request go through to load the additional data. That can create usability problems since the menus will have significant delay on a high-latency or a slow connection, but it does get rid of the SEO problem (though not the usability issue) with large numbers of links.
The search engines love mountains of text, but keeping the text on any given page on-target helps with relevancy. Again, this is going to be a design and information architecture question, but I think that Mega Menus tend to include a fair bit of information that is off-target with respect to the content of the current page. The broader the website, the more likely that is to be true. So the large amount of text in the Mega Menu can be confusing the signal sent by that 10-page text-only essay.
Thoughts on that? Agree or disagree (I’m not proud, so don’t feel a need to be polite about it either — feel free to push the BS button if you are so moved!)
“I skied at least once every month in 2011″
The background to my site is a picture I took on Labor Day 2011 Timberline. Summer skiing is the best skiing!
“Mega Menu as a design element is fine, but implementations that go hog wild with the number of links are the problem. Is that fair?”
Exactly. We agree completely. Some non-Mega Menu sites have too many links. Mega Menus simply tempt the ill-disciplined. For most people, a liquor store is a fine business to own. For an alcoholic, not a good plan. Can’t stick to the outline? Don’t Mega Menu!
“AJAX or non-AJAX implementations”
Non-AJAX. As an SEO guy: “from an SE perspective, that text is all still there” matters to me.
“That can create usability problems since the menus will have significant delay on a high-latency or a slow connection”
If the drop-down stuff is properly compressed (and don’t load up your drop-down with large items), I’d recommend normal loading. Then you have that great AJAX feel – new information smoothly in milliseconds, instead of the “1/2 second for the first byte” clunky feel of loading a new page. Without the AJAX SEO challenges.
A concern I would have with slow loading drop down elements is user expectations. Most people assume a new page will take time to load. But, they expect drop down content to load instantly.
The text is just like the links: It’s not the fault of the mega drop-down menu; the content creator/web developer/SEO folks should keep the whole page on track and pointed at a limited number of topics/keywords. Regardless of the technology employed!
The best SEO work I ever did was a 3,000 word (more or less)history of competition in the very, very narrow industry I was working in. The page ranked #1 for many of our competitors names in addition to thousands of long tail search terms! Additionally, it was #2-10 for many more popular search terms. It worked because it stayed completely true to a very specific topic for all 3,000 words.
@Karl Kelman
Is that website online?
I would very like to see it :P