DEV Community: Raj Patel

WordPress Technical SEO: The Fixes That Actually Improve Rankings

Raj Patel — Sat, 13 Jun 2026 12:23:07 +0000

WordPress technical SEO is where most sites leave ranking potential untouched. This covers the specific fixes that move the needle and the ones that mostly do not.

WordPress technical SEO gets conflated with content strategy more often than it should. The two are different disciplines. Content strategy determines what you publish and who you are targeting. Technical SEO determines whether Google can find, crawl, understand, and rank what you have already published. You can write excellent content and still rank poorly if the technical foundation underneath it is broken.

The frustrating part is that technical SEO issues are often invisible until you go looking for them. A misconfigured robots.txt file, a canonical tag pointing to the wrong URL, a page with a noindex setting left over from development, or a Core Web Vitals score that dropped after a plugin update. None of these produce an obvious error message. They just quietly suppress rankings that should be higher. After auditing WordPress sites for businesses across multiple industries worldwide, the same issues appear repeatedly. This post covers the ones that actually matter and how to fix them.

The Difference Between Technical SEO and Content SEO

Before going into specific fixes, it is worth being clear about what technical SEO actually covers. This matters because the two are often confused and the confusion leads to misdiagnosed problems.

Technical SEO is foundational. It does not replace content quality but it determines whether your content gets a fair chance to rank. A site with excellent content and poor technical SEO will underperform. A site with mediocre content and perfect technical SEO will also underperform. Both need to be right.

Core Web Vitals: What Actually Matters in WordPress

Core Web Vitals became a ranking factor in 2021 and have remained relevant since. The three metrics Google measures are Largest Contentful Paint (how fast the main content loads), Cumulative Layout Shift (how much the page jumps around during loading), and Interaction to Next Paint (how quickly the page responds to user input).

In WordPress specifically, each of these has predictable causes that appear across many sites.

Largest Contentful Paint problems

LCP measures the time from page load to when the largest visible element finishes loading. In WordPress this is almost always either a hero image or a large above-the-fold image. The most common causes of poor LCP scores are unoptimised hero images, images not set to preload, images being lazy-loaded when they should not be, and slow server response times. On many WordPress sites we audit, a single unoptimised hero image is responsible for an LCP score of 4 to 6 seconds when it should be under 2.5 seconds. The fix is usually straightforward: compress and convert the hero image to WebP format, add a preload hint for it in the head, and disable lazy loading specifically on above-the-fold images.

Cumulative Layout Shift problems

CLS measures unexpected layout movement during page load. In WordPress the most common causes are images without explicit width and height attributes, web fonts loading and causing text reflow, and embeds or ads that push content down when they load. Fixing CLS in WordPress usually involves auditing every image on key pages to confirm width and height are set in the HTML, enabling font-display:swap on custom fonts, and ensuring any third-party embeds have explicit dimensions.

Interaction to Next Paint problems

INP replaced First Input Delay as a Core Web Vitals metric in 2024. It measures the time from a user interaction to when the page visually responds. In WordPress the primary culprit is JavaScript execution blocking the main thread. Every plugin that loads JavaScript on the frontend contributes to this. Page builders that load large JavaScript bundles, slider plugins, chat widgets, and analytics scripts all compete for main thread time. The fix requires auditing which scripts are loading on each page and deferring or removing what is not necessary.

The Technical SEO Architecture of a WordPress Site

Understanding how the pieces connect makes diagnosing and fixing issues significantly easier. Most WordPress sites have the same fundamental structure from a technical SEO perspective.

The Eight Technical SEO Fixes With the Most Impact

When Technical SEO Is Not the Problem

Not every ranking problem is a technical SEO problem. It is worth being honest about this because chasing technical fixes when the real issue is content or competition wastes time and creates the wrong expectations.

If your pages are correctly indexed, have clean canonical tags, pass Core Web Vitals, have proper schema, and still rank on page 4 or 5, the issue is almost certainly one of three things. The content is not matching search intent well enough. The site does not have enough authority through backlinks compared to competing sites. Or the keywords being targeted are simply too competitive for a site at the current domain authority level.

