Capturing Price and Comparison Search Intent in E-commerce

Most e-commerce SEO chases category head terms and product names. Those matter, but they skip a layer of search that sits closer to the purchase than almost anything else: price and comparison queries. Someone searching cheap dog food, best cat litter under a budget, or one brand versus another is not browsing, they are deciding. On a pet e-commerce brand, these price and comparison searches were growing and converting, and yet the store had no page built to win a single one of them. That is the gap, and it is common.

Why Price and Comparison Intent Is So Valuable

Search intent runs on a spectrum from curious to ready to buy. Informational queries sit at one end, product names near the other, but price and comparison queries sit closest to the transaction of all. When someone adds cheap, best, under a price, or versus to a search, they have decided what they want and are working out where and which to buy. That is the moment a store most wants to be present, and it is exactly the moment most stores are absent, because they never built the page for it.

The reason these queries go unanswered is that they do not fit the standard store structure. A price query does not map to a single product or a broad category; it maps to a price-band or a curated selection. A comparison query does not map to a product page; it maps to honest, useful content that compares the options. Because these do not slot into the default template, most stores simply have nothing to rank, and the traffic, and the sale, goes to whoever built the page.

The Pages That Win Them

How to Find and Build Them

The opportunity is easy to find once you look for it, because it shows up as the modifiers your customers add to your category terms and the comparison and price queries your competitors rank for and you do not. The work is then to build the specific page each query type deserves, rather than hoping a category page happens to catch them.

This is bottom-of-funnel SEO, and it is undervalued precisely because it is less visible than chasing big category terms. But a shopper searching a price or comparison query is worth more than one searching a broad term, because they are closer to buying. The stores that quietly win these searches are capturing demand at the exact moment of decision, on pages their competitors never thought to build.

Why Your Organic Traffic Numbers Are Lying to You

Before you can decide whether your SEO is working, you have to trust the number that says how much organic traffic you have. On more sites than you would expect, that number is wrong before anyone opens the dashboard. Working on a pet e-commerce brand, I found paid clicks being counted as organic and campaign parameters quietly rewriting the traffic source, so the organic number everyone reported on was inflated and unreliable. This is an attribution problem, and it is different from arguing about which metrics matter. It is about whether the data is even real.

How Organic Gets Contaminated

Analytics decides where a visit came from using signals that are surprisingly easy to corrupt. A paid campaign whose links are not tagged correctly can land in the organic bucket. A URL parameter can overwrite the recorded source, so a visit that came from an ad or an email shows up as organic or direct. Internal links carrying campaign tags can re-attribute a session mid-visit. None of this is malicious; it is the accumulated result of many small tracking mistakes. The effect is an organic number that includes traffic organic search never earned.

This matters because every decision downstream rests on it. If your organic number is inflated by mistagged paid traffic, you will credit SEO for growth it did not produce, and when the paid budget changes, your organic will appear to crash for no reason. If it is polluted by parameter issues, you cannot trust any trend, any comparison, or any judgment about what is working. You end up optimising against a number that is partly fiction.

The Common Culprits

How to Clean It Up

Fixing attribution is unglamorous but transformative, because it restores trust in every number that follows. The goal is a strict, consistent tracking setup where every channel is tagged correctly and nothing is allowed to rewrite the source by accident.

None of this changes your actual traffic; it changes whether you can believe your report. And that is the whole point. The most sophisticated SEO analysis in the world is worthless if it sits on top of a contaminated organic number. Getting attribution right is the least glamorous, most foundational analytics work there is, and it is the difference between managing your SEO with data and managing it with a comforting fiction.

Local and GMB SEO for Service and Booking Businesses

Plenty of e-commerce brands also sell services, and services play by different SEO rules. A pet brand that sells food and supplies online might also offer vet consultations, vaccinations, and at-home visits, and the moment you add a bookable service with any local element, a whole separate discipline opens up. Local and service SEO is not a smaller version of e-commerce SEO. It is its own game, with its own top result: the local pack and the business profile, which often rank before your website appears at all.

