|How to get main text "before" other body html ?|
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?
Hello janisk, and welcome to WebmasterWorld!
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 !! :)
I don't know if it's just me, but I've had troubles with Netscape 6 table rendering using this method. The longer the Main Body section gets, the larger the space above the left column gets. I haven't been able to massage tables like this to work with this browser.
I just used an older version of Netscape (4.03) to check a page on which I'd had the webmaster use this trick... same problem (blush).
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.
You can also do the job with CSS. Users without CSS would see the text in the order it occurs in the file, though, and NN4 has some significant problems with CSS positioning.
Another HTML-only alternative would be to specify that the table cells occur right-to-left. Anybody recall offhand which browsers support this?
Have never heard of table cells being read right to left, and can't find any reference to it. You can, of course, put the navbar on the right hand side... I wouldn't go near CSS positioning.
This table trick has been around long enough that I'm thinking there must be a way to make it work, but maybe not... :(
How about this: Use a transparent 1x1 gif, redrawn by the browser to fill in the height of the navigation table cell.
That is, after the content of the left hand navigation finishes and before you close the cell tag add:
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.
|<br><img src="transparent.gif" width="1" height="3000"> |
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.
Tedster - Thanks... Sounds like a great idea. For now, I'm leaving it to the web designer to try it, but will definitely give you a report. I'll also be playing with it myself, but not right now on this site.
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?
Different font sizes would definitely be an issue, but probably nothing to worry about.
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.
Ah, here we go...
<td dir="ltr">col 1</td>
<td dir="ltr">col 2</td>
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.
Greg, you've done it again. I never thought of directionality, which probably enjoys wide support since there are many right to left languages. Thanks.
Here's the W3C reference:
Tested gmiller's idea out with a few browsers to see which ones supported directionality.
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.
Thanks for the work on that Bill. It's good info to have, even if a bit disappointing.
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.
>wouldn't go near CSS positioning.
Robert, why wouldn't youu go near CSS positioning? Is it a browser issue, or something risky re: search engines?
Browsers.... I've seen the reactions of corporate executives looking at expensive, fancy sites with body text superimposed haphazardly over nav bars, etc. The reactions weren't pretty.
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.
I just read a page at Alta Vista that discusses this table trick and a number of workarounds for the "Netscape" problem.
(edited by: tedster at 2:24 pm (utc) on Mar. 18, 2002)
Great find, Tedster. Thank you. On the site I was working on (mentioned above), now that we fixed some coding problems that were inherited from the site builders, I haven't been able to make our tables misbehave, even in NS 4x, but I don't doubt the problem happens.
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 can't take the credit. Someone shared it on one of the email lists I belong to, so I don't know how it fits into AV either.
I think I'd also like to give a salute here to right hand menus. The more I see of them the more I like them. The nav choices are right by the scroll bar -- less movement and therefore more ergonomic. And of course, the whole problem this thread addresses just doesn't exist.
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.
>>I think I'd also like to give a salute here to right hand menus.<<
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-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.
Now, I have a further question about all this, and I hope I'm not accused of heresy for asking. Let's say I'm playing devils advocate.
The heretical question is: how distracting to search is code that isn't "indexed" by search engines?
- 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 heretical question is: how distracting to search is code that isn't "indexed" by search engines? <<
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.
The question I asking here isn't about overall file size, since those elements would be on the page whether I used the table trick or not. The question is, are the elements sufficiently in the way (ie, between the top of the page and my optimized text), as seen by spiders, to justify fooling with the table trick?
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.
About the right hand nav bar...
Just lost the battle today. Client wouldn't even consider it. Too unconventional....