Technical SEO creates the foundation. It removes the obstacles that prevent good content from ranking. But it does not substitute for content quality, topical authority, or backlink strength. A site with perfect technical SEO and thin content will still rank poorly. A site with strong content, genuine authority, and solid technical SEO will rank well. The technical layer needs to be right so the content layer has a fair chance to perform.

A Practical WordPress Technical SEO Audit Checklist
This is the sequence we work through when auditing a WordPress site for technical SEO issues. Working through it in order catches the high-impact problems first.

How Technical SEO Fits Into Ongoing WordPress Maintenance

The most effective approach to WordPress technical SEO is not a one-time audit but a recurring check built into an ongoing maintenance routine. Technical issues in WordPress do not only appear at launch. They appear after plugin updates that change how JavaScript loads. After theme updates that alter page templates. After content migrations that create new URL structures. After server moves that change caching behaviour.

A site that passes a full technical SEO audit today may have new issues in three months if nothing is monitoring for them. The WordPress maintenance checklist we publish covers which technical checks should happen monthly and which can be done quarterly. The pattern we follow for maintenance clients in India and across businesses worldwide is to run a lightweight technical check after every significant update and a full audit quarterly. This catches issues while they are small rather than after they have been suppressing rankings for months.

The technical SEO checks described in this post are included as part of our WordPress maintenance plans. For sites that need a one-time technical SEO audit and cleanup rather than ongoing maintenance, our WordPress development service covers that as a standalone project. The starting point is always a proper audit that identifies what is actually broken rather than applying generic fixes that may not address the real issue on your specific site.

Bottom line: WordPress technical SEO is not glamorous work but it is the work that determines whether good content gets a fair chance to rank. A site with clean canonicals, correct indexing, fast Core Web Vitals, proper schema, and no crawl errors gives every piece of content the best possible foundation. Skipping this layer and focusing only on content is like building on unstable ground and wondering why results are not coming.

Why Your WooCommerce Store Is Slow (And It's Probably Not What You Think)

Raj Patel — Tue, 02 Jun 2026 05:18:05 +0000

Most performance guides for WooCommerce start and end with caching plugins. Install WP Rocket, enable page caching, done. If your store is still slow after that, the advice usually becomes "upgrade your hosting."

Neither of those fixes the actual problem in most cases.

After working on WooCommerce stores for 15 years, the pattern is clear: slow WooCommerce stores are almost always a database problem. The cache layer helps at the surface. But if the underlying queries are inefficient, caching just means the slow response gets cached instead of fixed.

This post covers where the slowdown is actually coming from and what you need to look at before throwing money at hosting upgrades.

The Real Architecture Problem

WooCommerce stores everything in WordPress's default database structure. Products, orders, customers, variations, custom fields — everything goes into wp_posts and wp_postmeta. That structure works well at small volumes. At scale it becomes the primary bottleneck.

Here is why. Every product page load triggers joins across wp_posts and wp_postmeta to fetch:

Product data
Variation data and pricing
Stock levels per variation
Related products
Custom fields and attributes
Review counts

On a simple product that is manageable. On a variable product with 50 variations it is a significant number of queries. On a shop page showing 24 products simultaneously, those queries multiply fast.

The problem gets worse as the store grows because wp_postmeta accumulates rows from every product, every order, every customer, and every piece of metadata attached to anything. Queries that were fast when the table had 10,000 rows become noticeably slower at 500,000 rows.

What Query Monitor Actually Shows You

Before you do anything else, install Query Monitor. It is free and it shows you exactly what is happening on each page load.

What you are looking for:

Total query count per page — a typical product page should be under 50 queries. If you are seeing 150 to 300 queries, something specific is causing that.

Duplicate queries — Query Monitor highlights queries that run multiple times in the same page load. This often points to a plugin calling the same data repeatedly without caching the result.

Slow queries — anything over 50ms on a single query is worth investigating. A query taking 200ms that runs 10 times per page load is 2 full seconds of avoidable overhead.

Queries by component — this tells you which plugin or theme file is generating each query. When you see a plugin responsible for 40 out of 80 queries on a page, that is your culprit.

The Five Actual Causes Worth Fixing

1. Variable products with too many variations

A product with 200 variations triggers WooCommerce to fetch data for all 200 on every page load. Most stores accumulate these over time without realising the performance cost.

Fix: Audit variation counts on high-traffic products. Delete or archive inactive variations. For products that genuinely need large variation counts, implement object caching so variation data is served from Redis rather than re-queried on every request.

2. No object caching layer

WordPress has a built-in object cache API but by default it only persists for the duration of a single request. Without a persistent cache backend like Redis or Memcached, WordPress rebuilds cached objects from the database on every request, even within a single page load.

Fix: Add Redis object caching. On most managed hosts this is a one-click addition. The difference on a WooCommerce store with significant product and variation data is immediately measurable.

// In wp-config.php after Redis is configured
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);

