cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conal Tuohy" <con...@paradise.net.nz>
Subject RE: Search Engine Optimization and Cocoon (long!)
Date Mon, 15 Apr 2002 20:43:24 GMT
Are you sure, Bert? I can see how a search engine would be suspicious of a
META REFRESH tag because the search engine would be ranking the page which
contained the META tag (and a whole lot of key words), but the user will be
sent to some different page. So I certainly wouldn't recommend using a html
META tag! But if a Search bot receives a 301 code as part of the HTTP
transaction, then the old (e.g. Britney Spears) page has disappeared, and
the search engine should follow the link to find the new (spaghetti) page.
WHen it finds a 301, the search engine should trash the old page in its
index, just as with a 404, so there's no chance of "britney spears" turning
into "spaghetti" again. To use this technique to spam search engines you'd
have to return the "britney spears" page to the search engines and the 301
code to browsers ("cloaking"). If you're going to do this, then you may as
well return the spaghetti page directly, rather than a 301 link to it. So
why should they care about the 301?

http://www.google.com/remove.html#change_url

I'm no expert on search engines really ... and you could well be right
(which search engines are averse to 301 codes?) but I stuck my oar in
because it seemed to me that it's a waste of a perfectly good hit to return
a 404 unnecessarily. With Cocoon this kind of thing can be handled so easily
that I don't think "search engine optimization" should be an excuse for
turning away your EXISTING users who ALREADY HAVE an (old) link to your
site.

Con

> -----Original Message-----
> From: Bert Van Kets [mailto:bert@visitronics.be]
> Sent: Monday, 15 April 2002 06:19
> To: cocoon-dev@xml.apache.org
> Subject: RE: Search Engine Optimization and Cocoon (long!)
>
>
> I meant that a 404 is the signal for th robot to remove the
> file from the
> index.  A 301 is, wrongly, interpreted as a "meta refresh" 307.
> The meta refresh is used in a technique where a page
> containing a meta
> refresh is optimized for a specific, very popular, keyword is
> promoted but
> the visitor is redirected to a completely different content.  ex. You
> search for "Britmey Spears", but get redirected to a page
> about spaghetti.
> Search engines want to give good relevant results, so they hate this
> technique.  You can get listed as a spammer for this.
> Although technically
> a 301 is more correct, it's not good for SEO!
> Don't use it unless SEO is not important for the site.
> Bert
>
> At 10:46 14/04/2002 +1200, you wrote:
> >Don't use a 404 to signal that a URL has changed: use a 301 "Moved
> >Permanently".
> >http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2
> >
> > > -----Original Message-----
> > > From: Bert Van Kets [mailto:bert@visitronics.be]
> > > Sent: Sunday, 14 April 2002 08:57
> > > To: cocoon-dev@xml.apache.org
> > > Subject: Re: Search Engine Optimization and Cocoon (long!)
> > >
> > >
> > > If you get visits from search engines to those pages it would
> > > be crazy to
> > > get rid of those links.  I would however install the new
> > > pages without the
> > > query string and try to get as high as possible with as
> many SE's as
> > > possible.  Once those new links do their work, you have an
> > > alternative and
> > > you can get rid of the old links if you want.
> > > Most major SE's don't like different links to the same
> page, so it is
> > > actually an advantage of having only one good link to a page.
> > >  Then again,
> > > it's only a disadvantage if you get caught, so you can keep
> > > the old link
> > > with some spam risk involved.
> > >
> > > Robots will revisit your site after a certain time.  Most
> > > have an interval
> > > of about 1 month.  If it gets a 404 page not found it will
> > > erase that page
> > > from the index.  That will get rid of the old links
> > > automatically.  You can
> > > get rid of them manually by resubmitting them, but that's a lot of
> > > work.  If they find the new links, they will index the pages.
> > >  If some
> > > pages are in a search engine, it will get out and get the
> new pages
> > > automatically.
> > >
> > > Keeping track of the logs is *always* a good idea!
> > >
> > > BTW:  Don't confuse Search Engines with directories.  Search
> > > Engines use a
> > > robot to index the content of your site.  Directories like
> > > Yahoo en Open
> > > Directory (dmoz.com) have humans look at the site and quote
> > > it.  A clear,
> > > good content is all you can do for these guys.
> > >
> > > Bert
> > >
> > > At 06:13 13/04/2002 -0400, you wrote:
> > > >Bert,
> > > >
> > > >Thanks for the great read!
> > > >
> > > >>Part 7: other things you should know
> > > >>-----------------------------------------------------
> > > >>A. Querystrings (everything behind a ? in the URL)
> > > >>Most major search engines hate querystrings.  They assume
> > > that the query
> > > >>strings are used for database access and dynamic page
> > > generation.  This
> > > >>can give them a "black hole" where they eventually
> index a complete
> > > >>database.  Altavista clearly states that they will index a
> > > page with
> > > >>querystrings, but won't follow any links.  Google is one of
> > > the first to
> > > >>start indexing pages with querystrings.  They are very
> > > coutious and will
> > > >>go only a certain levels.
> > > >
> > > >Now that we can effectively rewrite page URLs without query
> > > strings using
> > > >C2, do you think it's simply a matter of resubmitting to
> > > search engines to
> > > >remove any existing search engine links to the "old"
> pages? In the
> > > >meantime, I suppose we could leave up a pipeline up, that
> > > maps the old
> > > >URLs with query strings to the new URL without query strings
> > > (and monitor
> > > >logs to determine when/if to delete them down the road.)
> > > >
> > > >Would that be your approach for updating old sites?
> > > >
> > > >Diana
> > > >
> > > >
> > >
> >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > >For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> > >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> >For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message