Source code no-nos

Hurdles in the html of a page

[beekiller]

I was at the WebmasterWorld conference this week and noticed that experts were able to look at source code in the site clinics and id problems for a site.

I know this is a very broad question, but are there any "rules of thumb" to having good, spider-friendly source code. What should I avoid?

Any examples you could give of what I should look for, and change immediately if I see it, would be greatly appreciated.

Thanks in advance. beekiller

[pageoneresults]

Hello beekiller, Welcome to WebmasterWorld!

I know this is a very broad question, but are there any "rules of thumb" to having good, spider-friendly source code.

For myself and many others here, validation is one "rule of thumb" to having good, spider-friendly source code. Once you've addressed the validation issues, you've eliminated one major area that may cause issues with spiders and users alike.

The next step would be site architecture.

• How is the site structured?
  
• How is navigation structured?
  
• Does the linking navigation follow the same structure as the site architecture?
  
• Do you have links to all indexible pages?
  
• Is there a site map?
  
• Is that site map linked to from all pages?
  
• Is your site large enough to have sibling site maps which are linked to from the parent site map?

[emac]

[validator.w3.org...]

your best friend. also, browse the site for useful info.

[moltar]

Having semantically correct HTML code is priority number one for me. Look through W3C specifications on the advised use of HTML tags and use them accordingly.

[beekiller]

Thanks to everyone! This is very helpful. I really appreciate it. bee

[2by4]

Learn what doctypes are, then learn what it takes to validate the doctype you feel most comfortable with. Don't use doctypes that don't match what the requirements of the site are, for example, if you use target="" in your links, don't use the strict doctypes.

Pick a method that works for you and stick to it, don't follow fads without understanding the technical consequences and requirements of that doctype.

Do cross browser testing, don't assume something will work just because it validates.

Avoid all uppercase in your html, there's no reason to do that, and it makes it easier to upgrade the source code to a more complex doctype like xhtml in the future.

Learn what tags are deprecated, like font, center etc, and why they are deprecated, and what they are replaced with, css.

[Arces]

One thing about crawlers though, especially the one used by google - they seem to avoid all the javascript redirecting they find on a site.
Not sure if that was of any help to you, but it's always a good thing to keep in mind if you want for people to find your site through search engines.

[g1smd]

Make the page from headings, paragraphs, lists, tables, and forms. Those are the basic building blocks. Use external CSS to style those blocks. Only use a class name for a block that is having a different style to the page default (e.g. the paragraph in a footer would have a class).

Don't get into multiple-nested-DIV hell. Don't use inline styles (get the style information into an external style sheet instead). Get rid of all <font> tags, and associated code clutter.

Validate both the HTML and CSS code.

[tedster]

Start by conceiving of a text document rather than a screen display. Then use your "mark up langauge" on that document -- HTML, you know?

The worst code soup comes from thinking of html as if it were a layout program instead of a mark-up language.