Then install the Redis Object Cache plugin and enable it. Query Monitor will show you the reduction in database queries immediately.

3. WooCommerce transients accumulating

WooCommerce uses transients extensively to cache things like product counts, shipping calculations, and tax data. These get stored in wp_options with autoload enabled. Over time, expired transients accumulate and WordPress loads them all on every page request because of the autoload flag.

Fix: Run a cleanup query to remove expired transients:

DELETE FROM wp_options
WHERE option_name LIKE '%_transient_%'
AND option_name NOT LIKE '%_timeout_%'
AND option_value < UNIX_TIMESTAMP();

Then schedule regular cleanup using WP-Cron or a plugin like WP-Optimize. Check the size of your wp_options table — if it is over 10MB with autoloaded data, transient accumulation is almost certainly contributing to slow page loads.

4. HPOS not enabled for orders

WooCommerce's High Performance Order Storage (HPOS) moves order data from wp_posts and wp_postmeta into dedicated order tables with proper indexing. For stores doing significant order volumes the difference in order query performance is substantial.

Check if it is enabled in WooCommerce > Settings > Advanced > Features. If your store is on a recent version of WooCommerce and you have not migrated yet, this is one of the highest-impact single changes you can make.

The migration is handled by WooCommerce itself and includes a compatibility check for your installed plugins before it runs.

5. Plugin query overhead accumulating

Every plugin that hooks into WooCommerce adds queries. Each one might add 5 to 15 queries per page load. Ten plugins doing this adds 50 to 150 queries to every request. None of them seem significant in isolation.

Fix: Use Query Monitor's component breakdown to identify which plugins are generating the most queries. For plugins doing redundant work, either replace them with lighter alternatives or implement custom caching around their data calls.

The Checkout Problem Is Different

Everything above applies to cacheable pages. Checkout is different because it cannot be cached. Every checkout page load hits PHP and the database directly.

The performance factors specific to checkout:

Shipping rate calculation calls (often external API calls with latency)
Tax calculation queries
Payment gateway script loading
Cart session management

Under normal traffic this is manageable. Under heavy traffic or flash sales, checkout becomes the bottleneck because every concurrent user is hitting the server simultaneously with no cache layer to distribute the load.

For high-volume stores, dedicated server resources for checkout separate from the main site is worth evaluating. For most stores, minimising the number of external API calls during checkout and ensuring your server has adequate PHP workers for concurrent connections is sufficient.

The Database Optimisation Checklist

Before upgrading hosting, work through this list:

[ ] Install Query Monitor and audit query count per key page
[ ] Check variation counts on top 10 products
[ ] Enable Redis object caching
[ ] Clear expired transients and schedule regular cleanup
[ ] Enable HPOS if on WooCommerce 7.1+
[ ] Check wp_postmeta table size — over 500MB suggests indexing issues
[ ] Audit plugins with Query Monitor component view
[ ] Check autoloaded data size in wp_options

If you work through that list and performance is still poor, then the hosting conversation is worth having. But in most cases, at least two or three items on that list will produce measurable improvements before you get to the end.

When Faster Hosting Actually Helps

Hosting upgrades are not useless. They help when:

Your server is genuinely CPU-bound under normal traffic (check server CPU usage during peak periods)
You are on shared hosting where other tenants are affecting your performance
Your PHP worker count is too low for your concurrent user volume
You need more RAM to run Redis alongside the web server

The mistake is upgrading hosting as a first response rather than a last resort. A store with 300 inefficient database queries per page load will be slow on fast hosting. Fix the queries first, then evaluate whether the remaining performance gap justifies a hosting upgrade.