I’ve never seen anything to indicate Google is arbitrarily penalising sites that have invalid code. Their goal is to give searchers the most relevant results, and dropping sites because they have technical errors in their code isn’t going to fulfil that goal. (Besides, it would be more than a little hypocritical if they did!)
That doesn’t mean that code errors won’t harm your search position though. The key word above is ‘arbitrarily’. Google reads your code, and uses that to find out what your page is about and determine how and where it should rank. If your code is scrappy and all over the place, riddled with mistakes, there’s a fair risk that Google won’t be able to understand it properly, and that will harm your search position.
The main reason for caring about validation (apart from your own professional high standards, of course) is that sites with invalid code are much more likely to display incorrectly on some or all browsers. It might look fine in one browser and be wrong in another. That browser that it looks wrong in might not even be out yet – you can test it in every browser available today and it’s fine, then tomorrow a new version of (whatever) is launched and it chokes on your errors. It’s much easier to check the code is valid than to test it in every version of every browser!
On the other hand, proprietary code, whether it’s -moz- prefixes in the CSS or Google/Facebook code in the HTML, is always designed to use ‘new’ tags that aren’t part of any spec. That way, supporting agents will work with them correctly, and all others will just ignore them. So it’s no big deal if you have errors resulting from proprietary code, as long as you know why they’re there.
Code like that is designed to work properly even if it doesn’t validate, so I wouldn’t worry about it. The only way to remove that error is to remove the code. Remember that validation is there to warn you of potential problems. This won’t be a problem.
It would be better to ditch the transitional doctype, though. That’s really for 1990s sites.
It does work fine. The purpose of the exercise to get rid of as many errors as possible, is to speed up the downloads ( people are impatient, and it appears to be a ranking factor for Google ) and the rumour that Google ranks a site better that is has no ( or few ) code errors.
Is there some truth in this?
Is there a practical reason like better serp ranking? I am not a star programmer by any stretch of the imagination and learning whilst keeping up a full time job. I don’t mind if the old style limits the options; my site will be kept rather plain by choice.
Thanks for your quick response.
Is there a practical reason like better serp ranking?
I don’t think so, but an old doctype signals that the site may be built with outdated coding practices, such as tables for layout, which I do believe affects Google ranking a bit. It would be worth switching to a strict doctype and see what errors you get then. That would be very instructive.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
I was going to post this very same thing, without the Google ranking bit. The transitional doctype is used nowadays for two reasons: to “transition” a site from an outdated, table-driven structure to a newer one without loss of functionality (hence it would be strictly temporary), or to “hide” old, obsolete code behind the transitional doctype and give the impression that the site is valid when it really isn’t.
Thanks for the replies folks.
My site is handwritten, I do have editors but don’t like what they push out. Is there a tangible advantage to switching to a newer version html? Bear in mind that this is somethig I do on the side and I am not a pro-programmer.
There’s no big advantage, as such, but your original intention was to sort out any coding errors, so putting a more modern doctype in there would give you a better idea of what needs fixing, if anything. The older doctype just means that the validator will be more lenient on you and flag fewer errors.
I’d cleaned up a page a couple of days ago, at which point it completely validated. I copied the above doctype into this page, and I got 45 errors. 44 to do with unreconised font definitions/definitions.
I guess it will have to go back to looose, as I have no idea how to do the font specifications other than using css, of which I know virtually nothing.
OK, yeah, that’s very outdated code, so there wouldn’t be much point in messing with it to make the validator happy. The validator is really telling you that the page needs to be rewritten entirely. But if you’re not up for that, the page isn’t going to fall apart any time soon.
It is not a matter of being up for it. More like only so many hours in the day and needing to do first what pays of most including:
50+ pages to add to the site, 100% inhouse and hand coded.
Existing 30 pages need improving in lay out, content and seo.
Upgrading seo skills.
Adding and maintaining a blog.
If there is a quantifiable advantage in switching to the next generation coding, I will learn it. If it is a mainly a matter of “programming-aesthetics” and not much else, I’d rather spend the time on upgrading my seo skills as that will put bread on the table.
It’s not a case of what language it’s written in, but writing it in a way that’s semantically correct and most efficient.
As a basic rule, HTML is a language for identifying the meaning. For example, if you use a table, that is signalling that your are dealing with tabular data (related by rows and columns). Anything related to style or layout (Presentation) should be handled by CSS. In the bad old days of HTML, before CSS was properly supported in browsers, hacks such as table layouts and font tags were invented. But they are incredibly inefficient and not very accessible, for a start, so it’s better to rewrite a page without them.
It’s a bit like a building that isn’t constructed properly. It’s better to tear it down and rebuild from the ground up that patch it up and hope for the best.
HTML4 will do fine. At the moment you’re using HTML3.2 with some bits of 4 thrown in.
In HTML4, you’re supposed to use CSS for all the presentation, formatting, layout and styling information. So instead of putting [color="#aa0000"]<h1><font color="navy" size="3">[/color] in every time you have a heading, you just use the heading [color="green"]<h1>[/color] in the HTML, and then you have a CSS file (for the whole site), which includes [color="green"]h1 {color:navy; size:1.3em;}[/color], and that sets the style for all <h1> headings on the site.
It is not a matter of being up for it. More like only so many hours in the day and needing to do first what pays of most
I know that feeling well!
Setting your site up to use CSS will bring you massive time and efficiency savings in the medium and long term, maybe even in the short term as well, particularly if you are hand-coding it. Even if you don’t go the whole hog with the layout immediately, it really is worth moving to CSS for formatting as soon as you can.
A small addition to what Ralph, Stevie, et al. wrote: If you indeed have 50 pages on the site, which are all hand-coded, switching to a non-table CSS-based layout will literally allow you to reduce the time it takes to re-design the entire website with 98 percent. Once you learn more about CSS, you can improve this even more.
Another point, which is a bit moot, and only really interesting as a technical curiosity: The syntax g:[i][/i]plusone would actually be valid if you page was written in true XHTML (i.e. sent with an application/xml+xhtml MIME type). All it would require would be to define an XML namespace for the g: prefix. Only problem is, any version of Internet Explorer below 9 would be unable to display the page. Also note that, as I recall, this would not actually validate in the W3 validator, even though it’s strictly technically correct, as the W3 validator can’t handle user-defined namespaces.