Why Local Is Its Own Discipline

For a service or booking query, Google frequently shows a local pack, three business listings above a map, before any traditional organic results. That pack is powered less by your website and more by your Google Business Profile, your reviews, and your location signals. You can have a perfectly optimised website and still be invisible for local intent if the profile and the local signals are not there. That is the shift that catches product-focused teams off guard: the thing that ranks is not always the site.

So the work splits in two. There is the profile side, the Google Business Profile and the signals that feed the local pack, and there is the website side, the service pages that capture and convert the intent once someone clicks through. Winning local means doing both, and most businesses do neither well: they leave the profile half-filled and treat services as an afterthought page in the footer.

The Levers That Move Local

The Service Page Structure That Converts

Once the profile earns the visibility, the service page has to earn the booking. Local service intent is high-intent: someone searching for a vet consultation near them is close to booking. The page has to meet that intent without friction, answering the practical questions and making the next step obvious.

The businesses that win local are rarely the ones with the biggest websites. They are the ones that treat the profile as a ranking asset, collect reviews relentlessly, and give each service a real page built to convert. For a brand adding services to a product catalogue, this is often untapped ground, because the whole team is thinking in products while the service queries go to whoever bothered to claim the local pack.

How to Delete and Redirect Thousands of URLs Without Losing Your Traffic

Deleting pages is one of the highest-return moves in SEO, and one of the easiest to get catastrophically wrong. On a pet supplies store that had accumulated thousands of dead, duplicate, and outdated URLs, clearing them out was exactly the right call. Done carelessly it would have tanked traffic overnight. Done deliberately, it reclaimed crawl budget and lifted the pages that remained. The difference between those two outcomes is entirely in the process.

Why You Prune, and Why It Is Risky

Large stores accumulate URL debt: discontinued products, seasonal collections, campaign pages, filtered and parameter URLs, near-duplicates. Left in place, they waste crawl budget, dilute quality signals, and bury the pages that matter, the case I make in detail in the piece on index bloat. So pruning is right. The risk is that some of those URLs still earn traffic or hold links, and a blanket delete throws that value away, sending both users and Google to a wall of 404s and undoing months of work in an afternoon.

The goal is to remove the dead weight while preserving every scrap of value the old URLs earned. That means no URL is deleted without a decision, and the decision is one of three: keep it because it is still valuable, redirect it because its value belongs on another page, or retire it cleanly because it genuinely has nothing left to give. A pile of thousands of URLs becomes a pile of thousands of deliberate decisions, and that discipline is the whole game.

The Safe Pruning Process

Do Not Skip the Monitoring

The step that separates professionals from disasters is watching what happens after. A large prune is not finished when the redirects go live; it is finished weeks later when you have confirmed nothing important was lost.

Handled this way, a mass prune is one of the most satisfying wins in technical SEO: the index gets lean, crawl budget concentrates on the pages that matter, and the traffic not only survives the cleanup but often grows afterward, because the pages that remain are no longer competing with thousands of ghosts. The only thing standing between that outcome and a self-inflicted traffic loss is the process, and the process is entirely learnable.

SEO Governance: Who Gets to Create, Delete, and Redirect a URL

Not every SEO problem is technical or creative. Some are organisational, and they are among the most damaging because nobody owns them. On a growing pet e-commerce brand, the biggest drag on organic growth for months was not the algorithm or the content. It was that four different teams could each create, change, and delete URLs, with no process, so the website was quietly fighting itself. This is an SEO governance problem, and most companies do not know they have one.

How URL Chaos Happens

It is nobody’s fault, which is exactly why it spreads. The marketing team launches campaign and landing pages that happen to target the same terms as core category pages. Merchandising creates and deletes collections as the catalogue changes. Developers add parameters and templates that spawn URL variants. Each team is doing its job. But with no one owning the URL as an asset, the result is duplication, cannibalisation, orphaned pages, and a steady trickle of broken links and lost redirects that no single person can see.

