@Tangor - I'm just clarifying your response. So you are saying placing H1 at the top of the code is merely an administrative convenience?
No. Given today's reliance on loading code last and body first to obtain those important speed numbers, H1 can appear at the end of the doc, just like head and footer and side bars, etc.
That is, it's position placement has nothing to do with strengthening of the relevance of the page for ranking purposes.
Where, and when, is the document ranked? Before it is rendered or after? Content and presentation are the values for "ranking" and that comes AFTER a render. So, no worries where you stuff that H1. I just like it at the top because I come from a long line of magazine publishers before there ever was an internet.
If we take that logic, could the h2 and h3's appear above the h1 ?
Yes. Just make sure your CSS, layering, or JS is written correctly. Dynamic pages (database generated) have some drawbacks in this regard as the code comes after the content, with inserts and other fun stuff (depending on the engine used).
I still question this, especially for semantic relevance purposes.
Why? The page AS RENDERED should be semantically correct if all went well during the coding phase. One has to ask: does the big bad SE read code only, or the rendered page, or both? Some are willing to chase things... I chase only the user (my intended target) and, because of my old school and commonsense to document structure, code H1 at the top and any major fork on that is an H2 and, IF that H2 has a sub-fork that fits, then an H3 will appear. I frankly don't care if the SE wants it one way or the other, this is the way it should be done and the USER gets it. :)
But we do have code abilities that let us put these values in other places, even different documents/sources for insert, and that's okay, too.
A semantic hierarchy is considered useful in URL structures as indicated by respected
I'll grant respect to folks, but not to the mixing of apples and oranges. URLs are pointers to documents. They are not documents. H1 appears in documents, not URLs.
Why is the semantic hierarchy not important in the h1 code placement, and to that end the order of the h1/h2/h3 tags?
But they should! Why do we have this conversation? Because from the creation of html the brainiacs behind that project made a simple, STUPID mistake from the get go. They used "title" for the bar at the top of the viewing window of the browser when it should have been---ALL ALONG---the freakin' title of the DOCUMENT being displayed, and that ONE LINE of TITLE occurring before the BODY text. But that didn't happen.
In HTML there is no TITLE tag for the actual title of the document. Never has been. Idiots! So we are left with H1 as the "title" when it is actually HEADING1. Look at any electronic word processor or publishing program from the last 68 years and you'll know what I mean.
SECONDLY, the other failure at the creation of HTML and the web is font rendering, tying those to the H series in particular, and what are the kiddies left with to "style" their documents? The nightmare began, and continues to this day. Why? Too easy to use!
Consequently (and here's the crux of my whole rant about h tags ... and search Webmasteworld for tangor and h1 for more, they are there!) H tags have no relevance, semantically or for layout. I doubt any SE (I know Bing does not) gives h tags any real semantic value, though they check for the simple reason the h series CONTINUES to be used incorrectly.
Where are you placing your h1's in the code and why ? Every webmaster must have an opinion on this. What's yours?
I place mine at the top of the document, just after closing the head. Why? Because that's where the title of a document should appear, unless you like to do things bass ackwards (as some famous film directors have done).
