To accomplish maximum uptime and to keep customers confident, we recommend the following:
- Keep your core CMS and its plugins and add-ons upgraded.
- Review error logs frequently for warnings and errors and fix the root causes, the fix often being the first point above. This can help you catch things that might become problematic with increased visitor loads.
- Deploy Cloud Edge CDN/WAF. This offloads serving large assets to the edge closer to your customers, in turn speeding up your website page load time and improving visitor engagement and possibly search engine rank, too. (Everyone loves a fast website!) The WAF portion of Cloud Edge helps keep malicious actors and aggressive content scrapers and bots away, leaving your sites resources free to serve legitimate site visitors.
- Use Backstage™ selective content staging. Backstage gives you a dedicated staging environment for all content updates. You can work faster and more fluidly without worrying about accidentally breaking your site, test changes before making them live, and get colleagues or customers to sign off before pushing changes live. Further, you can lock down the back-end of your CMS on your production site, eliminating a potential security vector for malicious actors.
- Use NGINX web rules to create branded 50x error pages with basic information, including contacts and a maintenance message for brief intermittent server processing errors that can occasionally occur. This will at least help visitors to know how to reach you. A good starting point might be scraping the contents of the rendered HTML on your 404 page—500 Error pages need to be coded as standard HTML without any server-side logic since the server will be unresponsive during processing. In the following NGINX web rule example, we'll point 500 errors to a page called custom_500.html in the webroot:
-
error_page 500 502 503 504 /custom_500.html; - Use a failover deployment across servers and data centers to prevent hardware failures, software corruption, or regional network disruptions from creating longer content outages. Failover is appropriate for non-transactional websites (not e-commerce) or sites without lots of user-generated content because data de-syncs can happen during failover events.
- For transactional or high-traff websites, a High Availability (HA) cluster of 3 or 5 servers in geographically separate data centers should be considered for the ultimate uptime and flexibility to maintain the systems to avoid scheduled or unplanned downtime. These systems can keep all data in sync and sites online even with multiple server outages.