| This 72 message thread spans 3 pages: < < 72 ( 1  3 ) > > || |
|The Ultimate SEO Guide for 2009|
HTML and XHTML Techniques for WCAG 2.0
The above link provides "everything" you need to know about on page SEO. If you see anything that was missed, please do speak up!
It is like the Digital Encyclopedia of SEO. Be prepared to spend about 6-8 hours of "initial" reading, following links, using your back button, etc. After you have read the entire document and "all" linked references, I will Certify you as an SEO. Along with myself. :)
Thanks! I have to get reading and that's just the thing i need.
|there's a few you might have missed. |
Best WebmasterWorld Threads of 2008:
Would an A-Z listing qualify for the <ol> element?
That definitely qualifies for an ordered list. The best thing is that you don't need to type the corresponding letter for every new item. Just style your <ol> to display them automatically
|ol list-style-type: upper-alpha; |
Have a look at all the style types for lists [w3schools.com]
About reading the specs from the w3g - I have. At least some of them and am rereading as time goes by. You have to read them if you are willing to build accessible sites. I have done so through my interest in (x)HTML. Semantic markup is the way to go and I am so pleased that on-page SEO is that. That means that in the most part I have made my sites was coding SE-friendly without trying.
I can't agree that they're letting the cat out of the bag. They are showing the best practice for making websites. And if the best way of doing so is helping your ranking... well, nothing strange about that.
there's an example in the w3c wcag doc which uses the ordered list for a sequential process:
H48: Using ol, ul and dl for lists ¦ Techniques for WCAG 2.0 [w3.org]
|That definitely qualifies for an ordered list. The best thing is that you don't need to type the corresponding letter for every new item. Just style your <ol> to display them automatically |
i'm not sure this really does what you want.
an alphabetized list certainly has an implicit order, but there may be repetition or gaps in the letters.
therefore you would have to set the value attribute for every list item for this to work as required.
You can always add the empty <li> tag and give it a class which wont display it. Thus having the gap between letters.
I don't know about repetitions. I don't see the point in having the same index for two different things. If by repetition you meant something like A.a, A.b, A.c you could put an <ul> inside the <li> element and add the letters manually, yes.
And if you still manually edit your list if it needed something added or removed you have to go through every <li> object in a <ul>. Not the case with <ol>.
<li>'s don't have a value too.
But that is offtopic as this is a personal choice of formatting your content.
|<li>'s don't have a value too. |
it may be deprecated but it is still supported.
from the HTML 4.01 Specification:
Lists in HTML documents [w3.org]
I wanted to ask for your opinion of linking to other language versions of the same document with the <link> tag.
What are the benefits? Is it good to always put up such a thing?
|Is it good to always put up such a thing? |
It is always good to follow best practice when it comes to HTML specifications and suggestions.
12.3.3 Links and search engines
|In the following example, we use the hreflang attribute to tell search engines where to find Dutch, Portuguese, and Arabic versions of a document. |
^ Check the examples.
I use link rel quite frequently. And no, I don't know what impact it has on the search engines. I do know that certain things seem to happen that I cannot fully explain like the persistent return of indented results where link rel is being utilized. Again, I cannot confirm that it is the link rel that causes the indented result. If you think about it though, if you are using link rel to group documents together, wouldn't you think that would be a cause for indented listings? ;)
We will implement the <link rel="alternative"... thing
Btw.. shouldn't the title of the post be "The Ultimate SEO Guide" :D
Thanks a lot!
One of the terms that you will see referenced quite frequently in these documents is Phrase Elements.
9.2.1 Phrase elements: EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ABBR, and ACRONYM
I'm going to pick one of those for discussion today and that is the CITE Element (previously discussed but needs more air time). At the same time, I'm going to be using the BLOCKQUOTE and Q Elements to demonstrate various techniques in the use of the CITE Element.
H49: Using semantic markup to mark emphasized or special text
|JAWS contains support for blockquote and cite. WindowEyes contains support for blockquote, q and cite. |
Anytime I see specific references to JAWS and/or any of the other assistive technologies like WindowEyes, I'm going to pay special attention to what is being specified. My thinking is if the assistive software is focusing on specific elements, there is a good chance that other indexers are also interested in those same elements. Why? Well, they have to make that content presentable to users with disabilities. The bots are deaf and blind.
<p>Paragraph 1 content.</p>
<p>Paragraph 2 content.</p>
I wonder how that cite="" reference is handled by the search engines?
<p>As <cite>Barack Obama</cite> said, <q>Focusing your life solely on making a buck shows a poverty of ambition. It asks too little of yourself. And it will leave you unfulfilled.</q></p>
I could also take the above and use the CITE Element and cite Attribute...
<p>As <cite cite="http://www.WhiteHouse.gov/">Barack Obama</cite> said, <q>Focusing your life solely on making a buck shows a poverty of ambition. It asks too little of yourself. And it will leave you unfulfilled.</q></p>
There are all sorts of neat implementations using the BLOCKQUOTE, CITE and Q Elements along with the Attributes that are also available for refining those Elements. If you're an online publisher, you will most likely make ample use of these Elements/Attributes so that your content is semantically correct.
Keep in mind that many of these Elements have default styling. For example the BLOCKQUOTE is indented by default. Many authors use this Element to provide a visual indent which is incorrect usage. BLOCKQUOTE is reserved for a block level quote that has multiple paragraph breaks. Q is reserved for inline quotes that don't require multiple paragraph breaks. Using Q will also produce your curly quotes by default (and they validate). You can style these elements further using CSS.
I'm still wondering how that cite="" reference is handled.
I'll be surprised if this technique doesn't generate a few "huhs". :)
i wonder what would be the best way to use the cite tag if it's not within the blockquote tag and how best to refer the citation to the quote.
i just realized i need to add some more semantics to a "testimonials" page somewhere...
Semantic Data Extractor
What a great tool to have available!
|This tool, geared by an XSLT stylesheet, tries to extract some information from a HTML semantic rich document. It only uses information available through a good usage of the semantics defined in HTML. |
|The aim is to show that providing a semantically rich HTML gives much more value to your code: using a semantically rich HTML code allows a better use of CSS, makes your HTML intelligible to a wider range of user agents (especially search engines bots). |
Does the W3 know something we don't? Especially search engine bots? Hmmm, makes me wonder...
This is very interesting but I wonder how much of this sort of stuff Google uses? Won't they make an allowance for the fact that very few web pages will employ this level of markup?
Ye, but I've long suspected that Granny (or Grandma if you prefer) gets treated differently from non-savvy SMB, who in turn gets treated differently from SEO'd sites- at least by Google. This is just one area where my theorectical "partitions" and how they fold into SERPs proves illuminating in thought experiments. Anyway...
So Granny has good content but zero skills. No problem, have page 3-5.
Non-savvy can rank wherever, but TYPICALLY not page 1 above the fold.
SEO done badly seems worse than no SEO at all (and I'm not talking black hat, more keyword stuffing or poor alts). And SEO sites seem to need better content to break page 1. I haven't actually recorded results, but I have been checking lots of SERPs in alot of sectors recently. Thin sites on page 1 almost invariably have no onpage SEO.
Anyway, my point is that using excellent markup seperates you from your SEO peers, pushing you up a little. And it might aid referal-relevancy (searcher intent, thus conversions) if SEs understand the MEANING of your site. Its an additional tool that can help, why NOT use it?
[edited by: Shaddows at 9:34 am (utc) on Jan. 28, 2009]
I've created another topic for the Semantic Data Extractor here...
Semantic Data Extractor
2009-01-29 - [webmasterworld.com...]
In the above topic, I took that tool apart to find out how it works and came up with the information you see posted. Looking at the semantic view of documents has surely changed my way in how I think about site architecture. Proper use of the HTML Elements and Attributes that you have available to you allows Webmasters to create semantically rich HTML with little effort involved. In fact, the effort is the same, this time you are doing it right. ;)
Yes, I've been promoting this tool for years. While performing searches on the Semantic Data Extractor, I came across some older WebmasterWorld topics, this being one of them...
Semantic Data Extractor - Semantically Rich HTML Documents
2006-11-25 - [webmasterworld.com...]
Blimey, somebody pass me the Panadols!
Great stuff here, pageoneresults, albeit heady stuff too, for me anyway. I've made some efforts re one H1 per page etc, but clearly kid's stuff.
Also, use cms - Drupal 6 - and leave much of code, for menus etc, as is.
Seeing re semantics here, though, I will be more interested in moves towards Drupal 7 n semantic web. And in using some codes I hadn't considered.
This is such important stuff. I need to arrange a free day (or 2) to study this. A big thank you to PageOneResults for your illuminating fervor.
Sites and browsers started on the web by doing their own thing. Gradually they are all converging on standards and W3C. Even IE is becomming the prodigal browser. I believe W3C (and standards compliant browsers), are the only workable future for an internet of such rapidly evolving complexity and vastness. So we all need to understand this stuff!
Wow, what a post. There goes my week.
just redesign my site, so a lot of on page SEO was changed, but as I expected NOTHING went wrong to the Google rankings - I think on page SEO is somewhat dead, there are 2 things that do play a roll, but thats it.
|ust redesign my site, so a lot of on page SEO was changed, but as I expected NOTHING went wrong to the Google rankings - I think on page SEO is somewhat dead, there are 2 things that do play a roll, but thats it. |
Ah perfect, I was just getting ready to cover a few more Elements and Attributes.
Please, do tell us the exact steps you went through and what changed. Also provide us with time frames and such so we can determine that on page SEO is dead. Wouldn't that be great? There will be a lot of people without jobs next week because "your testing" proved that on page SEO is dead.
And, what are these 2 things that do play a role? Would that happen to be link development? And more link development?
Wow...I struck Gold when I found this website and then I struck Platinum when pageoneresults shared this link.
HTML and XHTML Techniques for WCAG 2.0
I better comment now because I'll be busy with a month's worth of reading just in that. I've much to learn and I'm in the right place.
welcome to WebmasterWorld [webmasterworld.com], Artsyrat!
see you next month.
SEO is Dead
|I think on page SEO is somewhat dead, there are 2 things that do play a role, but that's it. |
I guess it is official. As of 2009-02-16 at 17:56, zeus stated that on page SEO is somewhat dead. Now that we've got that out of the way and everyone is in agreement, let's look at "behind the page" as opposed to "on page".
First thing I want to do is bring in a reference to HTML 5 as it appears to be gaining steam in all the right places so it is imperative that you prepare now if you plan on making the transition to HTML 5 in the future.
Drafts of HTML 5, Differences from HTML 4 Published
Before you read the HTML 5 Drafts, look at those who are behind the movement. ;)
There is quite a bit of information to be digested with the new HTML 5 Draft. The "meaning" of web documents is increasing in importance and the Draft clearly shows that.
So, if "on page SEO" is dead or somewhat dead as zeus claims it to be, that must mean the stuff that is "behind the page" can now share the limelight?
Do you think SEO is dead? If it is, quite a few people have wasted a lot of time drafting up all those documents at the W3. :)
|I struck Gold when I found this website and then I struck Platinum when pageoneresults shared this link. |
Welcome to WebmasterWorld Artsyrat and thank you! Although some may think you may have "only" found a little bit of silver in them hills, the link that is. You surely struck Platinum when finding WebmasterWorld, that's for sure. :)
Please continue, p1r. What are your thoughts about HTML 5?
|What are your thoughts about HTML 5? |
In short, I like it. But, you know I can't be too short about something so important.
From my research to date, HTML 5 is all about structure, bottom line. In the process of defining that structure, they've added a host of additional features that Webmasters have been asking for in the current specs and haven't gotten yet. So from my perspective, it's a major overhaul for HTML 4 and brings everything up to current UA intelligence levels. That's the root of it if you ask me. The UAs are more intelligent now than they were when the HTML 4 spec was written.
SEO in the general sense just took on two meanings. You have "on page SEO" as many refer to it and now with HTML 5 you have "behind the page SEO" which will probably be equal to if not more important than what is on the page when it comes down to the final straw.
I'm not real jazzed that they didn't make it easy to transition from HTML 4 to HTML 5 but again, this is a major overhaul. My question is, what happens to XHTML and all the applications that are based on it?
My answer? We're going to be taking HTML tag soup to a whole new level. You're going to have HTML 4, HTML 5 and XHTML. They are all distinctly different. You're going to get publishing platforms wanting to make the HTML 5 transition not fully understanding how to implement it. You're going to get authors wanting to use it while at that same time cutting and pasting from other resources that are not using it. I have a feeling things are going to get quite challenging for the makers of UAs. Yes, very challenging indeed. ;)
And, I am ready to advance the use of proper metadata to make sure that my documents flow properly. I'm ready to use structural headings which will allow me to define the outline of my document using sections which will then allow me to use phrasing content in turn achieving SEO Nirvana!
What the heck did he just say?
Hi all - great to see the new WCAG docs causing a stir.
A few notes to begin - Quite a few of the links in this thread are to earlier versions. For new, improved, tastier versions go see [w3.org...]
This is one of a set of key docs... I recommend you start with [w3.org...] which contains all the guidelines, which links to [w3.org...] which goes deeper into each criterion, and then links through to the [w3.org...] which go into technology-specific guidance.
There is also a handy diagram at [w3.org...] to show how it all fits together.
If you find yourself needing to consider SEO for sites with Ajax and similar tech, you will also want to read [w3.org...] - plenty of interesting stuff to keep you going!
W3C working groups collate all this info and publish it, but it relies on the wider web community for contributions, corrections and new techniques.
The WCAG2.0 itself (http://www.w3.org/TR/WCAG20/) is now stable and won't change (in W3C jargon, it's 'normative'), however the supporting documents referenced above are all works in progress, and we need your help to continually improve them.
You can comment on specific techniques at [w3.org...] and you can submit new ones at [w3.org...] You can keep an eye on what's going on by signing up to the Interest-Group mailing list (http://www.w3.org/WAI/IG/#mailinglist) or the Rss feed (http://www.w3.org/WAI/highlights/about-rss.html).
If there are any points within the docs that need clarification, you could also post to this thread and I'll do my best to either answer your query or find someone who can.
[Cards on the table - I was involved to some small degree in the production of both WCAG2.0 and in its supporting docs (one of many, many people). I'm part of the Education and Outreach Working Group at the W3C Web Accessibility Initiative. It's our job to make sure that these docs are easy to read, easy to use and explain things as clearly as possible. And to be incredibly pedantic about grammar and punctuation.]
You sound like a good guy to have around Liam. Welcome to Webmasterworld and stick around why don't you?
|How does the <dfn> element come into play when a user performs define: search engine optimization queries? |
POR - we used definition list mark-up on our site, and pulled in a lot of define: searches (accidentally, really). Since then, the world's major financial institutions and dictionaries appear to have caught up, and we no longer rank on all of the phrases - external links count for more than on-page mark-up.
As a quick addition on definition lists, you can use multiple definitions for a single term, e.g.
<dd>Big brown animal. Fierce.</dd>
<dd>Short for Robert</dd>
And so on.
Re: <abbr> and <acronym> - I find it easiest to think of it as a pronunciation guide.
<abbr> means that you sound out each letter if it's IN CAPS, or read as a word if not. <acronym> is where you read it as a word even if it's IN CAPS. That said, this is a personal view, and I haven't checked out how JAWS is treating them, for example. If anyone cares, I'll go do just that.
Re: 'User Agent' - this is not meant to be a cryptic reference to search engine bots. A user agent is any software that retrieves and presents Web content for users. Examples are Web browsers, media players, plug-ins, and other programs — including assistive technologies — that help in retrieving, rendering, and interacting with Web content. You can consider Googlebot as behaving very like a user agent... but it isn't a user agent in the strict sense.
|Let's forget about SEO for a moment here and focus on the user. How many times have you used a form with checkboxes and/or radio buttons and it was a pain in the arse "targeting" those pesky little buggers with your cursor? It is one my biggest pet peeves and I'll crack down on a site review real quick if they are not being used both publicly and in admin. |
<label for="CompanyName">Company Name:</label>
<input type="text" name="CompanyName" id="CompanyName">
<label for="FooServices"><input type="checkbox" id="FooServices" name="FooServices">
In the above example, I've put the <label> element in front of the input. The spec shows it in front of the text. I don't like the gap between checkbox and text that occurs when you place the <label> element in front of text leaving the input element by itself. The function is disrupted by white space.
I think you may find that the whitespace is being caused by the line-break between the label and the input element. Think of it as behaving like any other inline element (e.g. <strong>) - a line break after it becomes a space when rendered. I would strongly recommend using the first method, i.e. label not containing the input element.
re:headings (hmm... I wonder if you can put headings in these posts. Never mind. Sorry if this is getting long!)
Yes, use headings to give structure to the page, but remember that a h3 following a h1 should really be avoided, as it skips a level. h2 after a h4 would be fine though. A subheading should be exactly that, a subsection of the topic of the parent heading.
|Many websites have left and/or right menu systems. These are prime candidates for the <h3> element along with the use of lists. Some might even venture into <h4> territory depending on how large the scope of their content is. <h1> thru <h3> may be reserved for content level headings. <h4> thru <h6> may be reserved for navigation level headings. |
I would avoid using headings for navigation on the whole. The headings should be about the specific content of the page, not the architecture of the site overall. Keep the navigation in an unordered list.
|Headings SHOULD be short and concise. They should describe and/or categorize the content that follows immediately thereafter. I recommend the use of Fragment IDs for all content level <h> elements. This allows you to put visitors right where they need to be when linking. You'll find the use of Fragment IDs has many benefits. Trust me, I know. And, I believe tedster has recently seen Google using "Jump To" links in the SERPs that link to a Fragment ID on the destination page. Hmmm, one of those positive side effects that usually occurs when you use the elements and attributes available to you for document structure. |
Absolutely right about concision - would also recommend 'front-loading' of headings (and title elements. And paragraphs) - the most relevant text comes first, followed by qualifiers, followed by supporting information.
|I thoroughly enjoy reading the WCAG. This new set of guidelines contains more brevity and quick reference which makes it a bit easier on the study portion of it. |
POR, I shall pass that back to the working group. They will be delighted to hear it! We like to hear criticisms too - as mentioned in my previous comment, please do comment wherever you see any entry that isn't clear.
There are still many arguments on this. If you are designing slickly, you would only ever use an image where it had meaning, and so it would have something in the alt atribute... andthing that really is purely meaningless decoration should be provided as a background image via the css. That said, when you're wrestling with a recalcitrant CMS, an img element with a null alt attribute can be the least worst option. Don;t forget that not all screenreader users are blind - if you have low vision, you may be really interested in knowing what the orange blur is at top right.
re: nested lists.
Semantically, nested lists are great. Trying to apply CSS to them that allows for liquid layouts and a set of tabbed horizontal nav bars can be humungously frustrating. If anyone manages a good implementation, please let me know!
N.b. - blimey, we could do with sprucing up the accessibility of webmasterworld, couldn't we. Ick.
[edited by: tedster at 10:25 pm (utc) on Feb. 18, 2009]
Thanks, BeeDeeDoubleU :)
|Do you think the search engines are intelligent enough to use semantic structure as a signal of quality? If so, to what level? Ever use JAWS? Would that type of processing ever be applied from an indexing standpoint to determine document quality? |
POR, interesting question. In my experience the search performance of a site after accessibility improvements has always increased, and semantic structure is a major part of the improvements typically implemented.
I recently did a piece of research where we applied a cladistic analysis (a mathematical tool used to work out dinosaur family trees, among other things), to work out how 'evolved' websites were, and whether their degree of evolution matched user perceptions of quality (the question for the users was: 'rate these sites in the order of most liked to least liked'). The cladistic analysis measured everything we could automatically measure - from things like 'does it have a favicon' to 'what percentage of pages use a h1 and a h2' to 'what apache version is it using?'. Results: the more 'evolved' a site, the better users liked it. If users like it, you can bet Google will want to too...
[edited by: tedster at 10:29 pm (utc) on Feb. 18, 2009]
welcome to WebmasterWorld [webmasterworld.com], Liam!
thanks for the insight!
you might also be interested in WebmasterWorld's Accessibility and Usability forum [webmasterworld.com]
Liam, Welcome to WebmasterWorld! And thank you very much for taking the time to get involved, I personally wish to thank you.
|I'm part of the Education and Outreach Working Group at the W3C Web Accessibility Initiative. It's our job to make sure that these docs are easy to read, easy to use and explain things as clearly as possible. And to be incredibly pedantic about grammar and punctuation. |
Tell the folks on your team that they did an excellent job with this new set of documents. You've totally paved the way for an official set of documents that we can reference when questions arise. Previously, it was a bit difficult to relay this information while digging deep through the W3 and other related resources. That is no longer the case, bravo!
|External links count for more than on-page mark-up. |
Heh! You just made a bunch of Webmaster's day, you really did. I'm going to let you slide with that comment for now. ;)
|I wonder if you can put headings in these posts. |
Now I know we're going to get along! I've been pushing for more semantics here at WebmasterWorld. They've been abused in the past so they were taken away. :(
|I would avoid using headings for navigation on the whole. The headings should be about the specific content of the page, not the architecture of the site overall. Keep the navigation in an unordered list. |
Ouch! That one is going to cause some stir. I do believe many of us have followed the long standing suggestions of placing menu items in lists and preceding them with headings if they are within a left/right navigation menu. Interesting that you would avoid headings in this instance as I see the assistive technologies rely on these to help define structure for the user. We'll definitely need to expand on this one. How would you precede a list of links that define a section? For example, you have 5 links in one section, 5 in another and 5 in another. They are three distinct sections that all have a root level Table of Contents and fall under a specific category. How would you label those lists?
One of me favorite concepts in addition to IPW, SOC (Source Ordered Content), etc. You're one of the few people who have used that term here at WebmasterWorld. ;)
|If anyone manages a good implementation, please let me know! |
I believe the menu system that SuzyUK and I came up with years ago fits that bill.
|N.b. - blimey, we could do with sprucing up the accessibility of webmasterworld, couldn't we. Ick. |
Now I'm really starting to like you. Yes we could! Hey Brett, Adam, you hear that? ;)
|POR, interesting question. In my experience the search performance of a site after accessibility improvements has always increased, and semantic structure is a major part of the improvements typically implemented. |
That has been our experience also as far back as we can remember. This is not something new. Here's the one inherent challenge with this, it is very difficult if not impossible to pinpoint exactly which improvements were the cause of the effect. Our industry has this inherent need to find out which particular elements perform the best and then beat them to death. At the same time, all these other elements get zero fanfare around here, nada!
I just have to close with a big thanks to joining in the discussion. It is really a pleasure to have an individual who is directly involved with these documents to be providing feedback to us. That is way cool and ya'll just earned big brownie points on my side.
Between WebmasterWorld and the W3, there really are no other reference resources needed. We have everything we need right here.
|I believe the menu system that SuzyUK and I came up with years ago fits that bill. |
Is that system available here on WebmasterWorld, P1R? </quicktimeout>
Back to the thread...
dibbern2, this is a good place to start:
site:webmasterworld.com htc solution from Peterned - Google Search [google.com]
| This 72 message thread spans 3 pages: < < 72 ( 1  3 ) > > |