Mega-navigation / Mega-menus: Should I move content higher?

[csdude55]

My navigation is the real question. I have a horizontal bar for navigation that has 9 categories and 46 subcategories. It's all generated through a PHP array, but what the browser sees is the navigation beginning on line 294, and ending on line 1278. So, about 1,000 lines of code for navigation.

I have 3 main keywords above the navigation, on lines 222, 228, and 239. But I'm concerned that having the content of the page starting at line 1278 is hurting more than it's helping.

I could rewrite the navigation in JavaScript, or maybe Ajax, which would eliminate about 800 of those lines. Would that help to make the content appear more relevant? Or would making the navigation all JavaScript inadvertently make the search engine stop following the links?

I should mention that the navigation is repeated in the page footer without JavaScript.

TIA!

[Wilburforce]

I could rewrite the navigation in JavaScript

That is what I would do (have done).

Or would making the navigation all JavaScript inadvertently make the search engine stop following the links?

Most SEs can now follow JS menus, but it is good practice to put in a (html/css) breadcrumb menu as well, which will both help SEs to establish site/page hierarchy and allow users with JS disabled browsers to navigate the site.

I should mention that the navigation is repeated in the page footer without JavaScript.

I wouldn't repeat the whole menu. Having a single comprehensive menu runs the risk of making your pages link-heavy (which is an issue in itself, but more so for any pages that are also content-light), and doubling the links doubles the problem. Links in the footer are best limited to main section categories.

[topr8]

if the horizontal navbar is generated in php why does it have to be 800 lines long, you could write it all without line breaks and it would be only 1 line long! so your content would be much higher up.

... although seriously you could easily use css in order to put your 'content' higher up in the code than the navbar.

many people used to do this, we certainly did at one time, about 10 years ago. but we don't bother anymore, although we did it as internet connections were slower then and it enabled our content part of the page to render first.

today SE's seem to be able to distinguish what is navigation and what is 'content'

you can help them out though by wrapping your nav bar in

<nav> ... </nav>

tags, that is what they are for.

[hasek747]

@Wilburforce

Having a single comprehensive menu runs the risk of making your pages link-heavy (which is an issue in itself, but more so for any pages that are also content-light), and doubling the links doubles the problem.

Would you mind elaborating a little bit on this?

[Wilburforce]

Would you mind elaborating a little bit on this?

If you have a menu that accesses all pages on a 500-page site, then having it twice on the page gives you (at least) 1,000 links on each page, which on a page with a 500-word article gives you two outward links for every word of content.

SEs might assess this as a (spammy) page whose main purpose is redirecting key-term queries, even if (or perhaps especially if) the content has high key-term relevance

The primary purpose of your menu is to allow your visitors to find what they are looking for easily, and your site needs to remain navigable if css or JS are not working in the visitor's browser, and for small-screen devices.

Until Google started demanding access to all page resources, my JS menu was in a robots.txt blocked folder, and SEs relied solely on the breadcrumb menu for internal links and site structure. For many years this worked without any problems, but should also say that I haven't noticed any adverse effects since unblocking the folder last year.

[csdude55]

The primary purpose of your menu is to allow your visitors to find what they are looking for easily, and your site needs to remain navigable if css or JS are not working in the visitor's browser, and for small-screen devices.

FWIW, this is why I originally did my navigation in PHP instead of JS; I wasn't sure if SE's would follow JS links, and wanted to have an alternative for non-JS users.

You make an excellent point about doubling-down on the navigation, though. I may have to reconsider that.

<nav> ... </nav>

Thanks for the tip, I was totally unaware of those tags!

[FranticFish]

I've not tried source-ordered content myself, but I've read posts from those that did that it stopped working a ways back.

There have been penalties and parts of the algorithm concerned with how the page LOOKS, and it is likely that Googlebot is a 'headless browser' that understands the page in its final rendered state and not as a collection of code from different files.

It's not a confirmed fact AFAIK, but this article (mods: not affiliated, hope link is OK) explains it well and makes a convincing case - [ipullrank.com...]

[lucy24]

you could write it all without line breaks and it would be only 1 line long!

I kinda doubt that google gives much weight to line breaks, as such, in the html. White space is white space; the character count is the same either way. Well, maybe a tiny reduction if you're using CRLF.

[No5needinput]

About 2 months ago I changed my top menu from listing 14 main categories to a mega menu with around 400 main and sub categories. Of course this added a mass of code to the site (straight placement code not re-positioned with css). The result? Not the slighest change in ranking or traffic after 2 months despite the extra links and coding.

[tangor]

Given broadband speeds it's unlikely mega menus are quite the problem they were back "then". However, duplicating same on page header and footer is a bit much. My foot has a menu "jump back" link to the header to display the already loaded menu again. Works a treat and keeps the page that much leaner and avoids "too many links".

[Robert Charlton]

it is likely that Googlebot is a 'headless browser' that understands the page in its final rendered state and not as a collection of code from different files

FranticFish... thanks for your observations, and for the link to that article. I assume that Mike King wrote it. It is a superb and thorough overview, and contains a lot of information worth thinking about. I note that Bill Slawski suggested some of the research material.

Particularly interesting, btw, are the dates of implementation of various aspects of the Google infrastructure, which dovetail right into Panda. The date of the article, btw, is Nov 1, 2011, and it was amazingly forward looking.

[Robert Charlton]

PS - Just looking at the serps makes me believe that source-ordered content is no longer necessary. Years back, if you remember the serps that long ago, if Google didn't use your meta description, you'd end up with all sorts of junk from the top of the page in your snippets... fragments of menus, logo alt tags, whatever. Apart from ranking, cleaning up the result display was one of the main reasons I used source-ordered content... to get the main content as close as possible to the start of the code.

