WordPress plugin vs theme, which feature goes where

The rule of thumb

The common guidance is simple: a feature that changes behaviour belongs in a plugin, and a feature that changes presentation belongs in a theme. Behaviour includes custom post types, shortcodes, API integrations, redirects and business logic. Presentation includes layout, fonts, colours and how content is displayed. A theme makes a site look a certain way; a plugin makes it do something.

The reason this boundary matters shows up the moment you start WordPress troubleshooting. When you switch a theme to rule out a styling problem, you expect the site's functionality to keep working. If that functionality was installed inside the old theme's functions.php, switching themes silently removes it, and suddenly the site looks normal but has lost its custom behaviour, which is a classic source of a blank or broken site that is hard to attribute.

The swap test

Run a mental swap to classify a piece of code:

1. If I change the theme, should this feature survive? If the answer is yes (a booking form, a product importer, a redirect rule), it belongs in a plugin, because a theme change is not supposed to destroy functionality.
2. If I disable a plugin, should the visual layout stay intact? If the answer is yes (spacing, colours, fonts), it belongs in the theme, because presentation should not depend on an optional plugin being active.
3. If the answer is neither, treat it as shared and isolate it. Generic helpers used across both, such as a small utility function, can live in a plugin as a lightweight module, keeping the theme purely presentational.

This becomes sharper with a child theme. Presentation tweaks belong in a child theme rather than edited into the parent theme, so updates to the parent theme do not overwrite your changes. But a child theme is still the wrong place for behaviour: put the logic in a plugin and keep the child theme for overrides to markup and styling.

Applying it cleanly

• Keep business logic out of functions.php. Reserve the theme file for actions and filters that shape presentation. Custom functionality that does real work is better as a plugin, which survives template changes and is easier to disable independently during a plugin conflict ladder.
• Do not lock a feature to a single theme. Features such as security headers applied via a theme die with it. The security headers guide shows header logic that stays active regardless of theme.
• Reach for plugins for feature-like tools, not just third-party plugins. A "plugin" in this sense means a unit of functionality, which you can build yourself as a plugin rather than padding functions.php. This mirrors how real themes are shipped with only presentation and how robust sites keep behaviour in the plugin layer.

The payoff is a site you can diagnose. When an update or a theme switch breaks something, the troubleshooting order lets you separate "the styling changed" from "the feature disappeared" cleanly, because the feature's home (plugin) is distinct from the skin (theme). If a behaviour feature still lives in a theme, moving it to a plugin before a big theme change removes an entire class of "the site lost functionality after I switched themes" faults before they occur.