Forum Moderators: Robert Charlton & goodroi
There's about - 63 links in the footers I am talking about.
My question is:
In your valued opinion should I reduce these footer links to about 5 links, home contact about, or remove the footers entirely from the site?
Thanks!
I suggest removing entirely - as long as there are alternate paths to the links elsewhere on the site, so that Google can actually spider those pages
I think this is also part of the problem. The footer is constantly changing and growing. To Google this would look like like 'fiddling' - often a giveaway sign of SEO.
It sounds like the site has about 150 pages overall - I'd venture to suggest that you need to revisit the structure to reduce this footer dramatically. For a site of that size, you could have say 10 footer links to 10 main categories (this footer would then never change). Each of those main categories would then have links to products thereunder.
This would create more of a pyramid type hierarchy, structurally. At present the structure is rather too 'flat' IMHO.
> There's about - 63 links in the footers I am talking about.
Why?
> In your valued opinion should I reduce these footer links to about 5 links, home contact about, or remove the footers entirely from the site?
Check your stats. If hardly anyone views them, kill them. Home page for stuff like that is sufficient. If you keep any, be reasonable. More than 5-9 looks to Google like link spam.
BTW, experiments are risky. Too much playing around and Google can see you as an overoptimizer... you'll be in its crosshairs before you know it.
Sometimes the best thing to do is nothing... even if you have some extreme things on your site (63 footer links). If it ain't broken, don't fix it. (Until a new Google Update rears its ugly head.)
p/g
I got my experiment page back from page 12 to page 5 now - still with the long footer links.
Thing is, it was in position 2 for over 5 years! So that's a big drop and will try this reduction in footer links, if it bugs out, will revert back to long footer, and in my experience, reverting back to a previous setup gets a site back to where it was previously pretty quickly.
Look for intelligent ways to reduce the bulk of your footer. Start by looking for ways you could edit for conciseness without actually removing links, although it sounds as though some of those links could be thinned out as well.
Suggestion: start with easy things such as using a more concise anchor text like "Privacy" rather than "Privacy Policy", "Contact" rather than "Contact Us", "Advertise" rather than "Advertise on This Site" and so on.
As far as conciseness goes, it's been that way since day 1 so there isn't much I can do there.
But buckworks' comment got me thinking (emphasis is mine):
One of the biggest problems with a large footer is that it's a substantial block of content that is identical from one page to the next. That can have the effect of swamping your unique content and making a lot of your pages look "too similar" to the spiders.
Since Google can (most of the time) recognize site's unique template, i.e. markup and content that is identical from page to page within a site, in this particular case wouldn't it just recognize it as such, and score it accordingly, regardless of the "size AND content" of template ? What I mean is that algo would look at the document, separate template, and rate unique content (I think that for overall document's score template plays a part, but it's given different (less) weight then unique content)).
Above thinking brings out two extremes:
- no unique content, just a template - it can be viewed as a stub, and/or dup content, and scored as such (low score, etc.)
- large template, but even larger unique content (much larger then a template) - overall score is dominated by large content's score
But, above thinking has a flow that assumes that content should be comparatively larger in order to dominate document's score. If we take a stance that content is rated on uniqueness / (search term) relevancy, then it could be very, very small and still score very well (a la dictionary - large template and very small content).
And this completes the circle back to the question, if (recognized) template is very large does it matter much?
there is a point in here somewhere but I had too much coffee :)
However, just to make their job easier, I think it's a good idea to make sure any footer content is in its own div and not just a set of <p> and <br> tags that flow right from the content div,
If Google's ability to recognize the tempate was free of problems, I doubt that we'd see the top menu lables in the description snippet as often as we do.However, just to make their job easier, I think it's a good idea to make sure any footer content is in its own div and not just a set of <p> and <br> tags that flow right from the content div,
Agree - that's why I tried to emphasize "recognized template". In order to make SE's job a bit easier, as well as my organization and editing, my pages are divided into few "container" div-s ( a la header, content, nav, footer ), with markup exactly the same (including div names, structure (especially div loading order), etc.). Whenever possible I also keep header, nav, and footer markup exactly the same across pages. Content div is diverse and made to sooth subject, presentational, seo, etc. goals.
It's very easy structure to figure out, and it appears that Google does not have any problems with it.
So from structural standpoint consistency is preserved, it just happens that there is no content in the div. I also include it because of ease of editing (be it static or dynamic)
Does this really matter to SE's algos? I don't know. My bet is that it doesn't hurt, and so far it has worked well for me. I do it based on programming experience - I wrote quite a few 'parsing' aps, and one thing that can throw a wrench into inserting/extracting data is unconsistancy. Let's say that you have a document set and want to analyze individual documents and extract data - in a nutshell you would want to:
- determine document structure (schema)
- identify fields of interest
- extract data of interest
Depending how you algorithm works, it might be sensitive to bunch of parameters (for example - order of elements). If in majority of documents you have all the fields (and are confident about structure), you chug along happily, but then you come across document which is missing a field. You, or your algo, will stop to examine what and why is different about this document, and how detected differences fit with greater document set...This is very simplistic example but hopefully it illustrates some of the potential issues. Also remember that html doesn't declare schema...
Long story short, and in this context, to algo empty div is not same absence of the div. While G's algo is sophisticated, and can (most likely) deal with this simplistic example, things can get complicated in a hurry..