7 WordPress Tricks I Actually Use on Client Sites in 2026

Most “WordPress tricks” lists are written by someone who has never had to fix a site at 11pm before a launch. These are things I use on real builds, including local businesses around Commack and the rest of Long Island. Nothing here is exotic. It is just the stuff that holds up.

1. Use a block theme with theme.json instead of fighting the customizer

By 2026 the block editor has matured to the point where a classic PHP theme is a liability for most new projects. The Customizer is deprecated, and the future is theme.json. The nice part is you can define your spacing scale, color palette, and typography once and have it apply everywhere, including the editor, so what a client sees while editing matches the front end.

{
 "$schema": "https://schemas.wp.org/trunk/theme.json",
 "version": 3,
 "settings": {
 "color": {
 "palette": [
 { "slug": "brand", "color": "#1f4e79", "name": "Brand Blue" },
 { "slug": "ink", "color": "#141414", "name": "Ink" }
 ]
 },
 "spacing": {
 "units": ["px", "rem", "%", "vw"],
 "spacingSizes": [
 { "slug": "40", "size": "1rem", "name": "Small" },
 { "slug": "50", "size": "2rem", "name": "Medium" },
 { "slug": "60", "size": "4rem", "name": "Large" }
 ]
 },
 "typography": {
 "fluid": true,
 "fontSizes": [
 { "slug": "body", "size": "1rem", "name": "Body" },
 { "slug": "heading", "size": "clamp(1.75rem, 4vw, 2.75rem)", "name": "Heading" }
 ]
 }
 }
}

Fluid typography (that clamp() above) means fewer media queries for headings. One less thing to maintain.

2. Register blocks you reuse, do not copy-paste patterns

If you find yourself rebuilding the same call-to-action section on every site, make it a block pattern with a locked structure. Patterns live in /patterns/ as plain PHP or HTML files and show up in the inserter automatically.

<?php
/**
 * Title: CTA Band
 * Slug: mytheme/cta-band
 * Categories: featured
 */
?>
<!-- wp:group {"align":"full","style":{"spacing":{"padding":{"top":"var:preset|spacing|60","bottom":"var:preset|spacing|60"}}},"backgroundColor":"brand","layout":{"type":"constrained"}} -->
<div class="wp-block-group alignfull has-brand-background-color has-background">
 <!-- wp:heading {"textAlign":"center","textColor":"ink"} -->
 <h2 class="wp-block-heading has-text-align-center has-ink-color has-text-color">Ready to talk?</h2>
 <!-- /wp:heading -->
</div>
<!-- /wp:group -->

Clients get consistent output, and you stop shipping the same markup by hand.

3. Cache at the object level, not just the page level

Page caching plugins are fine, but on a busy site the database is usually the bottleneck. WordPress has had a persistent object cache API forever, and with Redis or Memcached it is a one-line config change in wp-config.php plus a drop-in.

// wp-config.php
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_CACHE_KEY_SALT', 'example.com:' );

// In your plugin or theme, cache an expensive query
$posts = wp_cache_get( 'homepage_featured', 'mytheme' );

if ( false === $posts ) {
 $posts = get_posts( [
 'post_type' => 'post',
 'posts_per_page' => 6,
 'meta_key' => 'featured',
 'meta_value' => '1',
 ] );
 wp_cache_set( 'homepage_featured', $posts, 'mytheme', 300 );
}

That 300 is a 5 minute TTL. Tune it to how often the content actually changes. Caching something for an hour when it changes every ten minutes is how you end up debugging “why is my site stale.”

4. Set up security headers and disable XML-RPC properly

Most WordPress “security” advice is plugin recommendations. A few server-level settings do more. Add these to your Nginx config or .htaccess, and turn off XML-RPC unless you have a specific reason to keep it (the Jetpack connection is the usual one).

# Nginx
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=()" always;

location = /xmlrpc.php {
 deny all;
 access_log off;
 return 403;
}

Combine that with automatic minor version updates (which are on by default since 3.7) and a real staging environment. The staging piece matters more than any single plugin, because it lets you update plugins without holding your breath.

5. Kill unused CSS and scripts instead of adding a “speed” plugin

If you are not using the block library on the front end, you do not need its CSS. Dequeue what you are not using. This is a two-minute change that saves real kilobytes.

add_action( 'wp_enqueue_scripts', function () {
 // Remove block library CSS if you are not using core blocks on the front end
 wp_dequeue_style( 'wp-block-library' );
 wp_dequeue_style( 'wp-block-library-theme' );

 // Remove emoji detection script and its styles
 remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
 remove_action( 'wp_print_styles', 'print_emoji_styles' );
}, 100 );

Be careful with the block library one. If your theme uses core blocks, leave it alone. Test on a staging copy first, always.

6. Use WP-CLI for anything you would otherwise do by hand

Search-replace on a database migration is the classic example. Doing it in a plugin UI is slow and error-prone. Doing it with WP-CLI is one command and it is safe if you dry-run first.

# Always dry run first
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --dry-run

# Then for real, skipping GUIDs
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --skip-columns=guid

# Handy for debugging
wp plugin list --status=active
wp cron event list

I keep a short WP-CLI cheat sheet pinned. It saves more time than any admin plugin I have ever installed.

7. Write your own deployment, even if it is boring

FTP drag-and-drop is how sites break. A small deploy script using rsync or a Git push to a staging branch is enough. It does not need to be clever.

#!/usr/bin/env bash
set -euo pipefail

THEME="wp-content/themes/mytheme"

rsync -avz --delete 
 --exclude '.git' 
 --exclude 'node_modules' 
 ./ "$THEME" 
 user@host:/var/www/site/"$THEME"

ssh user@host "cd /var/www/site && wp cache flush"

Notice the wp cache flush at the end. Forgetting that step is why people think their deploy “did not work.”

A note on the local angle

None of this is different because you are in New York. But clients in Nassau and Suffolk tend to have the same handful of needs: a site that loads fast on a phone, a contact form that actually delivers, and someone who can make a change without a three-day ticket. If you would rather hand the whole thing off, that is what custom web development for local businesses looks like in practice. The tricks above are just the baseline.

FAQ

Do I need a block theme in 2026?

For new sites, yes, unless you have a strong reason not to. Classic themes still work and will for a while, but the tooling and the plugin ecosystem are moving toward block themes, and starting classic in 2026 means a migration later.

Is a caching plugin enough for performance?

Page caching helps, but if your database is the bottleneck you want a persistent object cache too. And the fastest win is usually removing code you do not need, not adding another plugin.

How often should I update WordPress plugins?

Monthly at minimum, and immediately for security releases. The trick is having a staging site so you can update there first and catch conflicts before they hit production.