When you set out to work on SEO for an EC store, the first fork is usually "should I add more blog posts, or thicken category and product pages?" The standard advice is "publish three or four blog posts a week," and whether those posts actually move revenue rarely gets asked — only the quota of posts remains.
But break down the structure of stores that actually sell, and the win doesn't come from "blog or product page." It comes from a web that links product pages, category pages, and blog posts through internal links, and from how well each page's search intent meshes. Lately, AI-generated summaries in search (AI Overview) have thinned blog-driven traffic broadly, adding the worry of "can blog investment pay back?" That is exactly why you want to back type-by-type decisions with numbers, not feel. This piece first unties the either-or question, then lays out how to judge whether to boost blog or category SEO by "landing revenue" grouped by URL path.
Contents
TL;DR#
-
"Blog, or category and product?" is a slightly mis-framed question. Winning stores don't run on an either-or; they run on a web of the three types linked internally, where types divide roles rather than compete
-
On top of that, which type to weight effort toward is decided by your own revenue, not generalities. You swap the judgment axis from a "blog camp vs product-page camp" feel to landing revenue grouped by URL path
-
Landing revenue is the revenue of sessions that entered through a page. Purchases made after browsing on are credited back to the entry page (last-touch). Per-page CVR is not shown
-
Grouping into types is a step of sorting page-level landing revenue by URL-path patterns. A tool does not auto-classify the type
1. Blog Camp vs Category Camp — Generalities Won't Settle It#
Bottom line: before agonizing over "blog or product page," you need to untie the question itself. Stores that win don't win by betting on one side; they run on a web that ties the three types together with internal links.
Each type has a role. Blog posts catch upstream intent — the "research and compare" stage before someone is even looking for a product — and serve as the entry. Category and product pages are receivers close to purchase intent, the "this is what I want" moment. These two don't compete; they complement, with upstream posts building interest and internal links bridging to the purchase-intent pages. So framing it as "blog vs category, which is right?" misses the mark a little.
You're still forced to choose because time and money are finite. The danger here is drifting into "just mass-produce blog posts" the moment SEO comes up. The number of blog posts is not the same as SEO results. A post-count KPI diverges from a revenue KPI. So you swap the way you decide, from a gut-level "blog camp vs product-page camp" to your own actual revenue.
The chart above lines up landing-revenue share by type. Product pages, closest to purchase intent, carry the most, followed by category and blog. The ratios differ by store, of course. How to position SEO within the whole acquisition mix is covered separately in Comparing EC acquisition channels, and how to rebuild when AI Overview thins blog traffic in Surviving a blog-traffic collapse. The starting point is holding your own type-by-type share as a number, not a feel.
2. Page Type Is "Grouped by URL Path"#
Bottom line: landing revenue by type is not something a tool classifies on its own, deciding "this is a blog," "this is a product." What comes out is landing revenue at the page level; grouping it into types is work the reader does, using URL-path patterns as the cue. Being honest about this keeps later decisions from wobbling.
In most EC stores, the type shows up in the URL shape. Blogs are /blog/, categories /collections/ or /category/, products /products/, and so on. So grouping by type means writing out page-level landing revenue, sorting it into "these are blogs," "these are products" by the head of the URL path, and totaling per type. If your path conventions differ, you define the grouping yourself. It's the reader's classification from reading the URL, not an automatic type judgment.
The other thing to pin down is the "landing revenue" way of counting. Landing revenue is how much the sessions that entered through a page ultimately sold, credited back to the entry page. If someone entered from a blog post, followed an internal link, and bought on a product page, that revenue is counted to the blog post that was the entry. Because revenue from browsing on to another page is credited to the entry, the in-visit browsing is captured as a result. This crediting-to-the-entry way of counting is called last-touch (attribution to the entry contact, not the final contact). The key boundary here: landing revenue is per entry page, but per-page CVR (purchase rate) is not shown. Scoring pages that assume browsing — like articles — by a rate is a mismatched measure, a reason covered in detail in Read articles by landing revenue, not CVR.
3. Where to Weight Effort, by Landing Revenue per Type#
Bottom line: you decide where to weight effort by two things — the scale of landing revenue and the per-page efficiency. Look only at share size and you get pulled toward the type with the most pages; look only at efficiency and you over-bet on a few pages. Read both, and set the mix from each type's position.
Landing-revenue scale is how much revenue a type generates overall. Per-page efficiency is how much landing revenue one page of that type generates on average — scale divided by page count. Product pages tend to have large scale and decent efficiency; category pages have high per-page efficiency even with few pages; blogs have thin direct landing revenue per post. Each type's characteristics come into view.
The further to the upper right a type sits, the more it's the main field where both scale and efficiency are large. The blog in the lower left looks thin on direct landing revenue, but you must not cut it here. Blogs catch upstream intent and route readers to purchase-intent pages via internal links — a bridge. Drop the bridge and the landing revenue of the product and category pages downstream thins too. So the mix isn't "zero out blogs and go all-in on products"; it's weighting the large-scale, high-efficiency types while deciding how much blog to keep by whether its routing works. The angle of pruning wasteful pages by per-page revenue efficiency is in Review by per-page revenue efficiency, and which articles to fix first in Priority for which articles to rewrite.
4. Which Type Should Your Store Invest In#
Bottom line: allocating effort across types falls out of following three questions in order. Don't settle it in one binary; judge by URL-grouped landing revenue and how internal links mesh.
The first question is "do you even have URL-grouped landing revenue by type?" If not, start by grouping page-level landing revenue by URL. The next question is "is the landing-revenue share of the purchase-intent types (product, category) enough?" If it's thin, weight effort toward pages close to purchase intent. The last question is "do blogs actually route readers to purchase-intent pages via internal links?" If they don't, fixing the internal links from blog to product and category comes before adding more posts. If routing works, keep the current mix while thickening the type that's growing.
The heaviest part of this diagnosis is actually the first question. Regrouping page-level landing revenue by URL and totaling per type, repeated every period across all pages, is the labor. The work itself is simple; it gets heavier as pages pile up and every update forces a regroup. The call to retire pages that have done their job is laid out in Three conditions for deleting old content.
RevenueScope helps
Try to allocate effort across types and you keep hitting the same work: regroup page-level landing revenue by URL, total per type, and judge "which type to weight" by scale and efficiency. Repeating that regroup every period across all pages is the heavy part.
RevenueScope solves the heaviest part before that. It lists page-level landing revenue (last-touch, credited to the entry page) and displays it in order of largest scale first (shown with sample data from a fictional store). What comes back is the "page" and "landing revenue" columns; which type to group them into is decided by reading the URL path. RevenueScope does not auto-classify the type.
| Page (URL) | Type | Landing revenue |
|---|---|---|
| /products/serum-blanc | Product | 1.82M yen |
| /collections/skincare | Category | 1.21M yen |
| /products/moist-repair-cream | Product | 1.18M yen |
| /products/cleansing-balm | Product | 0.84M yen |
| /collections/new-arrivals | Category | 0.46M yen |
| /blog/skincare-order-guide | Blog | 0.41M yen |
| /blog/vitamin-c-serum-guide | Blog | 0.27M yen |
The "Page" and "Landing revenue" columns are an example of the RevenueScope output. The "Type" column on the right is what you sort yourself, by reading the head of the URL path (/products/, /collections/, /blog/). Total it back by type and product is roughly 60%, category about 20%, blog about 10%. Because landing revenue credits the entry page, a purchase entered from a blog and made on a product page is counted to the blog. So a thin blog number doesn't mean you should drop the routing bridge. Note that per-page CVR (purchase rate) is not shown here — scoring pages that assume browsing by a rate is a mismatched measure.
Open a row of interest and you get that one page's landing revenue and the trend of its search impressions, clicks, and position. Group the list to grasp "which type revenue is concentrating in," and open a row to check "how this entry is moving." You move between regrouping and checking on a single screen, so you set the type-by-type mix by your own revenue rather than generalities. What each plan covers is laid out in pricing.
FAQ#
Frequently asked questions#
Q. So, should I strengthen blog or category?
A. It can't be decided by generalities. Group your own page-level landing revenue into types by URL, and decide by scale and efficiency. In many stores, landing revenue concentrates in the purchase-intent product and category pages, but blogs build interest upstream and route via internal links, so thin direct revenue doesn't make them something to cut. Set the mix by both role and revenue, not an either-or.
Q. AI Overview is cutting my blog traffic. Should I stop blogging?
A. Don't judge by traffic alone; read landing revenue and the routing role. If people who entered via a blog follow internal links and buy on a product page, that revenue is counted to the entry blog's landing revenue. Traffic numbers alone can't see this bridging contribution. Check landing revenue by type and whether blogs route to purchase-intent pages, then adjust the volume.
Q. Does RevenueScope classify the type automatically?
A. No. What RevenueScope returns is landing revenue at the page level. Which type — blog, category, product — to group it into is sorted by a person, using URL-path patterns as the cue. Use it on the premise that it's a classification from reading the URL, not an automatic type judgment. Landing revenue is last-touch, credited to the entry page, and per-page CVR is not shown.
Summary#
"Blog, or category and product?" is a slightly mis-framed question. Stores that win run on a web of the three types tied together by internal links, where types divide roles rather than compete. First untie the either-or, then judge "which type to weight effort toward" by your own revenue, not generalities.
Swap the judgment axis from a "blog camp vs product-page camp" feel to landing revenue grouped by URL path. Landing revenue credits the entry page, and per-page CVR is not shown. Grouping into types is a step where a person sorts page-level landing revenue by URL path — a tool does not auto-classify it. The hard part isn't the idea but repeating the regroup every period. Start by lining up your own page-level landing revenue on one screen, grouping it into types by URL, and setting the mix by scale and efficiency. The effort you were splitting by gut now rests on the ground of your own revenue.
See which ads actually drive revenue, at a glance
Free up to 5,000 sessions/month, AI analyst included. No credit card required. Up and running in 5 minutes.
