This document tries to outline an objective standard for what is required to be a great WordPress website. Anyone can create a WordPress website, but it’s not always clear what is needed for it to be a technically sound site. This list is part standard, part checklist and most of all a valuable reference for vendors and clients alike in their search for building or buying a great WordPress site.
- About
- A Great WordPress Website
- Removed Items
The master branch of this repo will contain the most up-to-date version of the standard. It might be between versions. If you need to reference a specific version of this document, then check out the releases. Feel free to browse trough the changes in the commit log.
The purpose of the document is to help get rid of ambiguous phrases like “best practice”, and rather set a benchmark for what practices must be used to qualify to be a great WordPress website. I hope that it will help make agreements and communication between vendors and clients simpler. By having an objective standard, it will be easier for vendors to show clients that they are doing quality work, while clients can be confident in what they receive.
The objective is also very close to that of the WP Honor Code; to provide a tool that enables client and developers alike to have a great WordPress experience.
This document is intended for persons involved in setting up or auditing WordPress websites.
Building web pages is a craft: It requires hard work that involves many decisions and considerations. This standard aimes to be objective and presents itself as a list of rules stated as facts. While I believe that all the items of this list are warranted and based on reliable sources and commonly agreed upon practices, there is still room for interpretation and/or variations on the topics presented. Be aware that there might be sites or projects where some or many of the requirements are not justified or needed.
Some of the items on this list are very specific about the practices and tools that must be used to solve certain problems. For example, modifications to premade themes must always be done in a child theme. This is a commonly acknowledged practice, and therefore belongs in this list. This document intentionally does not cover subjects or areas where there are no commonly accepted practices or yardsticks to measure by. For example regarding third party code/functionality like:
- use of premade themes
- limitation of number of plugins on a site
- use of page builders
It is very hard to state commonly accepted guidelines for these kinds of topics, but there are some ground rules that should be applied. Be mindful about pros and cons of different solutions while building a site. Use plugins wisely and only when actually needed. Be aware that they can hurt the performance or user experience on the site. Always try, to the best of your abilities, to vet any third party code before adding it. Evaluate aspects such as update frequency and code quality.
Use this list as a reference, but be critical to it's contents. If you disagree or have suggestions to changes, don't hesitate to open an issue.
This document distinguishes between what is required, recommended and optional for WordPress site deliveries. This is done through wording in each item.
The key words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may", and "optional" in this document are to be interpreted as described in RFC 2119.
In broad strokes, requirements and recommendations divides a basic standard from a gold standard. The requirements are what needs to be met to deliver a good site, and the recommendations will push that even further.
Please help me hone this standard so that it can serve as a reference for everyone that is using WordPress to power their websites. Open a new issue or submit a pull request to get the discussion going. If you want to help out, check the contributing information.
This document, and its author, is not affiliated with WordPress, other than being an enthusiastic user.
WordPress.org Plugin Repository Guidelines and WordPress.org Theme Repository Guidelines are not covered by this document, but as a keen reader you will find overlaps on certain points. Consider using the Theme Checker plugin to identify possible errors in your theme.
Below each requirement there can be one or multiple tags. These tags are used to give an indication of where the requirement originates or which group it belongs too. The following tags are used:
- Insdustry Benchmark
- The industry page speed benchmark as presented by Think With Google.
- PageSpeed
- The requirements originates from or is validated by Googles PageSpeed InSights tool for checking website performance.
The rest of this document outlines what it takes to be a Great WordPress Website
All modifications to premade themes must be placed in a child theme.
Any direct modifications to a theme that can be updated from the WordPress theme repository or any other source will probably be overwritten when updating the theme.
Custom functionality that is not related to design should be placed in a plugin, not in the a theme.
The purpose of this is mainly to keep the ability to switch themes without breaking the site. See WordPress Theme handbook for Plugin Territory examples.
Pages must be valid HTML5 with valid CSS.
Refer to the Theme Handbook page on the topic.
The site should have proper print styles.
There are no established best practices when it comes to print stylesheets, but the general guideline is to make make content useful and save ink. Consider what content is the most likely content to be printed, for example purchase receipts and other reference data. Modern browsers will let you emulate print, for example Chrome or Firefox. Consider the following practices
- Hide unwanted content such as headers and footers
- Don't print background images or colors
- Controlling page breaks
- Show URLs after links
- Show title of abbr and acronym tags
- Swap to a serif font
- Adding QR code for easy reference
All pages on the site must be responsive to work on devices off all sizes.
Page responsiveness has to be tested on actual devices by actual people, but should also be tested with automatic tools such as Googles Mobile Friendly and Ready.mobi
The site must be according to WCAG 2.0 AA guidelines.
This is the same guidelines that WordPress core uses. Check out the WordPress Accessibility Handbook for tips on how to make the site accessible.
All custom code should adhere to WordPress Coding Standards.
While following the WordPress Coding Standards is something that is recommended, it is not something that defines what a good WordPress site/delivery is. However, if the coding standards are followed for all custom code, it will make for an easier transition if a new vendor is doing work on the site in the future.
Unused plugins and themes must not be on the site.
If registered with Google Search Console, the site must have no issues.
It is recommended to register the site with Google Search Console.
If using JavaScript libraries that are included in WordPress Core, use the one that is provided by WordPress.
Many libraries are registered by WordPress, including Underscore and jQuery.
PHP version must be according to WordPress recommendations, currently PHP 7.2 or greater.
Database version must be according to WordPress recommendations, currently MySQL version 5.6 or greater OR MariaDB version 10.0 or greater.
Site admin must be able to do manual backups at any time and store that backup locally or off-site.
Scheduled backup to off-site location with defined interval and retention period should be enabled.
The site must redirect from www address to non-www address, or vice versa.
If a user tries to access the site on the non-canonical of the two addresses, then the site must still be delivered.
The vendor should provide the client with a staging site where changes can be made, tested and then moved to the production site.
Appropriate measures must be taken to ensure that emails from password reset, forms etc are not flagged as spam.
There are multiple ways of doing this, ranging from setting up SPF records, SMTP solutions, using ESPs and so on. Check this guide from Ninja forms.
The site must have a defined favicon for all platforms and devices.
Favicons are not what they used to be - now we need many different types of sizes. Consider using a plugin like Favicon to make your life easier.
Site analytics and tracking should be configured.
The site should have uptime monitoring with automatic notifications.
The site must have an XML sitemap.
The site should have breadcrumbs.
Refer to this article by Yoast for a detailed view on why it is important.
Consider using the WordPress Security Checklist.
The site must have forced SSL encryption (HTTPS).
The site should enforce strong passwords for all users with edit or publish capabilities.
While this can be handled on a policy level, it still makes sense to enforce it. This can be done via the plugin Force Strong Passwords. Users should also periodically set a new password.
Automatic Security Updates must be enabled.
There must be no user with the user name admin.
The site should hide login usernames and prevent against user enumeration.
Allowing enumeration of usernames is not a vulnerability in itself, but allowing hackers to know the login usernames makes other exploits easier to do. Enumeration can be prevented in code or .htaccess.
The site must have a limit for failed login attempts.
Multiple plugins provide this functionality, including Wordfence, but it might also be a good idea to do it on the server level with something like fail2ban.
The site should not have the standard login url.
Login url should be changed because it can stop unsophisticated attacks and also might limit the server load from such attack. Automated attacks might just head-on-over to the next site if wp-login.php returns a 404.
The theme and plugin file editor should be disabled.
Unless there is a really good reason for having these enabled, DISALLOW_FILE_EDIT should be set.
FTP should not be allowed on the server, only SFTP.
The database user should only have the required grants.
The site should have restricted access to WordPress admin to a few whitelisted IPs
The file permissons on the server should be only what WordPress needs, not any more.
Media Image Sizes must not be configured unless the sizes are actually used by the theme.
Having WordPress produce images of the right size is nice, but if there is no use for it or, it shouldn’t be configured. It just causes bloat on the server. Be careful to define new image sizes, and consider disabling some of the default ones.
Editor styles should be added so that editing experience equals front-end.
The site should include page templates that are ready for layout designers like Gutenberg or page builders.
This includes page templates that are wide (full content area/sidebars) and full-width (whole page).
Commenting functionality must be disabled if not in use.
It’s rather easy to “hide” comments functionality on the front end by simply not including the comment templates and code in a custom theme. However, if comments are not in use, they must also be disabled on the back end. Consider using either Disable Comment or No Page Comment plugins.
If comments are used, then there must be anti-spam functionality enabled.
A proper 404 page template must be in place and http status code 404 returned.
Also, consider tracking which urls are most frequently returning 404, using a plugin like Redirection.
The theme must honor sticky posts and handle them consistently.
A privacy policy page must be created, added to the privacy policy setting and displayed on all pages on the website.
The most viable way to test for an optimized web page is to use automatic testers like Google PageSpeed InSights, Google TestMySite, GTmetrix or Pingdom Website speed test. Some of the requirements below are based on the industry benchmarks from Think With Google.
All pages on the website must load in less than 3 seconds on all devices on average.
Industry Benchmark
Server response time must be under 200 ms.
PageSpeed
Time to first byte must be less than 1.3 seconds.
Industry Benchmark
Number of requests must be less than 50.
Industry Benchmark
The total size of a webpage, should be less than 500 KB.
Industry Benchmark
Proper image compression functionality must be configured on the site.
PageSpeed
Consider removing the default JPEG image compression via a custom or installable plugin, and then add a third-party lossless compression plugin like:
Web site cache should be enabled.
The ideal solution is to do this on the server level, but using a cache plugin can give a lot of gain for very little effort.
The static content of the site should be delivered by a CDN.
Gzip compression must be enabled.
PageSpeed
JavaScripts that are not critical to initial render should be made asynchronous or deferred until after the first render. CSS delivery should be optimized.
PageSpeed
All HTML, JavaScript and CSS must be minified.
PageSpeed
Each resource served must specify an explicit caching policy.
PageSpeed
There must be no landing page redirects.
PageSpeed
The size of the data that is needed to render the above-the-fold content of the page should be limited.
PageSpeed
The following items has been removed from the standard, but is kept as a reference.
Database tables must use a different prefix than wp_.
Outdated
There is no reason to hide change the database prefix. Hackers are more clever than that.
The meta generator tag which includes WordPress version must be hidden.
Outdated
This is not needed because you should always have an updated version of WordPress. Also, hiding the version doesn't really help.
If it is not in use, XML-RPC must be disabled.
Old tales has it that you could be exposed to amplified brute force attacks and be used in herding your site into a botnet for DDoS. Brute force attacks should be fended with login limits, and the botnet hack is not very effective anyways.