> p.s., ivb, don't flatter yourself. I have an 8 year old Russian
> Wolfhound that I have to follow around with a little plastic bag every > time I let him outside. As ironic as it may seem, guess what his name > is. ;-)
You guys crack me up. Igor, I'll never say my website design is perfect, but the team and I know a lick of CSS, yes. I'm not scared to post the url for competition purposes if that's what you are getting at, it's free for them to look at anytime anyway and I know they do considering the number of features we have that have been copied :)
Craig, I'm with you on the intent thing, I just think it is actually really hard for google to spot intent and I know when googlebot makes mistakes it can be painful... I think making guidelines like these make it even harder for webmasters who do land in the doghouse to know what to fix and what not to fix. I should go add this to the 'suggestions for webmaster central post' though, as essentially my problem is not with the guidelines but giving webmasters the information they need to make the fixes they have to. Some kind of information like 'googlebot might be having a problem with *list of items*' would be perfect - hey I can engage in wishful thinking right? :)
Sam, I am glad your team knows CSS! How do you guys make money? I see no advertising programs, just some affiliate stuff, that I do not think people buy anyway.
> > p.s., ivb, don't flatter yourself. I have an 8 year old Russian
> > Wolfhound that I have to follow around with a little plastic bag every > > time I let him outside. As ironic as it may seem, guess what his name > > is. ;-)
> You guys crack me up. Igor, I'll never say my website design is > perfect, but the team and I know a lick of CSS, yes. I'm not scared to > post the url for competition purposes if that's what you are getting > at, it's free for them to look at anytime anyway and I know they do > considering the number of features we have that have been copied :)
> Craig, I'm with you on the intent thing, I just think it is actually > really hard for google to spot intent and I know when googlebot makes > mistakes it can be painful... I think making guidelines like these > make it even harder for webmasters who do land in the doghouse to know > what to fix and what not to fix. I should go add this to the > 'suggestions for webmaster central post' though, as essentially my > problem is not with the guidelines but giving webmasters the > information they need to make the fixes they have to. Some kind of > information like 'googlebot might be having a problem with *list of > items*' would be perfect - hey I can engage in wishful thinking > right? :)
> Sam, I am glad your team knows CSS! > How do you guys make money? > I see no advertising programs, just some affiliate stuff, that I do > not think people buy anyway.
> Igor
> On Jun 8, 5:32 pm, Sam I Am wrote:
> > > p.s., ivb, don't flatter yourself. I have an 8 year old Russian
> > > Wolfhound that I have to follow around with a little plastic bag every > > > time I let him outside. As ironic as it may seem, guess what his name > > > is. ;-)
> > You guys crack me up. Igor, I'll never say my website design is > > perfect, but the team and I know a lick of CSS, yes. I'm not scared to > > post the url for competition purposes if that's what you are getting > > at, it's free for them to look at anytime anyway and I know they do > > considering the number of features we have that have been copied :)
> > Craig, I'm with you on the intent thing, I just think it is actually > > really hard for google to spot intent and I know when googlebot makes > > mistakes it can be painful... I think making guidelines like these > > make it even harder for webmasters who do land in the doghouse to know > > what to fix and what not to fix. I should go add this to the > > 'suggestions for webmaster central post' though, as essentially my > > problem is not with the guidelines but giving webmasters the > > information they need to make the fixes they have to. Some kind of > > information like 'googlebot might be having a problem with *list of > > items*' would be perfect - hey I can engage in wishful thinking > > right? :)
> We get paid to post on forums like this. Don't you? :)
> On Jun 8, 10:52 am, ivb wrote:
> > Sam, I am glad your team knows CSS! > > How do you guys make money? > > I see no advertising programs, just some affiliate stuff, that I do > > not think people buy anyway.
> > Igor
> > On Jun 8, 5:32 pm, Sam I Am wrote:
> > > > p.s., ivb, don't flatter yourself. I have an 8 year old Russian
> > > > Wolfhound that I have to follow around with a little plastic bag every > > > > time I let him outside. As ironic as it may seem, guess what his name > > > > is. ;-)
> > > You guys crack me up. Igor, I'll never say my website design is > > > perfect, but the team and I know a lick of CSS, yes. I'm not scared to > > > post the url for competition purposes if that's what you are getting > > > at, it's free for them to look at anytime anyway and I know they do > > > considering the number of features we have that have been copied :)
> > > Craig, I'm with you on the intent thing, I just think it is actually > > > really hard for google to spot intent and I know when googlebot makes > > > mistakes it can be painful... I think making guidelines like these > > > make it even harder for webmasters who do land in the doghouse to know > > > what to fix and what not to fix. I should go add this to the > > > 'suggestions for webmaster central post' though, as essentially my > > > problem is not with the guidelines but giving webmasters the > > > information they need to make the fixes they have to. Some kind of > > > information like 'googlebot might be having a problem with *list of > > > items*' would be perfect - hey I can engage in wishful thinking > > > right? :)- Hide quoted text -
Just wanted to let you know that I asked Matt about this at SMX last week (I'm a big fan of accessibility and image replacement, so I was curious about some of the same things you've brought up in this thread). Craig is correct in saying that your intent (in hiding text, or in using any technique that has the potential to be abused) is important. If your intent in hiding text is to deceive the search engines, we frown on that; if your intent is purely to improve the visual user experience (e.g. by replacing some text with a fancier image of that same text), you don't need to worry.
Of course, as with many techniques, there are shades of gray between "this is clearly deceptive and wrong" and "this is perfectly acceptable". Matt did say that hiding text moves you a step further towards the gray area. But if you're running a perfectly legitimate site, you don't need to worry about it. If, on the other hand, your site already exhibits a bunch of other semi-shady techniques, hidden text starts to look like one more item on that list. It's like how 1 grain of sand isn't noticeable, but many grains together start to look like a beach.
As the Guidelines say, focus on intent. If you're using CSS techniques purely to improve your users' experience and/or accessibility, you shouldn't need to worry. One good way to keep it on the up-and-up (if you're replacing text w/ images) is to make sure the text you're hiding is being replaced by an image with the exact same text.
> is to make sure the text you're > hiding is being replaced by an image with the exact same text.
I think that is where most people run into trouble, just as Danny (Not of Gilbert &) Sullivan did when his site got somewhat erroneously picked apart in another forum.
One problem with all replacement or many advanced DHTML techniques in general is keeping the on-page code and the replacement content in sync and up to date.
Me being lazy, I tend to avoid such techniques but then again, I like boring-as-a-mud-fence web sites more out of self defense than as a fashion statement. :-()
Craig
P.s. Thanks for dropping by on this one Susan, I can understand why Googlers don't comment on every post as 99.9999% of them are the same but it is good to see your input on unique matters like this that come up from time to time. Consider this one bookmarked!! :-)
Out of curiosity, how is intent determined algorithmically? Given that Google isn't going to hand-evaluate each flagged site, does this mean that if the algorythm sees enough grains of sand that then there may be some penalty?
> Just wanted to let you know that I asked Matt about this at SMX last > week (I'm a big fan of accessibility and image replacement, so I was > curious about some of the same things you've brought up in this > thread). Craig is correct in saying that your intent (in hiding text, > or in using any technique that has the potential to be abused) is > important. If your intent in hiding text is to deceive the search > engines, we frown on that; if your intent is purely to improve the > visual user experience (e.g. by replacing some text with a fancier > image of that same text), you don't need to worry.
> Of course, as with many techniques, there are shades of gray between > "this is clearly deceptive and wrong" and "this is perfectly > acceptable". Matt did say that hiding text moves you a step further > towards the gray area. But if you're running a perfectly legitimate > site, you don't need to worry about it. If, on the other hand, your > site already exhibits a bunch of other semi-shady techniques, hidden > text starts to look like one more item on that list. It's like how 1 > grain of sand isn't noticeable, but many grains together start to look > like a beach.
> As the Guidelines say, focus on intent. If you're using CSS techniques > purely to improve your users' experience and/or accessibility, you > shouldn't need to worry. One good way to keep it on the up-and-up (if > you're replacing text w/ images) is to make sure the text you're > hiding is being replaced by an image with the exact same text.
> Out of curiosity, how is intent determined algorithmically? Given that > Google isn't going to hand-evaluate each flagged site, does this mean > that if the algorythm sees enough grains of sand that then there may > be some penalty?
Hi Richard This is just my wild guess, but my guess is that you have to look at the larger picture. As Susan said, "many grains of sand" ... assume every grain of sand is a signal that is sent by your website. CSS image replacement is just a tiny bit more than hiding content on your page (except that the place where the hidden content should be is filled with an image or similar). Hidden content through CSS is mostly easy to recognize algorithmically. That's a grain of sand. If you're replacing headers, that's probably another grain of sand (aka "signal"). If your javascript does strange redirects, that's some more, if your pages uses 10 lines of alt-text for a 1x1 pixel image that's probably some more.
If you have enough grains of sand, if the Googlebot brings his beach- towel when visiting your site, then chances are you've either gone too far or things are being misinterpreted.
My guess is that there is a threshold of "sand" that brings a site into a queue for a manual review. This is where intent and replacing content with the same content in an image comes along. If things look good, no problem, your personal threshold might get adjusted or things might get updated in the algorithm, etc. This kind of review is probably rare and I bet the queue is pretty long.
However, there is likely also a threshold where the Googlebot brings a bulldozer instead of a beach-towel. That much sand just can't be an accident. With that many signals being sent, it can be assumed that the site is in fact doing something wrong on purpose (and I bet most of the time they're right). These sites are likely to be penalized automatically.
It's a bit like my email spam-filter works: it assigns a score based on many, many rules. Below a certain number is ok, within a range slightly above it's placed in a check-these queue, with a score way above that it's automatically discarded.
I'll assume that the automatic penalties are pretty much ok, if you have that many spam-signals in your site, then you're either doing a whole lot of things wrong on accident or you're doing it on purpose. The middle range is a bit harder: are they penalized with a pseudo- penalty or are they really manually queued?
Also, which kind of items cause how many grains of sand? Hiding text with CSS? Content duplicated from other sites? Sneaky javascript? Stuffed headers? Link-exchanges? Links to strange sites? Interesting things!!
I don't think you have anything to worry about with regard to intent, but there are a couple of things that you might want to consider...
You might avoid a "grain of sand" if you don't give the spans in your menu a class of "hidden", that's got to ring some alarm bells somewhere. You don't need a class there at all, just apply your css to
#primary_navigation span, #navigation_search span { ...rules in here... }
You should also be aware that using display:none for this text can cause problems for screen reader users. Not only do regular browsers not show the text (which is what you want), many screen readers don't read it out either (which isn't). If you only want to hide text visually, but still get it read out, use absolute positioning to "display" the text somewhere off the screen, say at top:-9999px . http://www.google.com/search?q=screen+reader+display+none will find plenty of stuff on this issue.
i had a page that i could not get fully indexed for months until i noticed in the CSS it had a -50px for one of its many layers. I fixed it to remove the negative and a week later it was fully indexed and remains so. My view is that any negative in CSS either for images or layers will be attract a negative score in google.
> i had a page that i could not get fully indexed for months until i > noticed in the CSS it had a -50px for one of its many layers. I fixed > it to remove the negative and a week later it was fully indexed and > remains so. My view is that any negative in CSS either for images or > layers will be attract a negative score in google.
Hmm... Strange, yes. So you believe the signals from the CSS files are processed and reacted upon automatically? That would be interesting. (understatement of the day :-))
Did Google crawl your CSS file in that timeframe (assuming you have an external stylesheet)?
CSS files can be so complicated with regards to that crazy "cascading" -- a tiny change in the (x)HTML page could move contents into a completely different style, relative values get mixed with absolute values and who knows how many browser dependent hacks even exist and how they in turn cascade. I don't even want to mention Javascript or different output media, lol. Is hiding content for mobile browsers a bad thing?
All these things would make it very problematic to react to CSS files automatically.
You wouldn't want to change that to -50px again, would you? just to see what happens :-). Afterwards you can change it back to +9999px :-))
I would think it depends. I have a negative margin on a number of elements and that hasn't seemed to effect anything negatively. (pun not necessarily intended)
The -50px that you had, what was it, element height or width, font size, line height and what was it being applied to?
> i had a page that i could not get fully indexed for months until i > noticed in the CSS it had a -50px for one of its many layers. I fixed > it to remove the negative and a week later it was fully indexed and > remains so. My view is that any negative in CSS either for images or > layers will be attract a negative score in google.
> You wouldn't want to change that to -50px again, would you? just to > see what happens :-). Afterwards you can change it back to > +9999px :-))
That would be sort of much to ask of silverstall as it could cause the loss of a page but if silverstall could find an element on one of my pages that would appear to be suitable, I'd be more than happy to try it out as I have a number of pages that while indexed, don't bring in a lot of traffic from SEs so losing one of them temporarily would be no great loss.
Of course it would be best if silverstall could try to duplicate the results on the same page but not wanting to lose a page would be understandable. ;-)
> The -50px was the positioning > of a nested layer - it was 'top' .
Interesting. I'd have to take a stab at it though and say I think it had to either have been coincidental or the css algo, if there is such a beast, had to have been crudely created or amazingly intelligent because a top:-50px style rule could either have no untoward rendering effect, meaning the supposed algo is crude or under some conditions, could have a rendering effect meaning the supposed algo was amazingly intelligent. I sort of have a hard time believing either scenario but who knows. It is interesting in any event!
> I'm convinced the impact is > relatively small but if a page such as the one i worked is just > slightly on the wrong side of a quality threshold that small > difference was enough to push it over to the right side.
That"s what Susan and JohnMu seemed to be saying as well, a bunch of little steps in the wrong direction and all of a sudden you are floating in air, briefly for a nanosecond before plunging 1,000 meters straight down. :-()
> As usual this > is all specualtion as for all i know it could have co-incided with an > unknown source deciding to link to that page etc.
True, which is what I think is the case but the timing and the other things you mentioned, it definitely would make one wonder!
> Running css.stylesheets through the W3C CSS validator often produces > warnings about same colour backround/text etc which the > motoricerca.info/spam-detector/ does not detect - i wonder therefore > if googles alogs are more closely in tune with the W3C CSS checker.
Validating a style sheet would be about as useless as validating the HTML. Either one can be perfectly valid yet render nothing but garbage and vice versa.
Looking for "signals" on the other hand, might not be all that difficult although were one to get a bad case of div-itis or table- itis or worse, a combination of both, I could see that making things extremely difficult.
> Maybe google allocates to a site a percentage of permissable 'static' > pages against dynamic/fresh content pages because despite it being a > static page with a history of little or no changes, it has a good serp > position. Other pages i have to change almost daily to maintain their > position and therefore i am loathed to change it back to -50px in > case it moves the page into the 'needs to be a fresh and updated' > field.
I doubt the static/dynamic/fresh thingy. I've seen too many sites that haven't been updated in literally half a decade that still rank well, as much as I wish they wouldn't. :-()
But at the same time, maybe the -50px was a negative signal and it added to something else. Only Google knows and is unlikely to give up her secrets any time soon. ;-)
I know, we should start a "-50px penalty" and see if we can get other forums to go crazy on it. I bet it wouldn't be all that hard! :-()
> 'So you believe the signals from the CSS files are processed and > reacted upon automatically?' - if they did not, then how would Googles > cached pages have all the styling acquired from an external css. i.e > the css is crawled at the same time.
Google's cache has everything, up to and including any javascript used on the page. The Google stuff that is added sometimes conflicts or causes problems with a given page's styling but the cache is the entire page and all its contents.
Hi guys - the css was in fact inline on the page and the -50px related to the top position of a nested layer. I made no other changes on it (except i now remember at the time it enjoyed a spasmodic spike in hits because of an image of a girl on the page wearing a silver cross who subsqeuntly turned out to be a ladyboy) The css on the page was frankly a mess complicated by nesting paypal tables inside nested layers so maybe the change could have simpy just made it more crawlable although i am still confused as to whether or how google read an external css. If google has a cached copy of a page it maintains all the syling from an external css presumably in the same way as images i.e through the links on the page - or does it actually somewhere index the external css itself ?
Thanks casshacks - sorry i had to remove the earlier post because on double checking the page i realised it did not have an external css - duh my bad.
'I doubt the static/dynamic/fresh thingy. I've seen too many sites that haven't been updated in literally half a decade that still rank well, as much as I wish they wouldn't. :-() ' maybe that is true for one of their pages (maybe even the homepage) but how has all their other pages ranked?
> As the Guidelines say, focus on intent. If you're using CSS techniques > purely to improve your users' experience and/or accessibility, you > shouldn't need to worry. One good way to keep it on the up-and-up (if > you're replacing text w/ images) is to make sure the text you're > hiding is being replaced by an image with the exact same text.
I'm planning on using CSS hiding systematically to allow me to create sets of pages that can be viewed either on screens or on handhelds. There's a lot of room on a screen for decorative stuff and other things.
For example, on some pages I want the copyright statement at the top on a screen and at the bottom on a handheld. So I put both in the XHTML. An @media screen display:none for the class used in the bottom statement and an @media handheld display:none for the class used in the top statement is the most elegant way to go - one XHTML page and one CSS serves both media.
I don't see that Google can progammatically verify what CSS does anyway. First it would double the crawling bandwidth needed, and secondly it would be trivial to serve the Googlebot with an innocuous CSS.
How did you get the css to tilt the image like that?
Or, am I thinking of the wrong curiosity here? :-()
As for how the "other" pages ranked, these pages were pretty much one hit wonders. Many "sites" during that time period were no more than a single page that someone tossed up and then seemed to have forgotten about. But then again, all bets are off for a single page web site because it would seem to be either a 100% on or 100% off situation.
Craig
p.s. what did I miss that a ladyboy got into this conversation? I can see I am going to have to be paying a LOT more attention! :-()
> I don't see that Google can progammatically verify what CSS does > anyway. First it would double the crawling bandwidth needed, and > secondly it would be trivial to serve the Googlebot with an innocuous > CSS.
I don't see how it would double any bandwidth, if Google indexes the pages it already has everything referenced in the page.
And of course it would be trivial to serve the Googlebot an innocuous CSS but the same could be said for serving the bot anything innocuous while serving everyone else something different. CSS, HTML, Javascript, wouldn't really matter.
I could think of a trivial brute-force method for determining to a certain extent what CSS does, render the page and then run an OCR over it.
I'm not saying how likely it is that Google does that but where there is a trivial brute-force method thought up by a Neanderthal, like me, there is usually a more elegant and efficient method possible to someone who knows what they are doing, e.g. Google-heads.
Susan, thanks so much for stopping by and answering the question! I noticed a few other sites picking up on the answer already and I can imagine it will trickle down into the standards based community quite quickly too. It's good to know you have nothing to worry about if your intent is solid, but that even if your intent is solid and you have a few of these gray areas piling up it might result in something. At least that gives someone 'in the doghouse' something to look at if the cause for this might otherwise not be clear.
Given that further reading up on this method shows that there's quite a few caveats when it comes to screen readers anyway (although it's a great solution for mobile browsers who are an increasingly important group to look at) I'm going to take a fresh look at a text based solution as well. Chris, thank you for the pointers. It does seem like a more viable alternative, although I'm now thinking avoiding all the extra spans is the most semantically correct way to go in the long run anyway. It's just a shame there's not more alternatives in terms of fonts really!
> > I don't see that Google can progammatically verify what CSS does > > anyway. First it would double the crawling bandwidth needed, and > > secondly it would be trivial to serve the Googlebot with an innocuous > > CSS.
> I don't see how it would double any bandwidth, if Google indexes the > pages it already has everything referenced in the page.
> And of course it would be trivial to serve the Googlebot an innocuous > CSS but the same could be said for serving the bot anything innocuous > while serving everyone else something different. CSS, HTML, > Javascript, wouldn't really matter.
> I could think of a trivial brute-force method for determining to a > certain extent what CSS does, render the page and then run an OCR over > it.
> I'm not saying how likely it is that Google does that but where there > is a trivial brute-force method thought up by a Neanderthal, like me, > there is usually a more elegant and efficient method possible to > someone who knows what they are doing, e.g. Google-heads.
> Susan, thanks so much for stopping by and answering the question! I > noticed a few other sites picking up on the answer already and I can > imagine it will trickle down into the standards based community quite > quickly too. It's good to know you have nothing to worry about if your > intent is solid, but that even if your intent is solid and you have a > few of these gray areas piling up it might result in something. At > least that gives someone 'in the doghouse' something to look at if the > cause for this might otherwise not be clear.
> Given that further reading up on this method shows that there's quite > a few caveats when it comes to screen readers anyway (although it's a > great solution for mobile browsers who are an increasingly important > group to look at) I'm going to take a fresh look at a text based > solution as well. Chris, thank you for the pointers. It does seem like > a more viable alternative, although I'm now thinking avoiding all the > extra spans is the most semantically correct way to go in the long run > anyway. It's just a shame there's not more alternatives in terms of > fonts really!
> On Jun 11, 5:39 pm, cass-hacks wrote:
> > > I don't see that Google can progammatically verify what CSS does > > > anyway. First it would double the crawling bandwidth needed, and > > > secondly it would be trivial to serve the Googlebot with an innocuous > > > CSS.
> > I don't see how it would double any bandwidth, if Google indexes the > > pages it already has everything referenced in the page.
> > And of course it would be trivial to serve the Googlebot an innocuous > > CSS but the same could be said for serving the bot anything innocuous > > while serving everyone else something different. CSS, HTML, > > Javascript, wouldn't really matter.
> > I could think of a trivial brute-force method for determining to a > > certain extent what CSS does, render the page and then run an OCR over > > it.
> > I'm not saying how likely it is that Google does that but where there > > is a trivial brute-force method thought up by a Neanderthal, like me, > > there is usually a more elegant and efficient method possible to > > someone who knows what they are doing, e.g. Google-heads.
Sam & Am it is nice that a high quality Webmaster like you finally figured out not to use hidden! I have been saying it for months but you guys all think you are something special! Even before Google updated the Quality Guideliness it said do not use hidden!
Sam, now maybe you can get rid off your paid text links and you will be on the way......
> Reinclusion request submitted and fingers crossed it was caused by > googlebot misinterpreting the class="hidden" showing up in our > navigation!
> On Jun 12, 1:18 pm, Sam I Am wrote:
> > Susan, thanks so much for stopping by and answering the question! I > > noticed a few other sites picking up on the answer already and I can > > imagine it will trickle down into the standards based community quite > > quickly too. It's good to know you have nothing to worry about if your > > intent is solid, but that even if your intent is solid and you have a > > few of these gray areas piling up it might result in something. At > > least that gives someone 'in the doghouse' something to look at if the > > cause for this might otherwise not be clear.
> > Given that further reading up on this method shows that there's quite > > a few caveats when it comes to screen readers anyway (although it's a > > great solution for mobile browsers who are an increasingly important > > group to look at) I'm going to take a fresh look at a text based > > solution as well. Chris, thank you for the pointers. It does seem like > > a more viable alternative, although I'm now thinking avoiding all the > > extra spans is the most semantically correct way to go in the long run > > anyway. It's just a shame there's not more alternatives in terms of > > fonts really!
> > On Jun 11, 5:39 pm, cass-hacks wrote:
> > > > I don't see that Google can progammatically verify what CSS does > > > > anyway. First it would double the crawling bandwidth needed, and > > > > secondly it would be trivial to serve the Googlebot with an innocuous > > > > CSS.
> > > I don't see how it would double any bandwidth, if Google indexes the > > > pages it already has everything referenced in the page.
> > > And of course it would be trivial to serve the Googlebot an innocuous > > > CSS but the same could be said for serving the bot anything innocuous > > > while serving everyone else something different. CSS, HTML, > > > Javascript, wouldn't really matter.
> > > I could think of a trivial brute-force method for determining to a > > > certain extent what CSS does, render the page and then run an OCR over > > > it.
> > > I'm not saying how likely it is that Google does that but where there > > > is a trivial brute-force method thought up by a Neanderthal, like me, > > > there is usually a more elegant and efficient method possible to > > > someone who knows what they are doing, e.g. Google-heads.
Well, to be quite honest it does exactly the same thing, it just doesn't say class="hidden" in the html.... effect is the same, but this eliminates one likelihood of googlebot making a mistake when assessing that content. If anything this is actually more spammy than the other way around though, since now it's harder instead of easier for googlebot to see that the text is hidden. But hey, I can live with that if that is what Google wants!
And with paid text links I guess you mean those ones with rel="nofollow" on them?
Any more comments you'd like to contribute without taking a second look? :)
> Sam & Am it is nice that a high quality Webmaster like you finally > figured out not to use hidden! > I have been saying it for months but you guys all think you are > something special! > Even before Google updated the Quality Guideliness it said do not use > hidden!
> Sam, now maybe you can get rid off your paid text links and you will > be on the way......
> Igor
> On Jul 4, 7:01 pm, Sam I Am wrote:
> > Reinclusion request submitted and fingers crossed it was caused by > > googlebot misinterpreting the class="hidden" showing up in our > > navigation!
> > On Jun 12, 1:18 pm, Sam I Am wrote:
> > > Susan, thanks so much for stopping by and answering the question! I > > > noticed a few other sites picking up on the answer already and I can > > > imagine it will trickle down into the standards based community quite > > > quickly too. It's good to know you have nothing to worry about if your > > > intent is solid, but that even if your intent is solid and you have a > > > few of these gray areas piling up it might result in something. At > > > least that gives someone 'in the doghouse' something to look at if the > > > cause for this might otherwise not be clear.
> > > Given that further reading up on this method shows that there's quite > > > a few caveats when it comes to screen readers anyway (although it's a > > > great solution for mobile browsers who are an increasingly important > > > group to look at) I'm going to take a fresh look at a text based > > > solution as well. Chris, thank you for the pointers. It does seem like > > > a more viable alternative, although I'm now thinking avoiding all the > > > extra spans is the most semantically correct way to go in the long run > > > anyway. It's just a shame there's not more alternatives in terms of > > > fonts really!
> > > On Jun 11, 5:39 pm, cass-hacks wrote:
> > > > > I don't see that Google can progammatically verify what CSS does > > > > > anyway. First it would double the crawling bandwidth needed, and > > > > > secondly it would be trivial to serve the Googlebot with an innocuous > > > > > CSS.
> > > > I don't see how it would double any bandwidth, if Google indexes the > > > > pages it already has everything referenced in the page.
> > > > And of course it would be trivial to serve the Googlebot an innocuous > > > > CSS but the same could be said for serving the bot anything innocuous > > > > while serving everyone else something different. CSS, HTML, > > > > Javascript, wouldn't really matter.
> > > > I could think of a trivial brute-force method for determining to a > > > > certain extent what CSS does, render the page and then run an OCR over > > > > it.
> > > > I'm not saying how likely it is that Google does that but where there > > > > is a trivial brute-force method thought up by a Neanderthal, like me, > > > > there is usually a more elegant and efficient method possible to > > > > someone who knows what they are doing, e.g. Google-heads.
Sam I am not trying to bash you, but to educate you.
If you going to link to someone drop the nofollow!
If you going to have a directory make it free or paid but do not mix the two!
If a Website is crappy paid or not paid, follow or not follow do not recommend it in your directory!
So, drop the nofollow, and decide do you want to give a free vote or get paid for the service of evaluating the Website before including it in your directory.
You may think I am biased because I am a Webmaster for a Travel Agency, but I am not.
The travel agents and small hotels are your friends, so show them some support and link to them for free without a nofollow, good Karma spreads around!!!
So if you think this hotel or travel agent is great and provides good service, give a nice link.....
> Well, to be quite honest it does exactly the same thing, it just > doesn't say class="hidden" in the html.... effect is the same, but > this eliminates one likelihood of googlebot making a mistake when > assessing that content. If anything this is actually more spammy than > the other way around though, since now it's harder instead of easier > for googlebot to see that the text is hidden. But hey, I can live with > that if that is what Google wants!
> And with paid text links I guess you mean those ones with > rel="nofollow" on them?
> Any more comments you'd like to contribute without taking a second > look? :)
> On Jul 4, 12:53 pm, ivb wrote:
> > Sam & Am it is nice that a high quality Webmaster like you finally > > figured out not to use hidden! > > I have been saying it for months but you guys all think you are > > something special! > > Even before Google updated the Quality Guideliness it said do not use > > hidden!
> > Sam, now maybe you can get rid off your paid text links and you will > > be on the way......
> > Igor
> > On Jul 4, 7:01 pm, Sam I Am wrote:
> > > Reinclusion request submitted and fingers crossed it was caused by > > > googlebot misinterpreting the class="hidden" showing up in our > > > navigation!
> > > On Jun 12, 1:18 pm, Sam I Am wrote:
> > > > Susan, thanks so much for stopping by and answering the question! I > > > > noticed a few other sites picking up on the answer already and I can > > > > imagine it will trickle down into the standards based community quite > > > > quickly too. It's good to know you have nothing to worry about if your > > > > intent is solid, but that even if your intent is solid and you have a > > > > few of these gray areas piling up it might result in something. At > > > > least that gives someone 'in the doghouse' something to look at if the > > > > cause for this might otherwise not be clear.
> > > > Given that further reading up on this method shows that there's quite > > > > a few caveats when it comes to screen readers anyway (although it's a > > > > great solution for mobile browsers who are an increasingly important > > > > group to look at) I'm going to take a fresh look at a text based > > > > solution as well. Chris, thank you for the pointers. It does seem like > > > > a more viable alternative, although I'm now thinking avoiding all the > > > > extra spans is the most semantically correct way to go in the long run > > > > anyway. It's just a shame there's not more alternatives in terms of > > > > fonts really!
> > > > On Jun 11, 5:39 pm, cass-hacks wrote:
> > > > > > I don't see that Google can progammatically verify what CSS does > > > > > > anyway. First it would double the crawling bandwidth needed, and > > > > > > secondly it would be trivial to serve the Googlebot with an innocuous > > > > > > CSS.
> > > > > I don't see how it would double any bandwidth, if Google indexes the > > > > > pages it already has everything referenced in the page.
> > > > > And of course it would be trivial to serve the Googlebot an innocuous > > > > > CSS but the same could be said for serving the bot anything innocuous > > > > > while serving everyone else something different. CSS, HTML, > > > > > Javascript, wouldn't really matter.
> > > > > I could think of a trivial brute-force method for determining to a > > > > > certain extent what CSS does, render the page and then run an OCR over > > > > > it.
> > > > > I'm not saying how likely it is that Google does that but where there > > > > > is a trivial brute-force method thought up by a Neanderthal, like me, > > > > > there is usually a more elegant and efficient method possible to > > > > > someone who knows what they are doing, e.g. Google-heads.
