On Fri, 9 Jun 2006, Charles Lindsey wrote:
> The document I found was
> http://www.speedtouch.com%2Fpdf%255C...06WL-780WL.pdf
*WHAT*? That looks to be like a highly mangled version of the fairly
straightforward URL:
http://www.speedtouch.com/pdf/datasheet706WL-780WL.pdf
except that at some point, one of the "/" had been replaced by "\".
> But nowhere could I find a link to that document from anywhere else
> on the speedtouch site.
Ah, they provided the garble themselves. It's referenced from
http://www.speedtouchdsl.com/prod706.htm , at least, but with their
URL having a backslash where a web user would expect a forward slash.
Ho hum, their web server comes from the place that silently repairs
such differences.[1]
> And Google could not find a link to it either
I can't, at the moment, tell exactly what they've done to avoid
getting into the search engine. But staying out of search engines
seems to be a popular vendor technique to make it hard to find
information on their web site by any means which they haven't
implemented themselves. (Other vendors have the perspicacity to take
advantage of such third-party traffic!)
At first I thought it was because they'd hidden their URLs in
javascript; but elsewhere there are regular links to these PDFs.
However, for *these* specific PDFs they seem to have consistently
misrepresented one "/" in the URL as "\". They have other links to
PDFs where they haven't made that blunder, and then google is quite
happy: try e.g pasting this into a normal google search field:
link:
http://www.speedtouchdsl.com/pdf/overview_brochure.pdf
So in this case it may be that they aren't deliberately trying to hide
the information from search engines, but they just can't get their
URLs quite right, and are confusing google.
> has anyone had any experience of asking Google to find links?).
Works well IME, for properly made web pages.
[1] Hmmm, odd: RFC1738 definitely rated "\" as an "unsafe" character,
requiring it to be %-encoded when needed in a URL. But RFC3986, which
"updates" RFC1738, seems to have dropped "\" as anything special,
meaning that I guess it's now permissible for it to appear unencoded
in URLs, see
http://www.gbiv.com/protocols/uri/rf....html#reserved
But see "security considerations",
http://www.gbiv.com/protocols/uri/rf...ty-transcoding
ho hum