Change Proposal - 4.2.2 The title element / 4.2.5.1 Standard metadata names

Background

----------------------------------------------------------------------------
------------

 

4.2.2 The title element / 4.2.5.1 Standard metadata names

 

Taking a typical user journey from a search engine to a page in a web site:

 

I am searching for "Mating Rituals"

 

If sites had no meta-tags nor content a site called www.matingrituals.com
may be at the top of the SERPS.

If sites had meta-tags but no content then a site about "<title>Introduction
to The Mating Rituals of Bees</title>" (regardless of the URL) with a page
with <title>Introduction to The Mating Rituals of Bees</title> may be at the
top of the SERPS.

If sites content but no meta-tags then a site about "Mating Rituals"
(regardless of the URL) with a page with <h1>Introduction to The Mating
Rituals of Bees</h1> may be at the top of the SERPS.

 

Most likely in real life the tag would read <title> Mating Rituals* -
Introduction to The Mating Rituals of Bees</title>

*where Mating Rituals is the name of the whole web site.

 

The issue here is that meta-data is used for indexing but is not visible to
the user visiting the web page other than <title> appearing in browser bars
(usually in the top left corner).

For this reason we often append the title of the page to the name of the
site in the <title> tag e.g.

 

<title>W3C HTML Working Group</title>

 

Where W3C is the site, HTML is the section and Working Group is the
sub-section.

 

However, the user sees: W3C  HTML > HTML Working Group.

 

This is of course a minor inconsistency but as we know the inconsistencies
between <title> and <h1>have been exploited in the past by unscrupulous
authors for SEO purposes.

Modern search engine algorithms cater for this by comparing metadata to
content.

 

My own advice to clients is to ensure that <title> matches <h1> to ensure a
consistent experience for the user and consistent indexing alike and that
<h1> is used only once per page (see end of this email).

 

We build this into our CMS templates like so:

When a user creates a new page and names it a <title> and <h1> are
automatically created e.g. <title>Mating Rituals - Introduction to The
Mating Rituals of Bees</title> and <h1>The Mating Rituals of Bees</h1>

The exception is the Home page of the whole site which is treated as
follows: <title>Mating Rituals </title> and <h1> Mating Rituals</h1> instead
of <title>Mating Rituals - Mating Rituals </title>

 

Proposal

----------------------------------------------------------------------------
------------

 

My proposal is that as <title> is Metadata content and is actually the PAGE
TITLE it becomes a metadata name within the meta element as follows:

 

application-name

author

description

generator

keywords:

 

 

either title or pagetitle

 

Where my proposal falls down is what then becomes of "Site title" ?

Why is this an issue - well if we move our page  <meta name="title"
content=" Mating Rituals* - Introduction to The Mating Rituals of Bees ">
(*where Mating Rituals is the name of the whole web site) to beekeepers.com
is it up to author to ensure the tag updates to : <meta name="title"
content=" Bee Keepers - Introduction to The Mating Rituals of Bees "> or
should there be a new tag that is in fact the name of the site?

 

If that is the case is the global metadata or local metadata as it should
NOT travel with the page if moved?

 

----------------------------------------------------------------------------
------------

 

Lastly

 

This is the first part of my issue with top level structure - I wish to go
on to how <h1> is currently used for accessibility as an anchor.

With layout in <div> and content that tends to appear in the middle of pages
with currently with correct hierarchical use of headings accessibility can
index pages very well.

I wish to look at how my proposal and the proposed HTML5 "section" and
"hgroup" elements will fit together and is there a need for a "Visible" page
title tag in the presence of multiple <h1> tags?

 

 

Regards,

Dean Leigh

Received on Wednesday, 14 April 2010 09:00:45 UTC