Principles of Implementing WordPress
Important things people miss when publishing a website.
(Click the principles below for notes and in-depth explanations.)

Introduction
Introduction
WordPress correctly publishes websites so they can be read by search engines and humans, redesigned easily using existing content, and tweaked with plugins, themes, and child themes. It is open source software, and very good software for its purpose. It’s designed to allow anybody to change how it works in virtually any way. The “right” way is open to what anybody wants to do. It depends on priorities and purpose.
When site owners plan their sites, they might not know the priorities and specifications to include. They are often limited to a visual review and a few buzz words that are current at the time. They miss some important factors: site speed, long-term updates, asset management, re-designability, usefulness of content, shareability, and more.
Some themes and plugins undermine some best practices. Overlaying another system (like a page builder) usually undermines some beneficial WordPress features and tends to slow a site. Careless use of plugins can cause the same problems.
That’s where these principles come in.
Each headline is, in essence, an item in a checklist. Sub-headlines comprise a checklist for the higher headlines. Some of the items need extended explanations. Some need a note or two. And that’s what you find here, some explanations and some one-line notes.
All headlines and sections are related because they are relevant to managing a website on any system (Wix, GoDaddy, Square, etc.) and WordPress in particular. But one section doesn’t necessarily lead to the next. In that sense, each section is independent. For some sites, one section is a priority, for other sites, another section.
How to Use The Principles
- Use the whole set as criteria to be weighed for the benefits and trade-offs.
- Prioritize them for your site.
It takes some technical expertise to understand the difference between good and bad implementation. This doesn’t explain every technical detail, but it’s a guide for asking questions and evaluating short- and long-term criteria.
Data-Content
Data-Content
Here’s a brute fact: Your website is data. No matter how you publish your site, the content is data. Google sees your site as data. Your content is data. Your site is data.
These principles start with this section to emphasize this point: your content is data. Your data is an asset. You can take steps to protect your asset and keep it re-usable, re-designable, and movable.
Separate Design from Data-Content
Separate Design from Data-Content
A longtime best practice in web design is to separate the content (data) from visual design and layout. Content is published with code called Hypertext Markup Language (HTML). Design is done with separate code, Cascading Style Sheets (CSS). With this separation, it’s possible to reuse the content, share the content, and change the entire design with one click. (Redesigning is not one click, but the switch can be quick.)
Not all themes and plugins separate content and design, and this complicates a design swap. It’s sometimes impossible to completely separate design and content, but it can be minimized and managed to keep a host of benefits.
Most people don’t know about this principle, so they don’t evaluate themes, plugins, nor their own websites for it. So this is the second technical point I want people to understand: content and design should be separate.
Evaluate themes and plugins for how well they separate design code from content (data).
HTML Markup
HTML Markup
The content for each page and post includes the HTML markup. The markup indicates which block of text is a headline, a regular paragraph, a list, a navigation menu, and lots more. This is called “semantic markup”. The markup gives the meaning of an element (like a headline), and that meaning is used by Google, screen readers, and people.
Content is stored with the markup. This might seem like design is included with the content, but it’s not.
Markup marks the kind of element, but it does not give any style or visual design. Browsers have default styles for each element. That’s what we see when no design is applied. Most important, we can apply styles to the markup using separate Cascading Style Sheets (CSS).
Content should be edited with a basic understanding of HTML and its use in page content.
Asset
Asset
Time Investment, Intellectual Property, Not Physical
The content of a website is an asset. It’s the result of a lot of time and money.
Pay attention to how much time you put into the text, pictures and video. With rewrites and edits, the time is a significant investment. Over a year or two or ten, it adds up. It isn’t a physical asset, but it’s still an asset. In legal terms it’s “intellectual property”.
Protect and build this asset by treating it as data and making sure you can move it, copy it, and reuse it.
Make sure your content-markup are separated from design, and design is separated from your content-markup. If there is some design in the content, keep it minimal and manageable.
Portable, Searchable, Long Lasting
Portable
Moving a site can be routine if content-markup is maintained properly by keeping design separate.
Searchable On Site
Searchability is important for sites with lots of content like articles, products, or tutorials. On-site search looks at the content for results. Core WordPress search is limited, but several plugins improve it.
On-site search is better if content-markup is maintained properly by keeping design separate.
Long Lasting
Content-markup can be used indefinitely with repeated design changes if content-markup is maintained properly by keeping design separate.
Designable
Designable
Design Theme Switchable
A design-only theme does not:
- alter or add to the content-markup
- alter permalinks or site URLs
- add pages or posts or custom post types
Plugins might do any of these, but themes should not. A website design can be swapped easily if design-only themes are used.
Shareable-Readable
Shareable and Readable
Generally, “shareable” and “readable” are expected. Behind the scenes, this is an advanced topic.
Computer Readable – Screen Readers
Standard HTML includes accessibility. Implementing websites to HTML standards gets you a long way to working with screen readers. It starts with the theme and plugins; they should publish valid HTML. And it continues with editors and writers; they should know how to create content with good HTML.
For screen readers, the HTML markup created by the theme, plugins, and site editors is important.
Computer Readable – Search Engines
Search engines are computers that read your site. Themes and plugins need to create good HTML; most do. And site editors need to create good HTML when they edit. That’s part of good SEO.
Computer Shareable – REST
This topic is advanced. Just realize it’s possible to send and receive data with non-WordPress systems. If you share page content with REST, the content should be formatted correctly. Themes and plugins that store extra code with content could hamper REST.
Human Readable
A website should be visually usable and readable on a phone, tablet, and computer. Most people check sites for general usability by sighted people. For the visually impaired and accessibility, Web Content Accessibility Guidelines (WCAG) should be met. (See the section Visual Design and Messaging under Design.)
Design
Design
For Humans, Colors, Text Size, Layout, Spacing
Design should be separated from content as much as possible. Design includes font sizes, colors, widths, animations, borders, and lots of visual style. The content with HTML (content-markup) is stored separately.
Technically, the design is done with Cascading Style Sheets (CSS). It’s literally separate code that tells browsers what the site should look like.
Change the CSS, and in an instant, the visual design can change without changing the content-markup.
Theme
Theme
Theme’s are the foundation for changing the overall design of a WordPress site. They can do much more, but at a minimum, they control the design.
Incorporates Data-Content
Incorporates Data-Content
The theme should incorporate the content-markup of your site. The theme should change only the visual appearance of your content.
Design Only
Design Only
Themes can add only separate CSS style to the site OR add so much extra code that the content can’t be easily restyled.
A design-only theme uses WordPress ways of templates, JavaScript, and CSS to manage the visual appearance and does not save extra code with the content.
All design is separate from the content-markup. Another design-only theme can be activated and the site should need little tweaking.
A Caveat: This Is Oversimplified and Ideal
This description of a design-only theme is a simplification of the ideal. In the real world, I expect most theme swaps to require some adjustments and tweaks.
Special Pages and Unique Layouts
Many websites have a unique layout for the home page or several other pages. These pages probably have to be recreated or tweaked for a new design. Identify these pages during a redesign; recreate them if needed.
Use the WP Way
Use the WordPress Way
Some themes and plugins do some things their own way instead of the WordPress way. This could make it difficult to change the design, especially if the plugin replaces the WordPress editor.
Use WP data storage
This gets into advanced technical issues. Don’t dig into this data storage unless you want to get into developer-level topics.
As already mentioned: Content-markup should be stored the way WordPress core saves it. The theme should not add its own code.
Use WP page editor Gutenberg (or Classic)
Page-builder themes and plugins take over WordPress editing. They can lock the site into using that theme or plugin. Converting back to the WordPress editor can be difficult.
If easy point-and-click design is a priority, page builders are a viable option, but they could disable an easy design swap in the future. Page builders also add extra code to the front end, usually slowing them down.
My advice: use the WordPress Gutenberg editor whenever possible. Avoid page builders unless point-and-click design by non-experts is a priority.
Childable
Childable
Making a copy of a theme is a very basic task in WordPress development. It’s called a child of a theme.
Child themes are the right way to change design and functions of the parent theme. Developers use child themes this way. Some plugins let users make child themes without the need to know code. (This is a simplification, but it’s the info needed for a high-level understanding.)
A child theme should work with a theme; the theme should be childable.
Minifiable, Cacheable +/-
Minifiable, Cacheable +/-
What is Minifying?
Unnecessary code can be removed from pages and posts. This is called minifying. This makes page size a little smaller and page loading faster. Some optimization and speed plugins minify pages.
What is Caching?
To speed up a site, a cache plugin pre-builds and saves pages as text files. These are called cached pages. When a visitor views a cached page, it can be served faster. This is perfect for pages that are the same for every user.
Some pages are unique for every user, like a page that displays the user’s name or account information. These pages have to be created at the time a user views the page. They should not be cached.
Applying Cache and Minify to Front End Content
When themes and plugins publish content on the front end, the pages should be cacheable by a cache plugin, and minifiable by an optimization plugin. And when themes and plugins create pages that should not be cached, those pages should be excluded from the cache.
Most optimization and cache plugins can exclude pages, posts, and URLs. Look for this when a plugin creates front-end content and pages. Make sure pages with user-unique information are not cached.
Functions: portable plugins
Functions: portable plugins
Themes can include everything you’ve ever seen a website do. But for designability and portability, some functions should not be in themes but in plugins that work with other themes.
These functions should be reviewed and possibly moved to plugins:
- adding or modifying content on any page or post
- Ideally and mostly, this should be done with the WordPress editor.
- This is different from changing design or CSS, which is what themes should do.
- changing URLs or permalinks
- Consistent URLs is very important for SEO. Changing a theme should not change URLs or permalinks.
- adding pages or posts or custom post types
- Changing a theme should not remove pages or posts.
If these functions are part of the theme, the content and functions are lost when the theme is changed. Stick to design-only themes.
Light, Valid HTML-CSS SEO, Accessibility, Mobile (SAM)
Light, Valid HTML-CSS
SEO, Accessibility, Mobile (SAM)
Light, valid HTML and CSS apply to many website decisions including themes. See the HTML-CSS section under Fundamentals.
Visual Design and Messaging
Visual Design and Messaging
The visual design is important. It affects project decisions and is influenced by other principles. It is very important to websites, but most people already evaluate visual design. And lots of advice is available online. This applies to messaging, too.
For now, I’m sticking to those considerations most people miss. What’s usually missed are other, not-so-cool issues that are technical and long term.
Make no mistake: visual design and messaging are very important. I’m leaving them for another day.
Fundamentals
Fundamentals
These fundamentals apply to all modern websites, not just WordPress.
“Just Works” is the Standard
“Just Works” is the Standard
Of course a site should just work today. And it should also just work when WordPress is updated, and when plugins are updated, when editors edit, writers write, and users use. In six months, and in twelve months. And when you move the site somewhere else. It should just work. That’s the ideal.
Regardless, since sites run on computers, small bugs and sometimes major failures pop up. Expect them. Plan for them.
You can try to prevent problems by reducing risk, limiting code to only what’s needed, and planning proper resources.
Reduce “doesn’t work” risk factors
Everything added to a site increases the risk of bugs. So use only the plugins needed, audit all plugins for their impact on speed, code, and data. See the details under the Plugins section.
This applies to themes. The more a theme does, the higher the chance it affects code, data, and speed.
Users, writers, and editors are part of the project. They can affect code, data, and speed. If needed, limit what non-expert users can do.
Documentation helps reduce the risk of user errors.
Use extra code and plugins judiciously when needed or wanted
Most websites require customization, even if it’s limited to changing colors. That means extra code of one kind or another. Do it. The site should meet requirements and priorities. Then test the site.
Be mindful of support and “risks”
Every function of a site could increase the need for support. Multiply that by the number of users/editors.
Sometimes you need support from the web developer. Sometimes you need to support users and answer questions. Be ready for it. Plan for it.
Be mindful of stacking complexities/risks
Be mindful of stacking complexities/risks
A good way to explain stacking complexities is an example.
For this example, first understand that WordPress has a User administration section where accounts can be managed for admins, editors, and contributors. Now for the example.
A membership site added these plugins:
- A forum plugin that added fields and functions to WordPress users.
- A user profile plugin that added fields to WordPress user profiles.
- An e-mail plugin that added user subscriptions to e-mails about various topics.
- A security plugin that added security features to WordPress Users including two-factor authentication.
- The Elementor page-builder plugin that adds a user role management screen.
The site had multiple places to manage users. Each plugin added capabilities. Some capabilities were used, some were not. Some plugins got in each other’s way. There was no way to quickly understand how to manage users and where to manage which capabilities. The good news is that the site worked and did what the client wanted. The bad news, admins struggled to figure out how to manage the over 1000 users.
If the site had to be this complicated, documentation on how each plugin is used would have helped. Documentation for admin tasks would help, too.
For stacking risks, it’s what I said earlier: Everything added to a site increases the risk of bugs. For general guidelines:
- Add only the plugins you need.
- Look for plugins that are lightweight.
- Look for plugins that are limited to what you need without extra features.
Priorities
Priorities
Your priorities guide decisions. Principles like “use as little code as possible” are good. But websites serve one or more purposes, so websites should fulfill those purposes no matter how much code is needed. Here are some typical priorities.
Content Management
WordPress is a content management system. If nothing else, every WordPress site publishes pages (non-dated pages) or posts (dated articles like news, tutorials, or updates). The content of these pages is managed through WordPress. If long-term use of the content is important, avoid themes and plugins that save design with the content.
SEO, Accessibility, Mobile (SAM)
In 2022, SAM is nearly always in the mix of priorities.
Ecommerce and Support
Beyond a simple store, e-commerce can become complicated quickly. Any item could have variations of color, size, and other features. One item with 10 colors and 5 sizes could become 50 items with different prices, inventory and shipping costs.
The more online sales you have, the more you have to provide support and answer questions about using the website. Be ready for it. Plan for it.
Customer and Tech Support
Does the site offer support for clients? Documentation? Downloads? Does it require users to log in?
User Editing and Designing
Does the site have multiple editors, designers and contributors? What do they need to edit?
Custom Functions and Specs
What custom specifications or functions are needed?
Light, Valid HTML-CSS
Light, Valid HTML-CSS
This is a best practice: use as little code as possible to achieve the functions and design you want. Light HTML-CSS that passes validity testing is the start of preventing problems and getting good SAM.
SEO, Accessibility, Mobile (SAM)
SAM is relevant in many website decisions. Valid light-weight HTML-CSS is good for SAM.
Backup & Update WP, Plugins
Backup & Update WP, Plugins
At least Yearly, Daily for high-use Sites
WordPress sites can be backed up, moved and archived.
You should have at least one backup, the one you get when the site is launched. Keeping at least one backup protects your investment. With it you can move the site to new hosting service.
After that, you should save a backup after major changes to content, WordPress, or plugins.
How often?
- Just before you update WordPress and plugins. This backup can be restored if the update breaks your site.
- Right after a successful update of WordPress and plugins. This backup can be restored if your site breaks or you need to move it in the future.
- When the content or data is updated enough that recreating it would be difficult. For high-volume e-commerce sites, this could be daily.
- At least yearly, before and after updating WordPress and plugins.
Updating WordPress and Plugins Yearly
Pacesetter Media recommends at least yearly maintenance to backup a site and update the software, more often for active sites.
WordPress and its plugins are the software that runs your site. WordPress is updated at least monthly with major updates a few times a year. Plugins are updated regularly. These updates do several things:
- apply security patches
- add new features
- fix bugs
In software, minor bugs are continuously uncovered. Major bugs creep in, too. WordPress and plugin makers continuously track them and fix them with the next release. - adjustments for best practices
WordPress and many plugins publish HTML, the code that makes your public website. What is considered best practice evolves, sometimes for “real” reasons like confirmed changes to how Google works and sometimes for “perceived” reasons like whatever the latest buzzword is.
Accumulated Updates Means Accumulated Risk
Updates accumulated over a long time can increase the risk of a failure when updating a site. Updating quarterly is a good practice, but some sites can get by with yearly updates. A simple brochure site with content that’s never updated could go for years without updating the software; when these sites are updated, the risk of problems is at least slightly higher.
To be clear, updating WordPress and plugins is usually easy. I’ve found that it usually just works. But when there is a problem, it can be very inconvenient, especially with an automatic update. Often the only solution is to revert to the latest backup. That happens often enough that you should minimize the risk, and always create a backup before updating the software.
Automatic Updates Sometimes Create Inconvenient Failures
Automatic updates are an option, but they can cause sudden conflicts with WordPress and plugins. And you might not know it until somebody reports that your site is broken. I’ve been called in for just such sites. It’s not often, but when it happens, it’s very inconvenient.
Use Client-Side Scripts Judiciously
Use Client-Side Scripts Judiciously
Most of what you see on websites comes from code run on the website server. It constructs the HTML and CSS for a page and sends it to your browser.
In addition, some of what you see comes from executable code that is downloaded to your computer; it runs on your computer and changes the HTML that’s already downloaded. This is called client-side code, usually JavaScript. WordPress comes with some front-end JavaScript, but themes and plugins can add more.
It’s possible to overdo it. The wrong implementation can make content unreadable by search engines and screen readers, and it can slow a site or break it.
But use when it does something you want
JavaScript does cool, useful stuff. Use it if you need to. Then check speed and the ability of Google to read the site content.
Otherwise, reduce or remove
Otherwise, remove unused JavaScript as much as possible. If it slows your site, consider getting rid of that cool JavaScript feature you like.
Documentation
Documentation
The more complicated a site, the more you need documentation. The more editors, writers, and users you have, the more you need documentation.
User Notes and How-To
For users, documentation could be basic info like what menu items to use or avoid. For complicated sites with extra features and plugins, this could be complete step-by-step instructions. Start with these priorities:
- site-specific tasks
- site-specific custom plugins and functions
- non-typical off-the-shelf plugins
- tasks you or others need to remember in 3 months or longer
- typical plugins
- typical plugins are those used on most sites: contact forms, SEO, cache
Don’t prioritize documentation that’s available at WordPress.org or plugin sites.
Developer Notes and Why
Presume that somebody else will work on the site in the future. Keep notes and documentation on:
- why any plugin is used, especially if the plugin is complicated or not typically used
- which features of which plugins are used or not
- decisions that effect SEO, URLs, custom CSS, third-party services
Think Long Term
Presume that you won’t work on the site again for 12 months. What will you need to remember about the site? Imagine people completely unfamiliar with the site development and decisions. What do they need to know?
This long-term thinking applies to developers, managers, editors and users. Future users won’t know any specifics about your site. Keep notes and documentation for them.
In six months, they’ll thank you or you’ll thank yourself for the documentation.
Plugins
Plugins
Functions, Data-Content, Markup, Design
Plugins are the WordPress way to add code and functions to a site. A plugin can do nothing or everything you’ve ever seen a website do or anything in between. Lots are available for free at WordPress.org. Some cost money for extra features and updates. Developers can create custom plugins. In fact, it’s kind of easy.
They can add design elements, small functions, or complex systems of functions. They can even disable parts of WordPress. They can affect anything or everything about your site.
Plugins are great because they can do anything. And they are dangerous because they can do anything.
Portable, Non-Theme-Dependent
Portable, Non-Theme-Dependent
Ideally, plugins can be used with any theme. This is especially important if they publish public content on your site.
Speed
Speed
Extra code sometimes slows a site. All plugins are made with code, and many add code to your front-end public site.
Check the site speed after installing a plugin, especially if it affects the front end.
Cacheable, Minifiable +/-
Cacheable, Minifiable +/-
See the Cacheable, Minifiable +/- section under Design > Theme
Use the WP Way
Use the WordPress Way
Some plugins do some things their own way instead of the WordPress way. This could make it difficult to change the design, especially if the plugin replaces the WordPress editor or saves extra code with the content-markup.
Data Storage
This gets into advanced technical issues. Don’t dig into this if you’re not a developer or coder.
The quick advice: If the plugin content is an important part of site content, the plugin should be independent from the theme and usable with any theme.
Page Builder/Gutenberg
See the information under Design >Theme > Use the WP Way > Use WP page editor Gutenberg. It applies to plugins.
Light, Valid HTML-CSS SEO, Accessibility, Mobile (SAM)
Light, Valid HTML-CSS
SEO, Accessibility, Mobile (SAM)
See the section under Fundamentals. SAM applies to many website decisions including plugins.
Bloat
Bloat
“Just Add a Plugin” Judiciously
Plugins solve problems and make sites do cool things. The repository of plugins at WordPress.org is a great resource. Use it. But take care about the “Just Add a Plugin” approach. Every plugin adds code which increases the risk of problems. Apply these principles if you can:
- Install the lightest, smallest, most limited plugin that does what you want.
- Deactivate those you don’t need.
- Before installing, read reviews, try demos, and read the documentation.
- If you can, test the plugin on a staging site first.
- Sometimes plugins leave traces of code or data even after removal. It’s better to litter a test site with these traces instead of your live site.
Audit for Overly Complicated Plugins
Many plugins add an entire system of features including the one thing you want. Try to avoid these. If you need one small function, try to find a plugin that does that one thing.
Sometimes a one-thing plugin is not available. In that case, try to find the most limited plugin that does that one thing.
Sometimes a complicated plugin has many functions you want and at least some you don’t need. For yourself and future users, document how your site uses it and which features you’re not using.
Paid Plugins
Paid Plugins
Many paid plugins are well worth the cost.
Subscription to Updates and Support
Many paid plugins work even after the expiration because the payment is for updates and support, not for the software loaded on your site. Once the expiration passes, the plugin is still installed and activated, so it still works. But you won’t be able to update it without renewing the subscription.
Subscription to Off-Site Services
If a plugin is connected to an off-site service, that service could be disabled on the expiration date, and that plugin could fail.
Plugin Receipts and Account Information
When you pay for a plugin, you often get an account with the plugin creator. Keep the receipts and logins for those accounts. And keep a calendar or list of expiration dates.