Fixing Real SEO Bottlenecks on WordPress Sites with Actual Code

Table of Contents

1. Stop using all in one plugins for SEO heavy lifting

I made this mistake twice. First time was installing Yoast Premium thinking it would do magic. Second time was when Rank Math lured me with schema wizardry and a slick UI. Both times, I ended up debugging post head tags manually and screaming at WP hooks documentation like it owed me money.

The issue isn’t that these plugins are useless — they’re overkill for most setups and they bloat your HTML like it’s getting paid by the kilobyte. If your theme spits out <title> tags and JSON-LD already, no need for a plugin to fight it.

Killing the plugin dropped my TTFB by 180ms
I hardcoded my meta titles using wp_title() and get_post_meta() conditions
Canonical tags? You can do that in your functions.php and forget about it

The real kicker: some themes render open graph and Twitter cards separately, not knowing the SEO plugin duplicates them. Result? Facebook sees two og:descriptions and picks neither.

2. Manage indexability instead of just crawling and praying

I ran into this when Google indexed a WooCommerce cart URL with ?removed_item= payloads and started ranking them for product terms. Should’ve seen it coming when my index had quadruple the number of pages shown in the sitemap.

The misconception is everyone thinks robots.txt is the first line of defense. It isn’t. Blocking with robots.txt keeps the pages out of crawl, but not out of the index if someone links to them.

Better approach

I started doing this instead:

add_action('template_redirect', function() {
  if (is_cart() || is_checkout()) {
    header('X-Robots-Tag: noindex, nofollow', true);
  }
});

Now it doesn’t matter if it’s linked somewhere — Google gets the message loud and fast. Also, WordPress will happily let archive pages exist forever with zero content. Disable author archives unless you have actual multi-author content. Same for date archives. Toss a 404 or 410.

3. Avoid AJAX-driven content that breaks crawlability on mobile

Two weeks went by before I noticed Google had stopped rendering certain mobile elements — turned out my category grid loaded via jQuery after DOMContentLoaded, and on slow 3G emulator testing, the content never appeared at all.

The problem wasn’t CLS or Core Web Vitals — it was that Googlebot Mobile literally couldn’t see the bulk of my category links because they showed up 3 seconds after everything else and required scroll to trigger. I had mixed infinite scroll and delayed fetch assuming everyone behaved like Chrome with cached JS. Big mistake.

The fix was to bake the initial state into the HTML, then use JS only to hydrate the interactivity. Think server-side render the essentials, client side enhance later. If you have a WooCommerce filter plugin that only swaps in new content client-side, make sure you at least echo the default state into the HTML so bots see something.

4. Rewrite your pagination templates to avoid canonical cannibalization

I once lost a keyword because page two of my blog category had a higher click-through rate than page one. Google decided it was more relevant and started ranking that instead. Yeah, page two — the one that opened with a post from 2018 about GDPR basics.

WordPress by default spits out the same <title> and canonical link on paginated archive views unless the theme handles it. Most don’t. You’ll end up with /category/page/2/ and /category/page/3/ having the same canonical URL as /category/ — which introduces duplicate content issues and splits signals.

The fix, after a horrifying bout of staring at wp_head() output for an hour:

add_filter('wpseo_canonical', function($canonical) {
  if (is_paged()) {
    global $wp;
    return home_url(add_query_arg(array(), $wp->request));
  }
  return $canonical;
});

Or just fire WPSEO and roll your own canonical logic. At the very least, add a page number to your title tag manually so you don’t look broken in SERP previews. Easiest place is under archive.php or category.php inside the head tag, conditional on is_paged().

5. Control Open Graph output directly because most plugins fail at fallback logic

I found this one when Facebook kept defaulting my homepage description to the site tagline “Just another WordPress site” even though I had custom text set in the SEO plugin. Turns out the plugin didn’t detect front-page.php correctly and never populated meta tags for that page type.

