Why review pages should sometimes have their own URLs.

A skincare brand sells a single serum that has sold sixty thousand units since 2022 and accumulated 4,118 published reviews. The reviews sit, all of them, inside a paginated widget that begins six scrolls below the buy button. The widget shows ten reviews per page. To read review number 1,400, a buyer clicks "next" 139 times. The HTML for review number 1,400 is not in the page until she does.

The widget is a single URL. The 4,118 reviews share that URL. The brand has, in citation terms, one product page; in reading terms, it has a 4,118-paragraph book without a table of contents.

This essay is about the case for giving that book its own address.

Most products on most stores do not need a separate review page. A SKU with eight reviews does not have a citation problem; it has a volume problem. Adding a second URL adds a thin page to the index, which is the opposite of what we want.

The architectural threshold, from observation across stores we have audited in 2025 and 2026, falls somewhere between 150 and 300 published reviews per SKU. Below that, the reviews fit on the product page without paginating past the second screen. The product page is the right home. Above it, the product page begins to load reviews in chunks; pagination starts; the long tail of citable language disappears below the fold and behind JavaScript.

Bazaarvoice's enterprise documentation, which addresses retailers with tens of thousands of SKUs and millions of reviews, has used "container pages" since at least 2019 to host overflow reviews for high-volume SKUs. The Bazaarvoice framing is moderation: containing reviews that would otherwise overwhelm the product page. The architectural framing is different. A container page is a separate URL. A separate URL is its own citation target.

We are arguing the threshold and the framing both. The threshold is volume. The framing is not overflow; it is corpus.

A product page is one URL ranking for a finite set of phrases. The phrases tend to cluster around the product name, the brand name, and a few category descriptors. The page can be optimised against that cluster. It cannot be optimised against the 1,400 distinct buyer questions sitting inside its review block.

A separate reviews URL is a different document. It contains a different set of strings. The strings include phrases like "did the serum sting" and "how long until visible results" and "broke me out at first" and "stopped working in week six." Those phrases are queries. The same buyer who typed them into the review form is the buyer typing them into Google and ChatGPT.

In the long tail begins inside the review, we walked through how the long-tail keyword research a store needs has already been done by its own customers, for free. The corollary is architectural. If those phrases live inside a paginated JavaScript widget on the product page, they are partially indexable at best. If they live on their own URL, with the reviews server-rendered in HTML, the keywords have a home.

The Princeton and IIT Delhi paper on Generative Engine Optimization (December 2024) found that AI engines preferentially cite passages from pages whose topical focus matches the query. A product page is topically focused on the product. A reviews page is topically focused on the experience of using the product. For a query like "does this serum work for combination skin," the reviews page is a tighter topical match. The engine is more likely to cite it.

Google's Core Web Vitals became a ranking signal in 2021. The three metrics are Largest Contentful Paint, Interaction to Next Paint (replacing First Input Delay in 2024), and Cumulative Layout Shift. Review widgets, in our field measurements through 2025 and 2026, contribute disproportionately to LCP and CLS on Shopify product pages. A high-volume product page can spend 1.5 to 3 seconds loading review content the buyer never scrolls to.

Splitting the reviews onto a separate URL removes the load cost from the product page. The product page becomes lighter. LCP drops. CLS drops. The buyer who never wanted to read reviews never pays the load tax for them. The buyer who did want to read reviews clicks through to a page that is, by design, just reviews; the load profile is appropriate to the content.

Baymard Institute's product-page research (published continuously since 2014, with the most recent benchmark update in 2025) has measured buyer behaviour on review-heavy product pages. Buyers who engage with reviews spend disproportionate time on them: in some Baymard sessions, more than half the time on the page. But the same studies show buyers who do not engage with reviews are slowed by them, particularly on mobile. Splitting the URL separates the audiences.

The most common objection to a separate reviews URL is that it dilutes the SEO equity of the product page. Two URLs, the argument goes, split the link graph. The buyer who would have linked to /products/serum now links to either /products/serum or /products/serum/reviews. Neither URL accumulates as much equity as a single combined page would.

The objection has a technical answer. The product page should remain the canonical destination for queries about the product. The reviews page should set its canonical tag to itself, but should rel="prev"/"next" with the product URL (using the original prev/next semantics, deprecated by Google in 2019 as a ranking signal but still parsed for site structure) and should be cross-linked prominently from the product page.

The architecture is hierarchical, not flat. The product page is the parent. The reviews page is a child document. The link graph treats them as related but distinct. The canonical for product-name queries lives at the parent. The canonical for experience-with-product queries lives at the child. Each URL ranks for what it is topically about.

This pattern is not new. Amazon does it. Amazon's product page sits at /dp/[ASIN], and the reviews live at /product-reviews/[ASIN] with their own URL, their own canonical, and their own indexing profile. Amazon ranks for product queries on the first URL and for experience queries on the second. The split has been in place since at least 2007. The decade of search-rank evidence is that the split helps, not hurts.

For AI engines, the question of duplicate content is different. The engines do not appear to penalise topically overlapping pages on the same domain the way Google's link graph does. They appear to choose the more specific page for the more specific query. A reviews page that contains the literal text of the reviews is more specific, for an experience query, than a product page that contains the same text in a JavaScript-loaded widget.

Three patterns to choose from, in order of our preference.

Pattern one. The reviews live at /products/[handle]/reviews. The URL is a subdirectory of the product page. The breadcrumb is Product > Reviews. The reviews page renders the full corpus in pages of fifty, with anchor-able URLs for each page (/products/[handle]/reviews?page=4). Each review has a permanent anchor that resolves to a specific position in the page. This is the cleanest pattern and the one we recommend by default.

