Costom 404 are NOT the same as Static

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   Hi all.

Having Keyword-Rich names for the pages is NOT the same thing as having STATIC html pages.

For every http request, the server returns a "Last-Modified"" Header, which tell the browser (and the search engine) when the page was modified. An ASP page will always return a very recent date.

Another rather important HTTP Header, is the "Expires:" Header. It tells the browser when this information expires.

If you want to use have keyword-rich page names, it might be that the (not-really-static) category-product-name.html is not better than viewCategory.asp?id=33&name=Nice+Keyword+Here!

A better way to use it, it to use caching to your advantage. Here are some simple rules:

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)

I'm not sure what is the best way that search-engines like and what they consider important.

A few very important things to keep in mind:

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

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
Bruce11 Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 16-May-2007 Status: Offline Points: 0	Post Options Post Reply Quote Bruce11 Report Post Thanks(0) Quote Reply Topic: Costom 404 are NOT the same as Static Posted: 16-May-2007 at 6:20pm
	Hi all. Having Keyword-Rich names for the pages is NOT the same thing as having STATIC html pages. For every http request, the server returns a "Last-Modified"" Header, which tell the browser (and the search engine) when the page was modified. An ASP page will always return a very recent date. Another rather important HTTP Header, is the "Expires:" Header. It tells the browser when this information expires. If you want to use have keyword-rich page names, it might be that the (not-really-static) category-product-name.html is not better than viewCategory.asp?id=33&name=Nice+Keyword+Here! A better way to use it, it to use caching to your advantage. Here are some simple rules: 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) I'm not sure what is the best way that search-engines like and what they consider important. A few very important things to keep in mind: If you have a mini-shopping-cart on every page, you should not cache If you have the current date visible on the page, do not cache Caching might effect the way you see statistics (Though, a good statistics program should know how to handle this) Caching done good can improve the speed of your pages (a good thing :) ) Caching done bad is NOT good for you

ProductCart Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group ProductCart Team Joined: 01-October-2003 Status: Offline Points: 135	Post Options Post Reply Quote ProductCart Report Post Thanks(0) Quote Reply Posted: 16-May-2007 at 7:12pm
	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. Edited by earlyimp - 17-May-2007 at 1:21am
	The ProductCart Team Home of ProductCart shopping cart software

thedeacon Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 09-July-2006 Status: Offline Points: 0	Post Options Post Reply Quote thedeacon Report Post Thanks(0) Quote Reply Posted: 16-May-2007 at 10:37pm
	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 Edited by thedeacon - 16-May-2007 at 10:38pm

Bruce11 Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 16-May-2007 Status: Offline Points: 0	Post Options Post Reply Quote Bruce11 Report Post Thanks(0) Quote Reply Posted: 17-May-2007 at 11:50am
	OK, I agree that HTML page names are better than asp pages. Let me clarify a few things; For us ecommerce store owners, all that matters is that we get better placement in the search engines (HTML page names helps with that and it does not violate any "best pratices"). But, we can do better than that, and here's what I mean: Let the search engine really think that the page is static AND let the search engine know that the page information (price, stock) might expire (in a day or 2). Static is good for the environment! (search engines, that it), they love it, and will eat a mouthful of static sites. Static is good for your health! (your hosting server). Dynamic means a real-time lookup in the database for the price, stock information, many many many variables on the page, hence the name "dynamic". If there would be a way to serve the customer something static but fresh, that would good for all of us. That is why, I want to propose something: 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. This makes the page load time somewhat longer for the first time fur-coats.html is served (saving the static file), but on the 2nd time, it flies. I've seen this approach before, here are some links: http://www.theukwebdesigncompany.com/articles/php-caching.ph p http://www.devshed.com/c/a/PHP/Output-Caching-with-PHP/ Enough of me now...

geoff Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 15-January-2006 Status: Offline Points: 2	Post Options Post Reply Quote geoff Report Post Thanks(0) Quote Reply Posted: 05-June-2007 at 9:49pm
	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.