The damage is cumulative and hard to trace. A marketing landing page starts outranking, then suppressing, the category page it was meant to support. A deleted collection becomes a 404 that was earning links. A campaign URL gets indexed and competes with the evergreen page. None of these is a disaster on its own; together they are a constant leak, and because no one owns the URL lifecycle, no one is watching the tank empty.

What SEO Must Own

Setting Up the Governance

Governance sounds heavy, but it is really just a lightweight process and a clear owner. The aim is not to make SEO a bottleneck; it is to make sure every change to the URL set passes one checkpoint that thinks about search before it ships.

This is the least glamorous work in SEO and often the highest leverage, because it stops the site from undoing its own progress. You can fix cannibalisation and pruning all day, but if the process that created them is still running, they come straight back. Governance is how you make the other fixes stick, and on a large, fast-moving store it is frequently the difference between growth that compounds and growth that leaks away as fast as you build it.

Client-Side Rendering Is Quietly Killing Your Product Pages

Some of the most damaging SEO problems are invisible, because the page looks perfect to you. You open a product page and see the image, the price, the description, the reviews. Everything is there. But everything you see was drawn by JavaScript after the page loaded, and the search crawler may have moved on before any of it appeared. On a pet supplies store I audited, hundreds of product pages looked flawless to shoppers and were nearly empty to Google.

Why Client-Side Rendering Breaks Indexability

Client-side rendering means the server sends a near-empty HTML shell and the browser builds the real page with JavaScript. Humans never notice; it happens in milliseconds. Search engines are different. They fetch the initial HTML first, and rendering the JavaScript is a separate, deferred, and not guaranteed step. If your product name, description, price, and specifications only exist after JavaScript runs, there is a real risk the crawler indexes a blank page, or indexes it slowly and incompletely.

The symptoms are consistent and easy to miss. Product pages that will not rank for their own product name. Content you can see on the page that does not appear when you view the page source. New products taking a long time to get indexed, or getting indexed as thin pages. For an online pet pharmacy, where every product page should rank for a specific medication or brand, this quietly caps the entire catalogue.

How to Diagnose It in Ten Minutes

How to Fix It

The fix is to make sure the content that must rank is present in the HTML the server sends, before any JavaScript runs. There are a few routes, and the right one depends on your stack, but the principle is the same: do not rely on the crawler to render your most important content.

This is engineering work, not a content tweak, which is exactly why it sits unaddressed on so many stores: it needs developer time and it is invisible until someone thinks to check the source. But on a catalogue-driven site it is often the single highest-impact fix available, because it unblocks every product page at once. All the content and links in the world cannot rank a page the crawler receives empty.

How to Win Google’s New SERP Features When Position One Is No Longer the Top of the Page

For years, the goal of e-commerce SEO was simple: rank number one. That goal quietly stopped being enough. Working on a pet e-commerce brand selling pet food and pet supplies, I watched a page that ranked first for a category term keep losing clicks, not because it dropped, but because Google stacked so many features above it that the first organic result now sat well below the fold. Winning search today means winning the features, not just the ranking.

The SERP Is Not a List Anymore

Search a term like dog food or cat litter today and you rarely see ten blue links. You see a Popular Products carousel, an image pack, a People Also Ask block, Shop by Brand and Shop by Price modules, and often a local pack, all before a single traditional organic result. Each of these is a place a competitor can appear and you cannot, and each one pushes your hard-won number-one ranking further down a page the user may never scroll.

This is the reality behind the phrase zero-click search. The click you thought you earned by ranking first is increasingly captured by a feature above you, or answered on the results page itself. For a store, the response is not to complain about it, but to compete for the features the same way you competed for the ranking, because that is where the visibility and the clicks have moved.