Also, most Open Graph plugins don’t deal well with multisite or homepages using custom queries — they rely on WordPress globals like is_front_page() or get_the_excerpt() which are blank if your home template is widgetized or uses WP_Query directly.

Reliable method

function custom_og_meta() {
  if (is_front_page()) {
    echo '<meta property="og:title" content="Your Brand Page">';
    echo '<meta property="og:description" content="Real description here.">';
  }
  else if (is_single()) {
    global $post;
    echo '<meta property="og:title" content="' . get_the_title() . '">';
    echo '<meta property="og:description" content="' . get_the_excerpt() . '">';
  }
}
add_action('wp_head', 'custom_og_meta');

This way you always know what’s being output. Bonus: no plugin conflicts or double tags when social card previews break unexpectedly.

6. Purge default sitemaps and generate your own on deploy

A creative depiction of using Cloudflare rules to force cache headers for SEO-critical assets within a loop of launch emails, emphasizing the importance of optimization.

Here’s the mess I walked into: I had two sitemaps. One auto-generated by Rank Math at /sitemap_index.xml and another custom one output by a CI deploy hook at /sitemap.xml. Google pulled both, but half the indexed URLs were from one, half from the other — and some URLs weren’t in either.

The issue is WordPress generates default sitemaps now via wp-sitemaps.php unless explicitly disabled. You end up with conflicting canonical declarations if plugins or themes output different lastmod timestamps, and Google is bad at reconciling those.

Disable it with this line in functions.php:

add_filter('wp_sitemaps_enabled', '__return_false');

Then roll your own generator that accounts for custom post types, language switches, or ecommerce taxonomies. I bake mine via Laravel’s sitemap package and cron-push it via FTP and Cloudflare cache bypass.

You can use the default, but don’t run multiple versions unless you love inconsistent coverage graphs in Search Console.

7. Watch out for Unicode slugs that wreck your SEO preview

This one surfaced with a German headline using an emoji in the post title — my “🚀 Schnell starten mit WooCommerce” post got slugged to something awful like /%f0%9f%9a%80-schnell-starten. It looked hideous in SERPs and tanked CTR instantly. Yeah, it displayed the UTF-8 string encoded as percent escapes. Not exactly readable.

Turns out WordPress tries to sanitize slugs but doesn’t handle emojis or control characters gracefully. Also, if you’re wire-pushing posts through REST or via Zapier, the slug might never get sanitized at all. Saw a post slug become an empty string — WordPress filled in the title, but left post_name as a blank, which broke permalinks silently.

Quick fix: use the sanitize_title filter and strip anything non-slug-safe yourself before save_post fires.

add_filter('sanitize_title', 'force_slug_strip_emoji', 10, 3);
function force_slug_strip_emoji($slug, $raw_title, $context) {
  $slug = preg_replace('/[\x{10000}-\x{10FFFF}]/u', '', $slug);
  return $slug;
}

Better yet, write slugs manually if the title’s got punctuation, foreign characters, or — God help you — non-breaking spaces.

8. Use Cloudflare rules to force cache headers for SEO-critical assets

I had this issue where Rendertron-based SSR was serving fresh HTML every time — except browser caching wasn’t doing anything because my font assets and main.js got served with Cache-Control: no-store. Why? Because WP default doesn’t declare caching headers, and nginx just passed them on as-is. Wasted bandwidth, broken Lighthouse scores, and Googlebot hitting the cache-miss wall repeatedly.

Cloudflare rules solved that in two directives:

Match requests to *.js, *.css, *.woff2 — force cache for 30 days
Set Edge Cache TTL for /?render=true URLs for 15 minutes
Enable HTML auto-minification but disable Rocket Loader (broke WooCommerce cart)

This knocked maybe 400ms off paint and let crawler hits reuse more resources instead of re-downloading the rendering shell. Worth every minute I spent combing Cloudflare’s UI looking for where the page rules actually live now.