I do a silimar thing where all my content is in a database as XML, so that the users can update their content when *they* need to(not when I get around to it). Then the html is created using xsl when requested.
The way that I set this up is that I map a directory to each servlet (or sometimes multiple directories to a servlet for different functionality for another set of pages) and then use real page names. These appear to be static html pages. This allows the pagename to be a prarm for the servlet. I also do not have many forms(nor do I use struts,etc) so that is not a problem for me. Charlie > -----Original Message----- > From: neal [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 06, 2002 3:49 AM > To: Tomcat Users List > Subject: RE: SEO and servlets > > > Craig, > > Thanks for the reponse. I know what you're saying that you > wouldn't want to > submit most web app pages, presuming that most of it is form > data ... but in > this case I have a bit of content that was placed into > dynamic pages because > (a) There is a common naivgation framework that is > essentially included, (b) > in the case of the main page there is some 'weekly specials' > data that gets > inserted into the content. The framework I developed > presumes XsLT for the > template rather than jsp, which means that I must use a > servlet (in this > case with my own extension), and thus the concern. > > So that's why I was wondering. I knew about the other issues > such s have > params beyond the question mark (they won't be picked up)... > again another > reason to use a servlet wherein *.abc would invoke the abc > serlet and * > could introspectively obtained as a param .. I thought that > might be a way > around it ... but I'm beginning to think perhaps not. :( > > Anyway, thanks for your thoughts. > > > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 05, 2002 6:55 PM > To: Tomcat Users List > Subject: Re: SEO and servlets > > > > > On Wed, 4 Dec 2002, neal wrote: > > > Date: Wed, 4 Dec 2002 22:06:53 -0800 > > From: neal <[EMAIL PROTECTED]> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > To: Tomcat Users List <[EMAIL PROTECTED]> > > Subject: SEO and servlets > > > > I was reading on Google the other day that it supports > "many of the common > > file types" including JSP ... but this led me to wonder if > they index > > servlets without file extensions, or how about common > frameworks such as > > Struts with the DO extensions. > > > > Does anyone know how these file types index with Google and > other major > > engines? > > > > Different search engines follow different policies -- you'd > have to ask > them how their spiders are programmed. Most of them, > probably, omit at > least some of the following types of URLs: > * URLs protected by an authentication constraint > * URLs matching patterns listed in the deny list of your > "robots.txt" file > * URLs that have query parameters in them > * URLs that have no-cache headers in the returned content > > Personally, I think it's somewhere between misleading and > silly to index > pages from a web *applications* (as opposed to web sites) > based on an MVC > framework (like Struts). Why? Because the URL that a search engine > spider would submit doesn't necessarily have *anything* to do with the > output that gets rendered. > > Consider a very common case where you have a form submit that > goes to a > URL ending in ".../saveCustomer.do" in a Struts app. If > you've made any > errors that get caught by the validation rules, the original > input form is > redisplayed. On the other hand, if you did everything > correctly, the next > page in your app's user interaction is displayed (probably a menu or > something). But the URL is the same! > > Which kind of output should a search engine index? > > Web applications != Web sites > > > Thanks. > > Neal > > > > Craig > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