The Features Worth Fighting For

How to Actually Win Them

Winning SERP features is less about content volume and more about feeding Google clean, structured, complete data and giving it the page types the features draw from. It is unglamorous, technical work, and it is exactly the work most stores skip while they chase rankings that matter less every quarter.

None of this replaces ranking well; it compounds it. A page that ranks first and appears in the carousel and the image pack and the answer box owns the screen. A page that only ranks first, on a modern SERP, may own a spot the user never reaches. That is the shift, and the stores that adapt to it are quietly taking the clicks from the ones still optimising for a results page that no longer exists.

Core Web Vitals at the Template Level, Not With Another App

When a store or a large site is slow, the reflex is to install a speed app. It rarely works, because the problem is almost never something an app can reach. Core Web Vitals are decided by how the site is built: its templates, its code, its images, its scripts. On a transactional site, that speed moves two things at once, rankings and conversion rate, which is why it is worth fixing properly rather than patching. And fixing it properly means the template, not the plugin store.

The Three Metrics, Plainly

Core Web Vitals are three measurements of real user experience. Largest Contentful Paint is how quickly the main content appears. Interaction to Next Paint is how quickly the page responds when someone taps or clicks. Cumulative Layout Shift is how much the page jumps around as it loads. Google uses all three as signals, and users feel all three directly, a slow, janky page loses rankings and sales in the same motion.

On a marketplace with a progressive web app front end, none of these could be fixed with an add-on. They were addressed in the code and the templates: how images were sized and loaded, how much JavaScript shipped and when, how space was reserved so the layout did not lurch. That is the pattern everywhere. The levers that actually move Core Web Vitals live in the build, which is why an app bolted on top so rarely helps.

Why Apps Rarely Fix It

Fixing It at the Root

None of this is a quick toggle, and that is the point. Speed that lasts is built into the site, not sprinkled on top. On a transactional site the return is unusually direct, because the same work that lifts your Core Web Vitals also lifts the conversion rate the business runs on, which makes it some of the best-paid technical work there is.

Which Vital to Fix First

You rarely fix all three Core Web Vitals at once, so the order matters. Start with field data, the real-world measurements from actual visitors, rather than a single lab score, because the lab can flag problems users never feel and miss ones they do. Whichever metric is failing for the most real users, on the templates that carry the most traffic and revenue, is where the work begins. On most transactional sites that turns out to be Largest Contentful Paint, because heavy images and slow server responses on key templates hit the metric that gates the first impression.

From there, sequence by leverage. A fix in a shared template, a header, a product layout, a collection grid, corrects every page that uses it, so template-level fixes almost always outrank one-off page tweaks. Interaction to Next Paint usually comes next, since it is driven by the JavaScript and third-party scripts that accumulate over time and are worth auditing regardless. Cumulative Layout Shift is often the cheapest to fix, reserving space for images, ads, and fonts, and makes a good early win. The principle throughout is the same: measure what real users feel, fix it in the template, and start where the most traffic meets the worst score.

Internal Linking at Scale: Routing Authority to the Pages One Step From Page One

On a small site, internal linking is common sense: link related pages together. On a large site, it is one of the most powerful and most underused levers you have. Internal links decide how authority flows through your site, and on a site with tens of thousands of pages, a deliberate linking architecture can lift thousands of stranded pages at once, without a single new backlink or a word of new content. Most large sites leave this lever completely untouched.

Why Internal Linking Is Leverage at Scale

Every page has some authority, earned from external links and from the site’s overall strength. Internal links are how that authority moves around. Left to default navigation, it pools on the homepage and a handful of top pages while the deep pages, the ones that make up most of a large site, starve. A deliberate internal linking architecture redirects that flow on purpose, pushing authority down to the pages that are close to ranking and just need a push.

