[uf-discuss] Re: Precise Expansion Patterns

Martin McEvoy martin at weborganics.co.uk
Sun Dec 16 08:02:55 PST 2007


On Sun, 2007-12-16 at 15:42 +0000, Martin McEvoy wrote:
> On Sun, 2007-12-16 at 13:48 +0000, Andy Mabbett wrote:
> > In message <1197809713.11736.31.camel at localhost.localdomain>, Martin 
> > McEvoy <martin at weborganics.co.uk> writes
> > 
> > >> Moreover this is like suggesting using URL fragments (internal link
> > >> anchors) in href is bad for SEO.
> > >
> > >No Im not links that go somewhere:
> > >
> > ><a id="here" href="#here" class="duration" title="PT2M23S">2:23</a>
> > >
> > >Is acceptable because there is an href value and it goes somewhere, no 
> > >confusing the bots
> > 
> > ...just the users.
> > 
> > Do we really want to present people with hyperlinks that link to the 
> > place they're already at?
> 
> no not really just presenting an example, and people already do create
> hyperlinks to the content they are already at, named anchors are a
> useful feature in long pages of content.
> 
> I also am not supporting any such usage (just for the record) ;)

The crux of what I am trying to explain is that at the moment empty
anchor text links mean nothing as far as SEO is concerned, bots will
either ignore or simply erase them from there index.

If we as a respected community say that empty anchor text DO mean
something, then bots and other applications that crawl the web will have
to take this into account in order to correctly represent their indexes.

Black Hat SEO's will undoubtedly exploit this to their own means
rel="nofollow" is a classic example of where a microformat has been
exploited by SEO's to do something its not meant for and thus may be
regarded as an Anti design pattern.

I do not wish (although the intentions are good) to be responsible for
opening the floodgates on any such behavior, and as a community we have
a responsibility to steer well clear of hacks, and half hearted
solutions that may end up causing more damage than good. 

Thanks

martin
> 
> Thanks
> 
> Martin 
> > 



More information about the microformats-discuss mailing list