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 ourSecurity 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. Seethis blogfor 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 goodwhitepaper(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:
Email This Article
Previous Article
Next Article