The most common misconception we encounter on intake: “we need more blog posts.” In almost every case, the blog is not what’s holding back organic revenue. The category architecture is.
A well-built category page targets high-volume, high-intent keywords at the category level. “Women’s leather bags,” “waterproof hiking boots under $200,” “B2B office furniture bulk.” These are the queries that convert. They’re also the queries where ecommerce stores consistently underperform.
A blog post about “how to choose leather bags” might rank for informational queries. A category page for “women’s leather bags” ranks for commercial queries and directly hosts the products. The revenue impact is not comparable.
Filter URLs — size=large&color=black — are almost always generating thousands of duplicate pages. We implement canonical tags and crawl directives that consolidate authority to the base category URL without breaking the filters.
Category pages with only a grid of products and a page title are thin pages in Google’s eyes. We add above-the-fold category introductions (150-250 words), structured buying guides, and FAQ blocks — all of which feed schema and add topical depth without hurting UX.
Product pages almost never link back to their categories with anchor text. Fixing this distributes PageRank correctly and helps Google understand category hierarchy.
BreadcrumbList schema on every page, correctly nested. This gets breadcrumbs in SERPs and helps search engines map your site structure.
PLPs are usually the worst-performing page type in a store. Lazy image loading, virtual scrolling, and deferred JS on filters typically move LCP by 1-2 seconds.
We track category-level ranking share of voice monthly. Most clients see measurable movement in the first 60-90 days on priority categories.
Every week a store owner sends us a screenshot of their PageSpeed Insights score after installing a “speed optimization” plugin. The score is 92. The LCP is 4.1 seconds. These two things are not contradictory, and the plugin is responsible for both.
The Lighthouse score is a weighted composite of several metrics. “Opportunities” like unused JavaScript and render-blocking resources score points when you eliminate them. But you can score well on those and still have a slow LCP if your largest contentful element — typically a hero image or product image — loads slowly.
Speed plugins are good at the low-hanging fruit: minification, combining scripts, lazy loading. They’re not good at the things that actually move Core Web Vitals, which require real engineering decisions.
Add a <link rel=”preload”> for the above-the-fold hero image in the <head>. This is the single highest-impact change on most stores and takes 15 minutes to implement correctly. The image stops waiting in queue and loads as a priority resource.
Serving a 2000px JPEG for a 400px display slot, scaled down by the browser, is still common. WebP with correct srcset attributes and proper dimension constraints. Every product image, every hero image. Not a plugin job — a theme-level decision about how images are output.
TTFB (time to first byte) above 600ms makes LCP almost impossible to get under 2.5s. Common causes on WooCommerce: uncached database queries (no object cache), PHP running on shared resources, or WooCommerce doing unnecessary work on every page load. Redis object cache + server-level page caching on non-cart pages moves this significantly.
Interaction to Next Paint is where speed plugins are least useful. High INP is almost always caused by long JavaScript tasks blocking the main thread. On ecommerce sites: chat widgets, analytics libraries, and marketing tags loaded synchronously. Deferred loading of third-party scripts, and code-splitting on custom JS, are the fixes. No plugin does this properly.
LCP under 2.5s on mobile, INP under 200ms, CLS under 0.1. These are Google’s “Good” thresholds and the point at which Core Web Vitals stop being a ranking drag. Most stores are in the “Needs Improvement” band on LCP — meaning they’re losing rankings to competitors who have done this work.