I haven't seen results like this for a long time. Back in the day when I used source ordered content, I vaguely remember that moving the relevant content closer to the top might also improve rankings by a couple of places.

I still have a big aversion to mega-menus, though, or even just large drop-downs. I describe them as "confusing for users, confusing for Google." Source-ordering shouldn't change the core issue, though, which is simply loss of focus by too many links on the page. I think they may be less of a problem for a site like Amazon, that attracts direct links to its deeper pages, and has a huge amount of homepage authority as well.

[aakk9999]

About 2 months ago I changed my top menu from listing 14 main categories to a mega menu with around 400 main and sub categories. Of course this added a mass of code to the site (straight placement code not re-positioned with css). The result? Not the slighest change in ranking or traffic after 2 months despite the extra links and coding.

I still have a big aversion to mega-menus, though, or even just large drop-downs. I describe them as "confusing for users, confusing for Google."

I dislike mega-menus too and we had a number of threads discussing "diluting the page focus / section focus" by placing all links to all categories and their sub-categories on every page.

With mobile being important, more and more sites are implementing menus where every page has the complete menu structure within HTML - this allows user to view the complete menus on mobile where subcategories are uncovered by javascript "on-tap/on-click".

So whilst initial opening of the Hamburger menu may look like this:

>Category-1
>Category-2
>Category-3

And whilst the tap on the Category-2 will result in user seeing this:

>Category-1
>Category-2
>>>Sub-cat-2-1
>>>Sub-cat-2-2
>>>Sub-cat-2-3
>Category-3

What actually exists in HTML on every page are all possible menu links:

>Category-1
>>>Sub-cat-1-1
>>>Sub-cat-1-2
>>>Sub-cat-1-3
>>>Sub-cat-1-4
>Category-2
>>>Sub-cat-2-1
>>>Sub-cat-2-2
>>>Sub-cat-2-3
>Category-3
>>>Sub-cat-3-1
>>>Sub-cat-3-2

Having all subcategories appearing on all pages used to confuse SE what the page focus is about. This is where blocking JS that would block sub-categories from being visible came about.

But interestingly, as few members here report, it appears that Google is not confused by this any more.

As much of the sub-categories are hidden on initial page load, then my guess is that this is one of reasons why Google is saying that hidden content on the page is ignored. Ignoring hidden drop-down menu parts would allow Google to see the page in the pretty much the same way as it saw it before when all of the second level of navigations were not in the HTML code on every page.

[csdude55]

Google is saying that hidden content on the page is ignored.

For the sake of clarification, I assume you're referring to CSS like display: none.

What if I do something like this:

if (screen.width < 480)
 document.getElementById('something').style.display = 'none';

else
 document.getElementById('something_else').style.display = 'none';

I ask because I've been making elements specifically for mobile that are hidden otherwise, and the elements that are currently for desktop will be hidden on mobile. So both elements have a conditional statement that would hide them. Does this mean that both would be ignored by Google, or is their system now smart enough to read the conditionals?

If they do read the conditionals, which one would they see?

[aakk9999]

If they do read the conditionals, which one would they see?

They see both. It is what they take into the account that has changed.

I believe they still only use desktop page version for scoring the document. So you should make sure that the content you want your page to rank for is visible when the page renders, without the user needing to interact with the page to "uncover" it. And this is why Google wants you to unblock javascript - so that they can see what is executed "onload".

[lucy24]

What if I do something like this

document.getElementById('something').style.display = 'none';

But why would you need to take this additional script-dependent step when you can do the same thing directly in the CSS? By this time, Google should have no trouble understanding exactly what you mean.

Aside: If you have parts of your content that are not meant to display on smaller devices, make sure that any resources used only by that content aren't loaded at all. For example, change {background-image} from whatever-URL to "none". The user won't see a difference, but the connection will thank you.

[csdude55]

But why would you need to take this additional script-dependent step when you can do the same thing directly in the CSS?

The section I'm specifically referring to is this navigation area. On a desktop I have a horizontal bar that's 775px x 50px... perfect for desktop, but way too long for mobile. So on mobile browsers, I'm hiding this section and, instead, unhiding a navigation menu that's 150px x 100% that opens on the left (in theory, I can't get the scripting to work right... different thread, though).

Also, on desktop I have a 180x80 element in the upper right where the users can log in directly to the site, and if they're logged in then it shows if they have new messages. It doesn't fit here on mobile browsers, though, so for them I hide this section, then unhide a similar 180x30 element in a totally different area.

I'm hoping that Google is smart enough to figure it out, because if not then either my navigation is doubled up in the header (which has already been mentioned as an issue), or the navigation is skipped altogether.

[blend27]

...and if they're logged in then it shows..

But Google is not Logged, or is it? If not, you could make the LOGGEDIN UI what ever willing.

For not Logged in look at this site what happens when the resolution drops to Mobile dimensions.

Play around it with it, SHIFT+Ctrl+M on FireFox.


As for moving content up:


<style>
....style sheet for top menu to make it look the way it looks now
</style>

<div id="top-menu">empty</div>

content blah bloh bluh...

<div id="footer-menu">all the html for the menu goes here</div>

in then in JQuery:
<script>
$('#top-menu').html($('#footer-menu').html());
</script>

I do the same with Pagination on Catalog pages - No Problema!

[topr8]

@lucy

>>I kinda doubt that google gives much weight to line breaks

i agree!

i was being facetious, you'll note that on the next line i wrote: "... although seriously"

[topr8]

as a side note to this discussion i would also add that last year i did some tracking of which (internal) links were actually clicked, it turned out (in our case) that a lot of the links in some of our menus were a bit of a waste of space.

although large menus, with lots of links, of course can also be used to help convey the impression of size, which is also an important factor.