Pattern two. The reviews live at /reviews/[product-handle]. The URL is a sibling of the product directory. This pattern works for stores that want all reviews discoverable through a central /reviews index, with cross-product browsing. It is structurally fine. It is less semantically obvious to crawlers about the parent-child relationship.

Pattern three. The reviews live at /products/[handle]#reviews. The reviews are on the same URL with a fragment identifier. This is the pattern most stores ship by default. It does not split the URL. It does not solve any of the problems we have raised. It exists in this list to be named and rejected.

For pattern one, three additional structural choices follow. First, pagination should be in the URL (?page=N), not in JavaScript, so each page is indexable. Second, the schema markup should split: the product page carries Product and aggregateRating; the reviews page carries an ItemList of Review objects with full review text. Third, the product page's review block should remain, with the first ten or so reviews rendered, and a clear "Read all 4,118 reviews" link to the reviews page. The product page does not become review-less. It becomes a teaser, with the long form one click away.

The separate URL is wrong when the volume is low. A product with twelve reviews on a dedicated reviews URL is a thin page. Google's Helpful Content classifier (folded into core ranking in March 2024) actively suppresses thin pages. The reviews page would not rank, the product page would lose the small amount of review content it had, and the buyer would arrive at a sparse second page with little to read.

The separate URL is wrong when the reviews are highly repetitive. A consumable with ten thousand reviews that mostly say "great product, will buy again" does not benefit from a dedicated page; the page would be ten thousand variants of a single sentence. The corpus has to have linguistic variance to be worth its own URL. A test for this: count the distinct nouns and verbs across the corpus. If the count is low, the corpus is one sentence repeated. If the count is high, the corpus is a book.

The separate URL is wrong when the brand cannot maintain the schema and crosslink hygiene. A reviews URL that lives outside the product URL but does not cross-link, does not set canonical relationships, and does not appear in the sitemap will end up orphaned. An orphaned URL is worse than no URL.

The separate URL is also wrong for SKU clusters that share reviews. A serum sold in 30ml and 50ml sizes may share its review corpus across both variants. Two reviews URLs (one per variant) would duplicate the same content twice. The pattern in that case is one reviews URL serving both product URLs, with canonical tags pointing the variant URLs at the parent.

The product page is not the right shape for two hundred paragraphs. It is the right shape for the buy decision. The reviews are the right shape for the second decision the buyer makes, the one about whether to keep believing what the buy page told them. Two shapes, two URLs.

We have run an informal corpus check, in late 2025, against three stores that split their reviews onto dedicated URLs and three matched stores that did not. The split-URL stores had, in ChatGPT and Perplexity citations sampled across forty product-related prompts, a measurably higher rate of citation of their own pages versus third-party review aggregators. The sample is small. The direction is consistent with the structural argument: when the reviews live at a dedicated URL with the text in the HTML, the engine has a clean target to cite. When the reviews live inside a paginated widget on a product page, the engine cites the third party that mirrored the content (Trustpilot, Reddit, a YouTube review) because the third party's URL is the clean target.

In the end of the review widget, we argued that the widget shape is finally the wrong shape for what it holds. The architecture argument here is a corollary. The widget is the wrong shape because it asks the URL to do two jobs. The URL is about the product. The widget tries to also be about the experience of the product. Two jobs need two URLs.

In the half life of a product page, we wrote about the product page that compounds in the language of its own customers versus the product page that decays. The reviews URL is the architectural form of the compounding. The product page does not need to grow longer over time; the reviews page grows on its behalf. The link graph, the citation graph, and the buyer's reading experience all benefit from the split.

Three steps, in order, for a store considering the split.

Step one. Identify the SKUs above the threshold. Pull a count of published reviews per SKU. The split is justified, on a volume basis, for SKUs above roughly two hundred reviews. For most stores that means five to fifty SKUs out of the catalog. The rest stay on their product pages.

Step two. Stand up the URL structure. /products/[handle]/reviews is the default. The page should server-render the reviews in HTML, paginate with query strings rather than JavaScript, and carry its own Review-list schema. The product page keeps a teaser block of reviews and a prominent link to the full reviews page. Both URLs go in the sitemap.

Step three. Wait for the indexing. Google takes two to six weeks to fully index a new URL pattern of this kind. The AI engines update on different cadences (ChatGPT's crawl freshness lags Google's by weeks to months depending on the model version). The citation lift, where it appears, is not immediate. It is also durable: a reviews URL that has accumulated review text since 2024 is the kind of page citation engines treat as a long-standing reference.

After those three steps, the audit is at the level of reviews are language not inventory. Does the reviews page read like a document a person would want to read, or does it read like a stockroom? The first means linguistic variance, real names, dates, replies. The second means a wall of repetitive five-stars. The split URL is the architecture. The content has to earn the architecture.

The product page was built, originally, as a single document with a single job. The buy decision happens here. Everything else is supporting evidence below the fold. That model was correct for a product with a dozen reviews. It is not correct for a product with four thousand.

The reviews have become a document of their own. The document deserves an address. The address gives the document its own canonical, its own load profile, its own topical focus, and its own citation target. The brand that ships the address keeps the link equity, the search ranking, and the AI citation share on its own domain. The brand that does not ship the address keeps the reviews inside a widget, and the widget inside a single URL, and the single URL on a slower page, and the slower page in a lower position.

The work of running a store has, quietly, become the work of running two pages per high-volume product instead of one. The buy page and the reading page. Two shapes, two URLs, one domain.