Email Website
Contents
Search:

Home > Add-Ons > Advanced Product Image Display

Go Live Checklist


An important step in the “go-live” process is making sure your new store does not lose the search rankings your have established through your current store. Setting up 301 redirects ensures you carry over search engine page rankings and helps customers find the right pages during site transfers. If you’re looking to transfer existing storefront pages this URL redirect will help.

Below is a checklist of tasks that should be done before setting a site to 'go live'. These steps will increase security and performance, and also (in some cases) make your site appear more professional. 

301 Redirects

An important step in the "go live" process is making sure your new store does not lose search rankings you may have already earned through your current store. Setting up 301 redirects with our built-in UrlMode GlobalConfig Parameter allows you to carry over search engine page rankings from previous AspDotNetStorefront versions while allowing you to take full advantage of our new SE Friendly URL patterns. See the UrlMode GlobalConfig Parameter for more details.

 

If you are migrating to AspDotNetStorefront from a different eCommerce platform, there is a Development Partner solution available to help you set up those 301 redirects.

Properly Secure Your Site 
Follow the directions in our Security Best Practices guide to properly secure your site. These steps should ALL be performed before considering a site ready to go live. Ideally, your 'Security Audit' section at the top of your admin page should be cleared. 

Enable HTTP Compression 
Optimize your bandwidth by GZipping static and dynamic content.

Add a P3P Privacy Policy & Compact Privacy Policy 
Your sites' cookie can be blocked if your site doesn't have a P3P Privacy Policy. See this blog for more information. 

Add an SSL Certificate 
Customers look for the "closed lock" on your site when they want to checkout. A SSL Certificate is not only good business, for many Gateways it's required.

In order to use SSL on multiple site domains, a certificate that supports multiple domains is required, or multiple single site certificates. You will also need to create a new LiveServer setting for each store and set it to the appropriate domain.

Turn off Debug Mode 
Edit your web.config file, and search for "debug". Make sure you set it to false (debug="false"). This will improve your website load times and overall performance. 

Rename Admin folder 
The AspDotNetStorefront Admin Console runs in the "Admin" folder by default. "Admin" is easy to guess, so rename your Admin folder to something other than Admin then set the AdminDir setting to the name of the renamed folder. The AdminDir setting value tells the application where to find and run the Admin Console user interface. 

Lock-down your Administration site 
Require a Windows Authenticated login for your admin folder. You can request this via your hosting company. 

Re-compress product images 
You can maximize your bandwidth, and even double your throughput by heavily compressing your product images.

Set-up redirects for non-www requests 
If you want to make sure *all* requests go to your www-site instead of your non-www site, setup a redirect in IIS. Here's how. 

Review robots.txt 
Make sure that you're not excessively-blocking search engine spiders. Consider the images folder... do you want your product images to be searchable? Have you added any custom pages that you don't want indexed? 

Generate MachineKeys 
Open the web.config file, and search for "MachineKey". Every site should have a unique set of validation and decryption keys. There is information on the process here. 

Set a memory limit for your AppPool 
Here's a good whitepaper (somewhat dated, but still accurate) on how to configure the AppPool for your web application.
 
Replace default topic content

AspDotNetStorefront ships with default content in several topics. You should review every one of your topics before your site goes live. Evaluate the default content shipped with AspDotNetStorefront and make any modifications necessary to suit your business needs.

 

The following lists topics many customers forget to review and update. If left unmodified, your shoppers will see the default content, which is, in many cases, something like "AspDotNetStorefront Administrators should change this topic."

 

To edit a topic, choose Content, Manage Topics from the Admin Console menu and filter for the topic name. 

 

Privacy

About

Download.information (if you sell downloadable products)

EmptyCategoryText

EmptyDistributorText

Copyright

CODInstructions (if you allow COD payments)

SiteDisclaimer

FAQ

ProductNotFound

 
Enable Custom Errors

 

Never run a live site with CustomErrors set to Off.

The web.config file includes a "customErrors" element. When you are convinced that your site is working properly you should set customErrors to On and create a static .htm page to be shown to your customers when an error occurs on the site. This will A) prevent your customers from seeing an ugly .NET exception if an error does occur, and B) will prevent your site from disclosing potentially sensitive information about your hosting environment such as the database name (in the case of a SQL error) or disk path of your site. (Refer to 404 Redirects for more information)
Set up custom error pages

You need to edit a couple of keys in the web.config file to enable or disable custom errors. You should never run a live site without first enabling Custom Errors, as failing to do so presents a significant security risk and often produces a poor shopper experience. (Please refer to 404 Redirects for more information on this aspect of Custom Errors.)

 

AspDotNetStorefront ships with a custom error page that will handle all errors. You can edit this page or create more of your own. Conversely, it is generally preferable to disable Custom Errors while your site is under development and testing.

 

To enable custom error pages, you edit the web.config file, located under the Web folder in which your site runs. Open web.config, search the file for httpErrors errorMode and follow the instructions detailed directly in web.config.

Running in a Sub-Directory or Virtual Directory

If you run your site in a sub-directory (also known as a virtual directory such as http://www.yoursite.com/{storefrontDirectory}/), you must change all of the error paths to include your virtual directory. For example, the following line exists in an out-of-the-box default AspDotNetStorefront installation:

 

<error statusCode="400" responseMode="ExecuteURL" path="/error?statusCode=400" />

If your site is running in a virtual directory named, for example, "StorefrontDirectory", then you need to update that error code to:

<error statusCode="400" responseMode="ExecuteURL" path="/StorefrontDirectory/error?statusCode=400" />

 

Follow suit to change all of the error paths listed in web.config.

 



Actions
Print This Article
Bookmark
Email This Article
Previous Article
Next Article