• Eliminate any ? and other symbols in the page name (nice-keyword-here.html)
• In the ASP code, add the Response.Header for the Last-Modified date.
• In the ASP, add the Expires: Header. (this is important not to let too long, since information and prices might change)

1. If you have a mini-shopping-cart on every page, you should not cache
2. If you have the current date visible on the page, do not cache
3. Caching might effect the way you see statistics (Though, a good statistics program should know how to handle this)
4. Caching done good can improve the speed of your pages (a good thing :) )
5. Caching done bad is NOT good for you

Bruce, we are not sure how to read your posting. Of course using a URL rewrite tool is not the same as having static pages. This is true regardless of what technique you use, whether it's mod_rewrite built into Apache, or an ISAPI filter.

The technique mentioned in our forum provides correct server responses depending on whether the page does exist (product or category page -> 200 response code) or not (wrong URL -> 404 response code).

Content is updated constantly on an e-commerce store (e.g. "Units in stock" shown on the product details page), so we are not sure how caching could be used. Could you elaborate?

As far as we know using the custom 404 error page in the way it is used in the code we supplied does not violate any "best practices". If you disagree, please provide detailed information on which "best practice" you believe this violates and we will be happy to look into it.

The bottom line is that URLs that contain a product or category name do provide valuable information to a search engine crawler, as the file name becomes an additional, correct indicator of the content displayed on the page. I say "correct" because the product and category names are used to build the name of the HTML page, and therefore are always, automatically consistent with the content of the page delivered to the browser.

According to our research, the URLs generated using the technique mentioned above rank better than the corresponding ASP pages. We use this technique ourselves on our own software store. If you disagree, please provide evidence of it.

Sure, they aren't static pages, but neither a search engine or a human visitor can easily tell the difference.  What's better is that neither really have a reason to care enough to find out if the htm page is dynamic or static, either.

Google ranks dynamic asp pages *much* lower than a root level htm page.  That along with the category name being placed in the URL makes the minimal effort required to upload the statis redirect files very worthwhile, especially considering it doesn't cost anything!

-Rich http://www.hipepc.com - http://www.hipepc.com

• Make a "page names" table in the database.
• For every category and product, save a "keyword-rich-page-name.html" in the database.
• When someone comes to oursite.com/fur-coats.html, and there's no such page, the 404.asp will take over and lookup what to serve (viewCategories.asp?idCategory=2, Fur Coats).
• The viewCategories.asp page will look if we have a file called idCategory-2.html that was created within the last 24 hours. If yes, serve it. Else, get the page details, save as a file and serve it.
• When any change is done to the category/product (price stock), delete the idCategory-2.html if it exists.

Bruce11

Very nice post - I actually went the route with PC 2.76 of converting all product, catelog and brand asp pages into static html. I did it pretty much for the reasons you describe and by the method you suggest of using intermediate look up tables. I also have taken it a minor step further in using html compression. (At the time I could not do any of the simpler "half" methods as my host (1and1 win developers) did not support them.

The downsides of this are that everytime I want to regenerate the html due to the various scripts and FTP transfers, html compression etc - it takes me about 4 hours. Also sometimes my head goes numb remembering the various different steps I have to go through to modify feeds to add or delete new products that spawn categories of new brands. You can see the site at moc.dlorwymhtlaehym.www backward (I don't want this link showingup). The downsides are really quite an overhead even with a degree of automation.

The upside is that the end user gets to view much better context modified product pages which have all been previous generated with a large number of conditions and database calls that would (on my host) be a very long loading time. (I have the data that backs this). I also find that delivering html is far less prone to variable page serving times when using a shared database.

In terms of SE placement - I have not had any significant success but that maybe because nearly all my content is duplicate content despite trying to be creative. An exception to this is Froogle.

So like most things software - everything is possible - but if I was doing it over, my lack of sucess with SE placement would not make the effort justified. But it is interesting to follow the path less frequently followed.