Forum Moderators: open
I am new to search engine optimization but as I understand it is extremely important that keywords and keyphrases appear in the begining of html body.
My website has menu on left-side with text links.
Since html cell of left-menu appears before right cell where main text is search engine always reads it before main text.
How can I avoid this problem? I want my text to be before all other body html.
I have thought of one solution - I could read all “template-html” from .js file using "document.write" function. Is it ok? What about people, which has turned js off? Are there many such people?
Thanks,
Janis
Using an external js and document.write is one way to go that gives you the advantage of maintaining your navigation in a single file. Server side includes (SSI) can accomplish a similar purpose, and they have the advantage of not needing special browser support. Depending on your audience you may find 2% to 10% with Javascript turned off (to avoid pop-up windows, bad js code, etc.)
There is also an all HTML solution. I can't find it now, but I've seen a page on the web with details for writing the table differently.
The idea is to start with an empty cell at the top of the first column, where your navigation will appear. Fill it with a transparent "spacer" gif that is only 1 pixel high. Then write the next table cell for your body text using rowspan=2, and valign="top". All your body text ends up at the top of the HTML.
When you write the code for next table row with your navigation code, is only nudged down one pixel, and you can make that small sliver "invisible" to the viewer.
I hope I was clear enough. Depending on your design, you may need to modify the details to get your display to look good, but the essential idea is the same -- start with a thin, empty, table cell on top of the left hand navigation, and then rowspan=2 for the body cell.
This is exactly what i need !! :)
What I don't know is whether it might be because there are some non-breaking spaces filling up some spacer columns... it's too late at night to look into it.
I did try reducing the length of the content column by commenting out some text until it was shorter than the navbar... no change.
Anyone else have any experience with this? I really like the difference in page position the trick gives you, but never noticed the Netscape problem before.
Another HTML-only alternative would be to specify that the table cells occur right-to-left. Anybody recall offhand which browsers support this?
This table trick has been around long enough that I'm thinking there must be a way to make it work, but maybe not... :(
That is, after the content of the left hand navigation finishes and before you close the cell tag add:
<br><img src="transparent.gif" width="1" height="3000">That "forces" Netscape to give the second cell enough vertical space. The 3,000 is an arbitrary number for the purpose of the example -- you would choose however much space the particular page needs.
With this workaround, I think it's best to pick the actual height in Explorer, since it takes a bit more space when it renders fonts. This means the Netscape page ends up with some white space at the bottom - which really isn't a problem.
In the case of our particular page, we have a second table across the bottom, so we'd have to sort that out... and I'm concerned with what might happen at different font display sizes. Any further brilliant strokes of inspiration?
I say this because, as I play with the height of the tansparent gif, it seems like Netscape is using some kind of averaging algorithm to allocate the relative heights of those two left hand table cells.
As you increase the height there is only a small bit of space left at the top -- long before it reaches the total height of the layout. It gets close enough so that the Netscape rendering could be considered a very "graceful degrade". So even if someone increased the font size, it wouldn't cause the nav section to drop way down the page -- just a smidgen.
<table dir="rtl">
<tr>
<td dir="ltr">col 1</td>
<td dir="ltr">col 2</td>
</tr>
</table>
That'll fatten up the code a little bit, though. Dunno what (if any) browsers handle directionality according to the spec, and I'm too lazy to experiment with it.
Here's the W3C reference:
[w3.org...]
Browers tested:
Netscape Navigator (2.02, 3.0, 3.01, 3.02, 3.03, 3.04, 4.03, 4.07, 4.08, 6)
Netscape Communicator (4.75)
IE (3.02, 5.01, 5.50)
Opera (4.0, 5.02)
NCSA Mosaic (3.0)
All Windows versions
and the only browsers that this worked with.....
Microsoft Internet Explorer 5.01 & 5.50 and Netscape 6
The dir="rtl" and dir="ltr" are ignored in all other browsers I tried.
I also did a bit more fooling around with using a transparent gif to force Netscape to behave. It seems to work best if it's just shy of filling the entire cell space at normal font sizes.
Unfortunately, every time the content section is updated, it might require a small adjustment to the size of the transparent gif as well. Still, I'm pretty confident it will please a very high percentage of visitors.
Robert, why wouldn't youu go near CSS positioning? Is it a browser issue, or something risky re: search engines?
From the search engine point of view, if I understand correctly what you can do with CSS positioning (if all the browsers worked the same as they were supposed to), I think it could be very helpful for search and could solve issues like this tables problem... but I really haven't explored the possibilities. How do the engines look at this issue? I'm not sure.
[web.archive.org...]
(edited by: tedster at 2:24 pm (utc) on Mar. 18, 2002)
Where did you ever find this AltaVista page, by the way? I can't even figure out where exactly it belongs on AV's site.
I've now got right hand menus on several sites, and I don't see anything that worries me about usability. Even did some informal studies (observing people use the sites without saying anything, then giving them tasks to do, etc.)
I also like the right hand menu on search enigne world very much. I honestly think we'll see more and more.
Tedster - Your ergonomic arguement makes a lot of sense. I'm trying to talk a client into it right now.
In the meantime, here's more...
I saw a note today in I-Search Digest newsletter #321 about further problems and a further fix for the table trick. It's a javascript solution to the problem, which, the writer says, "seems to occur when the height of the right side content is more than twice the height of the navigation bar."
I-Search Archives has I-Search issue #321 here. The post is entitled "Bulletin Board" and is the last one.
Steve Rosenberry, who made the I-Search post, has put a detailed explanation online for his approach, along with some further info, at:
He cites code for the trick that doesn't use a gif in the empty cell, though. I don't know whether this would make a difference.
My interest in the table trick was originally prompted by nav bars with text content. Many nav bars are graphic. They contain href graphic links, possibly alt tags, and possibly javascript rollover code.
The heretical question is: how distracting to search is code that isn't "indexed" by search engines?
- If javascript, for example, isn't indexed by the engines, is it in fact a distraction?
- Are the URLs (with graphics, not link text) seen as a distraction?
- And, if, as in some "quick algos" I've seen, the alt tags are counted as half the weight of a regular word, can we assume that say 8 alt tags might only be a 4 word distraction. Is this enough to go to the trouble of shifting the table structure and getting into the problems we've been discussing? I've been doing using the trick for nav bars with text in them... but I'm wondering about the rest.
The ratio of "indexed" material to the total file size has been an issue in the past, at least. The old AV algo seemed to be affected if I remember correctly, burying pages whose ratio was too far out, no matter what else was happening on the page.
It's an area I pay more attention to in sites that are in more competitive areas. But for the most part, my clients will not go for very simple Jakob Nielsen style pages. So I just minimalize the extras as best I can.
I have a related question for which I should probably start another thread... but in a way it's the same question. When I optimize, I like to keep at least 5 words between repetitions of a target search term. Now, if I don't have words intervening... but instead have graphics (with alt tags), or a graphic nav bar with href URLs intervening, will that suffice as intervening text (to prevent a spam repetition penalty), and how do I figure out how much?
If these elements work as intervening text, separating repetitions of a search term, then a graphic nav bar is somewhat in the way of search, if you follow my line of thought... and using the table trick is worth it.
Sorry if I'm rambling... it's late.
Just lost the battle today. Client wouldn't even consider it. Too unconventional....
