| This 48 message thread spans 2 pages: 48 (  2 ) > > || |
|CSS, SEO and semantics|
Clean code means plain text for seo?
Hello everyone, I must start by saying I am fairly new to the html, xhtml, and css world and completely new to the webmasterworld forums.
I was reading up on some SEO techniques and got to thinking about my new found love for CSS. Since CSS is browser side and the spiders (from my understanding) ignore CSS, does this not mean that in cleaning our code with proper CSS we are also removing many important tags for SEO purposes?
Since in CSS we clean our html or xhtml by moving tags like; <b>, <u>, and <i> to the CSS file we are also removing the weight those tags hold to the spiders in a SEO sense.
I understand that we are still using our h1, h2, h3..., keywords, and keyphrases, but if the CSS is hiding everything else, are we not also making a sacrifice?
Personally I believe that the cleaner code using proper xhtml and css is by far better than the code of old, but just how much in SEO terms are we sacrificing if any?
I would be very interested to read any theories, suggestions, opinions, and/or facts about this topic.
Thank you for your time.
Welcome to WebmasterWorld, Mostever :)
The separation of style and content with CSS actually makes things much easier for a search engine to interpret, since the focus should be on HTML that is used for meaning rather than HTML used for presentation.
|tags like; <b>, <u>, and <i> |
The benefit of using these tags in terms of SEO is at best, very debatable. Semantically speaking, they're meaningless.
"Bold" and "italic" are visual instructions - there's still <em> and <strong> which are explicitly designed to a convey something meaningful, with or without visual aids.
Thank you for the quick reply. I know this topic and possibly further discussion of it may lead off into the SEO range, but I must ask: CSS is design, and because of this "cleaning" effect on the html, xhtml it is in-fact SEO friendly? Meaning the true nature of CSS tags has more SEO weight than the removal of certain html tags.
I'd say that's absolutely right - if you follow best practice in terms of CSS for design and HTML as the "building blocks" for content, then the benefits in terms of ease of interpretation and speed far outweigh any benefit you might get from using deprecated "visual" HTML elements.
A related area worth looking at is accessibility, since, by definition, search engines are visitors who are forced to "read" a page without the aid of, for instance, visual or audio elements.
Once again, thank you very much for your fast reply, and thank you for your time. My first experience here has been great. Hopefully in the near future I can have something positive to add and possibly be of help rather than be in need of help.
The SEs are interested in your content, not the markup used to get it on the page. They are happier with cleaner pages.
<u> is deprecated in HTMl 4.01 Strict and XHTML.
|.....we are also removing the weight those tags hold to the spiders in a SEO sense. |
I am not aware that the 'weight' extends beyond the users experience; though cannot document that that is the case. If the SEs add weight, they certainly have the ability to read the CSS and note font-weight: et cetera.
You may get a lot of push back as to whether it is proper for most people to be using XHTML at all. There are many threads on the subject here. Google site: for an extensive listing.
Cleaner code is ideal for site management and SEs, and am unaware of any downside to separating presentation from framework.
<u> is so confusing I doubt anybody uses it anymore regardless (underline means link in a web context ...)
<b> and <i> while technically for a while falling in disgrace, are basically back in grace in (x)html5, so they probably are still more than alright.
The real pitfall is an overuse of <div> and <span>: "divitis" is what we call it.
If you use semantic markup instead -so that the html makes "sense" without any CSS at all-, you should have SEO benefits without drawbacks unless you're into cheating and then CSS can allow you to cheat more (as most SEs are so far quite inapt at finding the cheats in the CSS -AFAIK-)
Yeah, in creating my first page with my new found love of the xhtml and css, I started to get a case of divitis and had to really do some research to find better ways of implementing.
Thank you everyone for your help. I believe the answer is clear and that creating a quality site with clean code that validates is my first step in SEO.
I've done my bit to turn this off topic for this forum, swa66, apologies. Although in a way it's nice to discuss SEO in a CSS forum ;)
|The SEs are interested in your content, not the markup used to get it on the page |
The web is a tangled mess of code, which counts both for and against the benefits of best practice CSS/HTML. At the same time, code that is difficult to misinterpret has to be better than code likely to be misunderstood.
It's the content that's cheating, though, not the CSS ;)
|"divitis" is what we call it. |
I'm no CSS guru, but I think the reason for that is a lack of understanding of the "cascade". So, everything needs to be in a very specific box, otherwise it can trigger a panic ;)
Yes, the understanding of the cascade can be complex and trying to create clean code and not over indulge in the fact that we can just add another div to solve the problem makes it the much more complex to find a real solution to functional layout while keeping clean seo friendly code in mind.
|<b> and <i> while technically for a while falling in disgrace, are basically back in grace in (x)html5, so they probably are still more than alright. |
The 'disgrace', which was very real, never made any sense to me. I should <span> a class rather than plug in an easy tag? Wouldn't mind seeing multiple <b> options given the range of font-weight: available (though actual rendering varies).
|...does this not mean that in cleaning our code with proper CSS we are also removing many important tags for SEO purposes? |
As mentioned, no, you begin to look at page content and as, "How do I give this meaning to the S.E.'s?
No semantic meaning:
This is my paragraph and it's easy to make it look like a paragraph with line breaks.<br><br>
Ah! It's a paragraph:
<p>This is my paragraph and I may have to create a style to get the look I want, but now it has a meaning, it's a paragraph.</p>
|Personally I believe that the cleaner code using proper xhtml and css is by far better than the code of old.... |
First, ask yourself, why do you use XHTML?
Are you using features that require XHTML?
Is your server generating the content type text/xhtml headers for XHTML pages, or does it generate text/html headers?
XHTML does not necessarily mean "cleaner" code, and you can have extremely clean and semantic code with HTML 4.01 strict or **even** transitional. A good portion of the XHTML doctypes I see are as bad as code in the 90's, using deprecated elements, tables for layout, and invalid junk. Often people choose XHTML thinking it's the "latest and greatest," then generate plain old vanilla HTML in the content. Others don't even know they are choosing a doctype - they use a WYSIWYG editor, and just open a new document. The software makers make this decision for them.
Often I get flamed for not using an XHTML doctype, "it's so 1990's." However the XHTML document type has . . . changed over time, it is no longer the "next big thing" as it was planned. The "next big thing" is HTML 5, when XHTML supporters said HTML was dead.
I raise this point because if you are planning on just outputting plain old HTML, it's not that HTML doctypes are sloppier, or old, or easier, it's because your doctype more accurately describes it's contents. Why say "I'm XHTML" when I'm really just HTML?
The second reason, developers are making this decision based on assumptions that may or may not be true for their projects, never questioning it. Question everything including my input here. :-)
Choosing the best doctype for your site [webmasterworld.com]
Why most of us should NOT use XHTML [webmasterworld.com]
The previous is not speaking out against using XHTML - it has it's purpose. Just stop and ask yourself why you are doing it, and are those reasons valid. In terms of SEO, "clean code," and semantic documents, using XHTML as opposed to HTML is not a factor.
An important note, if you don't read anything else in the links above, follow the first link in Dr. Doc's post. It outlines some very specific points for not using XHTML when you are outputting text/html.
[edited by: rocknbil at 7:49 pm (utc) on Nov. 25, 2009]
@D_Blackwell, no, you shouldn't <span> a class in an attempt to replace <b> and <i>. Those 2 tags are purely presentational. Instead, you should use tags that have semantic meaning. Therefore:
<b> becomes <strong>
<i> becomes <em>
This will give you the visual (presentational) as well as the semantic meaning.
It is true that there is lots of ground to be made up in the xhtml and css land due to the depreciation of certain tags and the frowning of other "non-depreciated" tags. But it seams as though much of the new rules of xhtml and css are based on having clean readable code for the coders rather than true functionality.
Don't get me wrong here, xhtml and css have revolutionized the way we build pages today, but there is still a long ways to go before everyone has a smile on their face (if that is possible).
Nice update to your post. as mentioned in my first post, I am fairly new to html, xhtml, and css. In fact, everything I know (not much at all) is from books, forums, and view source.
I use xhtml and in most cases output plain low grade html, but I use it because the world of standards claims that is where everything is headed and there is no point in learning something that is going to be depreciated.
Now I know I can not believe everything I read, but trying to get and stay on top of all the changes in the world of site development is not exactly a straight forward and easy task.
I truly believe that picking and using xhtml for my standard will allow me to develop the skills I desire in site development and design. It will allow me to pick one "standard" learn it and stick to it.
Really, how much difference is there between xhtml and html? From a beginners view, there is little to now difference other than a few depreciated tags unless you start using the validator, then it is time to get confused and come to this forum for help.
So it seams like all developers are back to waiting on the "standards" people and the browser developers to tell us what we can and can not do. There is something wrong with this situation.
I have little to no understanding of the how and why browsers work, but the browser wars are supposed to be over and it is time that a similar and direct path for all developers is cut and paved.
Learning to develop excellent web pages is difficult enough for many of us without the standards being changed on a regular basis.
Hi mostever, interesting topic you started and some great replies.
I don't think this is anything to do with the browser wars per se. As has been said already the Web is a tangled mess of code which the Browsers and the SE's do a not bad job of interpreting considering ;)
As for yourself and many others yes we believe that the cleaner we can make our code the easier it makes everyones jobs! Browsers can hopefully render it quicker, SE's and text browsers can understand it easier, and CSS works!
Any standard will do HTML or XHTML, (X)HTML is what most of the old school (not the oldest school) use because at one time it was supposed the language of the future, it's likely that HTML5 will become the language of choice for most average Webmasters going forward, although XHTML5 is also available.
HTML4 is the solid grounding no matter which flavour you use, and XHTML is just slightly more strict in that it (if you want it to validate) forces you to use closing tags, or close all elements. This is good basics and I highly recommend anyone to get used to validating their code against an XHTML Doctype whether they intent on using it or not.
Not everyone is aware that there are "implicit" closing tags in HTML4 and therefore they can't understand why an element they haven't closed is not styling like it should (then they blame CSS!) Andy, possibly this is a cause of divitis too?
e.g. it is quite legal to write:
<p>here is some of the items on my list;
However it might not render as you think if you're trying to CSS a background onto that <p>aragraph.. the browsers will implicitly insert a closing </p> just after "list;</p>". Then they will then ignore the closing </p> tag after the </ul>
That is the right thing for them to do, but for those not in the know, that's the start of spaghetti code and why you can't use a <p> to contain other elements ;)
That should have no bearing on the SEO factor of a document either, and all browsers will handle it. However if you'd tried to validate that code against an XHTML doctype the validator would have shown you the error of your ways, and made your CSS troubleshooting a lot easier.
You don't have to use an XHTML Doctype to render the code, and HTML4.01 strict one will do and you have the knowledge that your code is as clean as possible for all, SE's Browsers and your CSS File! ;)
As for the semnatics of <b>, <i>, <em>, <strong> there is no reason for you to remove them from your HTML, it is believed they don't carry that much SEO weight due to abuse in the past but that may change, write the document for the people not the opinion. The argument over whether to use <em> over <i> or <strong> over <b> is purely semantic and I think HTML5 kept the shorter ones in purely because they are shorter, I believe they probably have equal weight nowadays.
However when you're saying that for clean code you want to remove them to the CSS, you don't remove the HTML tag, leave it in if it has text/audio meaning as in if you listen "em" or "i" will emphasise a word, if that's right, then it's in the right place. You simply then use your CSS to visually style those four elements how you want . i.e you can override the bold on the <b> and <strong> and make it red instead.. but you have not altered the meaning of the plain text document, nor an SE's reading of it.
So don't use unnecessary spans if there is an existing HTML element that will suit for the wrapper, all elements are boxes and are capable of being styled via CSS, the SE's a text browser and couldn't care less what the page looks like, they want the plain meaning.
It's a lot of common sense, it's not just about standards, although that would be nice, it's simply making it as easy as possible for one seems to have a knock on effect all the way along ;)
Oh and before I forget, Welcome to WebmasterWorld!
|I use it because the world of standards claims that is where everything is headed and there is no point in learning something that is going to be depreciated. |
The standardistas got it badly wrong. HTML has not been deprecated. Work on XHTML2, which is where the standardistas thought we were heading, has been abandoned altogether.
HTML5, the next version of (X)HTML, recommends using the HTML5 version not the XHTML5 version, because for most people XHTML offers no benefits at all.
|I truly believe that picking and using xhtml for my standard will allow me to develop the skills I desire... |
If you send your XHTML pages as text/html mimetype browsers just treat your XHTML as malformed HTML. IMHO your best option is to use a full HTML4.01 strict doctype and get into the habit of validating your code.
I'd also recommend rocknbil's links.
|Learning to develop excellent web pages is difficult enough for many of us without the standards being changed on a regular basis. |
The markup standards we use to write web pages basically haven't changed since 1999(!) :)
|<b> becomes <strong> |
<i> becomes <em>
This will give you the visual (presentational) as well as the semantic meaning.
Changing a string identifier does not magically add semantics. The only difference between the two sets of tags is the "semantic" ones make your pages a bit longer. They are, to all intents and purposes, equivalent. :)
Changing a string identifier does not magically add semantics. The only difference between the two sets of tags is the "semantic" ones make your pages a bit longer. They are, to all intents and purposes, equivalent.
From a purely visual perspective, yes that's true, those tags are essentially equivalent. However, from a semantic perspective, that is certainly NOT true.
For example, assume that you are "listening" to the page rather than viewing it. What does <b> mean? It means "bold". Ok, so what does that mean semantically when that section gets read? Absolutely nothing. "Bold" describes presentation, not content. On the other hand, if it was marked up with <strong>, that has semantic meaning, which can be interpreted to be audibly different than the surrounding text. The same holds true with regards to <i> and <em>. <i> meaning "italicized" has no semantic value, but <em> has a semantic meaning of "emphasis".
The wider question, is what's the difference between making something "emphasised" and making it "stronger". I think the fact that's a question for the linguists is a good way of highlighting the difference between "emphasis" and "bold".
And while the difference in characters may seem irrelevant to those who understand the meaning, it is an important way of guiding those that don't.
I have to say that out of all the forums I have been to, this has absolutely been the very best experience (both learning and entertaining) I have had.
Although we have traveled a bit east of our original CSS vs SEO topic, there is still great meaning and relevance of each reply.
I know I still have plenty to learn and I am sure that I will always have plenty to learn, but that alone is what makes it fun for me (I love to learn).
I guess what I should have mentioned earlier is that I learned to write my code without using much markup other than <p> <br /> <a> <div> <h1> <span> ... I learned to almost always remove <strong> from my markup and use css for this.
I have a feeling that I will be re-writing lots of code in the next few months and spending much more time on this forum.
Well everyone, the conversation has been educational and stimulating. I truly appreciate all the replies, insights, and warm welcomes. I look forward to becoming an active member of this community.
I generally use <strong> or <em> when building, the text input editor on one site inserts <b> or <i>, my CSS converts both to look the same as it's not worth the effort to change such subtleties based on the latest fad.. but hey if we're talking linguistics. Emphasis is a subtle tone or inflection, whereas strong is shouting or in your face.. all IMHO of course
<i>talic for subtle inflection
<b>old for shouting
This particular semantics argument has been ongoing for nearly ever. I think it was given a good going over during the course of HTML5 drafts, was it mattur?
With a standardista hat on I'd of course prefer the <em> and <strong> for their semantic meaning.. but it's a few less bytes to use the shorter ones, and apparently keeping code to a minimum is important these days ;) - I think they were so set in peoples WYSIWYGS or minds that it makes no odds to the browsers or SE's to make them equivalent in meaning - they don't care about the actual semantic word/tag as long as it's clear to them what value to attach to it do they? Everyone's happy, use either.
To me, the underlying theme is that web is not a visual or audio medium; it should be for everyone.
|if we're talking linguistics. Emphasis is a subtle tone or inflection, whereas strong is shouting or in your face |
The linguistic argument is useful, though, surely? Is there a use to having bold and bolder, or even a numeric scale to how LOUD we're trying to be?
Simple semantics aside, writing xhtml and validating forces a newb such as myself to be very strict with the code. In the long run (hopefully) this will result in a better understanding and adaptability to changes in the standards. The only reason I use the term standards is because browser manufactures are bound to completely drop many rules and tags from their tool box.
If we want as many people as possible to be able to view our site, then I feel following "the mans" idea of what is the standard is the way a beginner should go. html 5 is years from completion and is unlikely to allow unclosed tags such as that is allowed in html 4.01
Then again I am the newb and I have come to you for your seasoned opinions.
i suggest a very thorough examination of rocknbil's post and follow those links.
|writing xhtml and validating forces a newb such as myself to be very strict with the code. |
html 5 is years from completion and is unlikely to allow unclosed tags such as that is allowed in html 4.01
HTML 4.01 Strict and validated will be more than adequate to learn to code to standards. The only significant difference (there are others) is in the requirement and method of closing tags. XHTML will not improve your standards more than HTML.
Frankly, once you get used to handcoding, validation is mostly just a double-check. Correct markup becomes automatic and one is only looking for accidental errors that get through. It is no more than a spell-checker for markup once your skills are solid.
It is worth noting that validated markup doesn't necessarily result in a page that will render well. It can validate and be useless junk. Design for function, validate, 'pretty it up', double-check validation, publish.
Useful and accurate suggestions. While reading these posts I have been searching and reading about the future extermination of xhtml or rather the future halting of further development of xhtml as well as the development of html 5.
It looks as though like all technology (coding languages apply) html will always be changed and upgraded for one reason or another. It appears as though html 5 will be a hybrid version of html 4.01, xhtml, and a new breed including new tags and such. More to learn!
I guess since all I had to go on was the words of authors claiming to be the authority on the subject (also seeking a payday i am sure) I went with what they said I should go with.
With a few minor adjustments I am sure being on the right track and developing quality code is within my reach.
By the way, as stimulating and helpful as all these replies are, I think we have finally strayed completely from the original topic. I am fortunate enough to have had all my questions answered and gained some great insight I might have never had if I never stopped by WebMasterWorld.
|This particular semantics argument has been ongoing for nearly ever. I think it was given a good going over during the course of HTML5 drafts, was it mattur? |
Yes, good going over is an apt description :) HTML5 takes the pragmatic path and defines meaning for all four tags [whatwg.org].
Unfortunately this (IMHO quite reasonable) decision has somehow managed to upset practically everyone - on both sides of the argument - and it continues to cause much consternation. :)
|I started to get a case of divitis |
Contextual selectors are your friend. :)
Seeing as how, as you say mostever the topic has strayed a bit, though very interesting, I changed the title a wee bit bit as it's all interlinked anyway. Hope you don't mind.
Thanks for the link Mattur, :) all four defined eh.. I agree that was the most reasonable decision, and one I've gone with for a while.
Andy, yes I agree linguistics are important to the deeper understanding, the semantics if you like - and there are already levels of bold (numerical) CSS2.1 Fonts [w3.org] but that is what goes in the CSS, that really is a presentation preference - whether it's visual (Though I can't tell the difference) or audible stylesheets. As for the plain text or SE's - it's probably a bit like a word processor, it's either B or I, it is after all a plain text document.
If and when SE's start to parse to stylesheets, I would fully expect them to use the extra information provided inside them to be for the good of the people, a "green flag" if you like as opposed to the "red ones" so many are scared of.
| This 48 message thread spans 2 pages: 48 (  2 ) > > |