On a marketplace I worked on, the pages that mattered most were the tens of thousands sitting on page two, ranking for real terms but not quite breaking through. New content would not help them, and new backlinks at that scale were not realistic. Internal linking was the lever that could move them in bulk: routing authority from strong category and hub pages to the stranded pages one step from page one, thousands at a time.

How to Build a Linking Architecture

Deliberate, Not Decorative

The difference between internal linking as decoration and as architecture is intent. Decorative linking is whatever the theme and navigation happen to produce. Architectural linking is a plan: which pages should hold authority, which pages need it, and the deliberate paths that move it from one to the other. On a large site, that plan is worth as much as a content strategy, because it decides whether the pages you already have can climb.

How to Tell Whether Your Linking Is Working

Internal linking is easy to do busily and hard to do well, so it helps to know what success actually looks like. The clearest signal is movement on the pages you targeted: the page-two URLs you deliberately linked to should begin climbing, because the authority you routed to them is doing its job. Alongside that, watch crawl behaviour, important pages that were crawled rarely should be crawled more often once they are better linked, and check that click depth is falling, with key pages reachable in fewer steps from the homepage than before.

A quick audit tells you where to start. Crawl the site and look at internal link counts: the pages with the most internal links should be the pages you most want to rank, and if they are not, your linking is working against you. Find the orphans, pages with no internal links at all, because they cannot rank no matter how good they are. And look at where your strongest pages point, because an authoritative page linking only to your privacy policy is authority spent on nothing. Linking done well is deliberate, measurable, and correctable, not a set-and-forget navigation decision.

Structured Data at Scale: How Large Sites Get Thousands of Pages Understood

On a small site, structured data is a nice-to-have you add page by page. On a large site, it is infrastructure. When you have hundreds of thousands of near-identical pages, listings, products, profiles, the question is not whether to add schema, it is how to apply it consistently at scale so search engines classify every one of them correctly. Get it right and thousands of pages become eligible for rich results at once. Get it wrong and you have introduced errors at the same scale.

Why Schema Is Infrastructure, Not Decoration

Structured data is how you tell a search engine, in a language it does not have to interpret, exactly what a page is: this is a product, this is its price, this is its rating, this is a vehicle listing with this year and this mileage. Without it, Google guesses from the text and often guesses conservatively. With it, the page is unambiguous, and unambiguous pages are the ones that earn rich results and get classified correctly in the first place.

On a marketplace I worked on with millions of listings, the entire structured-data strategy came down to one principle: standardise it in the template so every page of a type carries the same clean, valid markup. One well-built listing template meant every one of hundreds of thousands of listings was correctly described, without anyone touching them individually. That is the leverage of doing structured data at scale: one decision, applied everywhere.

What Doing It at Scale Requires

The Payoff, and the Risk

Done well, structured data at scale makes thousands of pages eligible for rich results, breadcrumbs, review stars, prices, and helps search engines confidently classify content they might otherwise misread. Done badly, it multiplies errors across the whole site, and a template-level mistake means a template-level penalty on eligibility. This is exactly why it belongs in the technical foundation, built and validated carefully once, rather than bolted on page by page.

Where Schema Goes Wrong at Scale

The same leverage that makes template-level schema powerful makes its mistakes expensive. When the markup is generated by a template, an error is not on one page, it is on every page of that type at once. The failures I see most often are marking up data that is not visible on the page, which search engines treat as a violation; choosing a type that does not really fit the content, so the markup is valid but useless; nesting entities incorrectly, so the relationships between them are lost; and, most commonly, shipping the template and never checking it again, so errors that appear later go unnoticed across hundreds of thousands of pages.

The discipline that prevents all of this is simple to state and easy to skip: validate the template before it ships, keep the markup in sync with what the page actually shows, and watch the Search Console enhancement reports at the page-type level, not the individual page. When an error surfaces, it is fixed once, in the template, and the fix propagates everywhere. Structured data at scale rewards the teams that treat it as a living part of the build, and quietly punishes the ones that treat it as a task they completed once and forgot.