You have eight thousand product pages and about six hours a week. That gap is why the refresh list never moves.
Here is the good news. You do not need to fix the catalog. You need a way to answer one question every Monday: which pages to refresh first. This guide gives you that, using money as the sort order instead of page age or traffic.
Most advice on how to prioritize content refresh ecommerce teams inherit was written for a sixty-post blog. It does not survive contact with ten thousand SKUs, seasonal stock, and a checkout that owns half the outcome.
The method is a revenue weighted refresh. You rank each page by the revenue you can plausibly recover per hour of work, then you work down the list. It takes a day to set up and about an hour to rerun. Let's build it together.
Step 1: Decide what revenue means before you rank anything
Every argument about priority is really an argument about definitions. Settle them first and the rest gets easy.
Write down the answers to these:
- The currency and the exact revenue field you are ranking on.
- Whether you rank on item revenue, net revenue, or gross profit.
- How you treat refunds, cancellations, discounts, tax, shipping, and returns.
- Which page types are eligible: product, category, collection, campaign, guide.
- Whether the goal is recovery, profit, conversion, organic demand, or a mix.
- How many refresh hours you actually have per week.
Then pick one observation window and one matching comparison window. A trailing 90 days against the prior 90 days works for most stores. If your demand swings hard by season, compare the same season year over year instead.
One caution on the field itself. In GA4, item revenue is price multiplied by quantity, and it excludes tax and shipping. That makes it great for comparing product pages against each other. It is not the same number your finance team calls net revenue. Pick one and stay on it.
Done when: another person on your team could rebuild your exact list from the brief alone, with the same date range, the same filters, and the same revenue field.
Where people go wrong: mixing windows. Ranking pages on all-time sales while judging the opportunity on last month's traffic makes ancient bestsellers look permanently important and hides what is happening right now.
Step 2: Build one row per canonical page
Now you need an inventory. One row per canonical page, with the identifiers that let you join everything else to it later.
Each row should carry:
- The canonical URL, plus every URL variant you have seen for it.
- Page type: product, variant, category, collection, campaign, guide, filter, or search.
- Product ID, item ID, SKU, GTIN, and variant ID where you have them.
- The category and parent category path.
- Price, currency, stock, availability, discount, and shipping state.
- Publication date, last content change, and template.
- Indexability, canonical target, sitemap membership, and HTTP status.
- The page owner and your rough estimate of refresh hours.
- Whether this is a direct revenue page, an entry page, an assist page, or a growth candidate.
Two join keys, not one. Use the canonical URL to join Search Console data. Use the product or variant ID to join item-level revenue. Keep the mapping many to many, because one product genuinely does live in several categories, and flattening that loses information you will want in step five.
Pro tip: keep two tables, not one. A page identity table holds the URL, IDs, and mappings. A page performance table holds the numbers per period. When you discover a canonical was wrong, you fix identity without rewriting six months of history.
This is the step where a content map earns its keep. DeepSmith's Content Map crawls your site and your competitors' sites, classifies every page onto a granular topic and a funnel stage, and rechecks sitemaps every 24 hours so new pages fold in on their own. That gives you the page and structure half of the inventory without a manual crawl. It is not a revenue ledger, so you still join it to your commerce and analytics exports to get the money side.
Done when: every candidate has one canonical record, a stable product mapping, a page type, a business state, and a named owner. Duplicates and pages with no clear commercial job are visibly flagged, not quietly dropped.
Where people go wrong: joining on product names. Names change, repeat across variants, and differ by locale. Use stable IDs, and keep the old-to-new URL map when you migrate.
Step 3: Join your commerce, funnel, and search data
No single tool answers this question. You are building one page-level table per period by pulling three streams together.
Product and order revenue
From GA4 or your commerce platform, aggregate by item or variant: item revenue, units, purchase count, refunds and returns, product views, add-to-cart events, checkout starts, purchases, price and quantity, currency, and how clean your transaction IDs are.
A note if you are on GA4: ecommerce events are generally not collected for you. Your site or integration has to send them. Some Shopify setups send a subset automatically, but verify what is actually firing before you trust a ranking built on it. The items array holds up to 200 elements and each item can carry up to 27 custom parameters, so a large catalog needs a disciplined item ID convention rather than a pile of product names.
Entry page revenue
Category, campaign, and guide pages need a different measure. Pull landing page sessions, landing page revenue, product clicks, list views, and the funnel events that follow. Label this session-scoped entry page revenue and keep it in its own column.
Do not add it to item revenue in the same total. The same purchase would be counted twice, once as category revenue and once as product revenue, and your top ten would be nonsense. Worth knowing too: the GA4 landing page report is session based and its total revenue metric can include revenue types beyond ecommerce purchases, so confirm your property's mix before you lean on it.
Organic search exposure
Pull Search Console clicks, impressions, CTR, and average position by canonical page. Search Console attributes performance to the Google-selected canonical URL, so consolidate your URL variants before you join, or the numbers will land on the wrong row.
Keep two things in your head here. CTR is clicks divided by impressions, nothing more. Average position is an aggregated measure across queries, locations, and devices, not a fixed rank for the page. Use both to locate demand and diagnose leaks. Never use them to invent a revenue number.
At real catalog scale the API becomes the constraint. Search Analytics documents a maximum of 50,000 rows per day and search type, so you will need pagination or a bulk export into a warehouse. If you are joining GA4 raw events to your catalog anyway, BigQuery is the more durable home for all of it.
Done when: every row has a revenue measure or an explicit "no revenue observed" flag, funnel signals, search signals where they exist, page state flags, and a documented path back to the source.
Where people go wrong: treating a product view or an organic click as proof the page made money. Views and clicks are opportunity signals. Revenue and profit are commercial signals. They are not interchangeable.
Step 4: Clear the blockers before you score any copy
This step saves more hours than any other, and it is the one most teams skip.
Before a page gets a content score, ask whether the problem is even the words. Run each candidate through eight checks:
- Availability. Is the item in stock, orderable, and sold in the market you are analyzing?
- Commercial accuracy. Do price, currency, availability, shipping, returns, images, and variant selection match what the shopper actually sees?
- Measurement. Are currency, item IDs, quantities, transaction IDs, purchase events, and refunds present and consistent?
- Crawlability. Can a crawler reach the page through normal links or a valid sitemap?
- Canonicalization. Does the page declare the canonical you intend, and do internal links agree with it?
- Pagination and facets. Do listing pages have unique crawlable URLs, without filter combinations spawning thousands of near-duplicates?
- Structured data and feed. Do your product data and feed describe the page a shopper lands on?
- Template and performance. Will your planned change add heavy images, extra scripts, or layout shift?
On canonicalization, the signals are not equal. Redirects are strongest, then a rel="canonical" declaration, then sitemap inclusion, which is only a hint. Do not use noindex to pick a canonical, and do not use robots rules for it either.
A page with a broken canonical, an unavailable product, a wrong price, or a missing purchase event is not a copywriting opportunity. Send it to the owner who can fix it, and keep a separate blocker queue so technical work never gets reported as an editorial result.
Done when: each candidate carries one label: refresh now, fix blocker first, monitor, seasonal hold, retire or consolidate, or growth test.
Where people go wrong: rewriting descriptions on pages nobody can buy from. The new copy might be genuinely better. The commercial problem is untouched.
Step 5: Diagnose the leak by comparing like with like
"Refresh" is not one thing. What you change depends on where the page is losing, and you can only see that by comparing a page to its peers.
This is the step that turns a spreadsheet into a real catalog refresh priority list, because it names the fix, not just the rank.
Cohort first: page type, category, price band, brand, availability, season, template, query intent. A product page judged against a buying guide tells you nothing. An out-of-stock SKU judged against an active bestseller tells you less.
Then read the pattern:
| What you see | Likely cause | What to change |
|---|---|---|
| High revenue, high product views, weak add-to-cart against peers | The page is not answering fit, value, use case, or trust questions | Refresh product detail, benefits, proof, imagery, variant guidance, and objections |
| Strong views and carts, weak purchase completion | Checkout, shipping, returns, payment, stock, or price, not copy | Route to checkout or merchandising; touch copy only if the page sets a false expectation |
| High impressions, low CTR, relevant queries | The search result is not communicating the value | Test title, description, and the visible page promise against query intent |
| Strong organic clicks, weak product views | The landing experience is not carrying the promise into the catalog | Improve category structure, product links, filters, and above-the-fold clarity |
| High entry page revenue, weak product selection | Valuable sessions arrive, then struggle to find products | Improve internal paths, product modules, category labels, selection guidance |
| High revenue, healthy funnel, no defect | There may be no proven opportunity | Monitor and protect it; refresh only for a real risk or product change |
| Little revenue, real impressions | Not a recovery candidate | Growth queue, with a hypothesis attached before you spend hours |
| Revenue falling alongside stock, price, feed, or tracking issues | A blocker wearing a content costume | Fix it, then recalculate |
One rule keeps this honest: require two independent signals before you call something a copy problem. High product views plus a below-cohort add-to-cart rate is evidence. One low metric on its own is a hunch.
Done when: each candidate has a cohort, a named problem, the evidence for it, a proposed change, and the person who owns the fix if it is not editorial.
Where people go wrong: prioritizing pages because they are old, sit below position one, or have thin descriptions. Age, word count, and average position are not opportunity measures.
Step 6: Score expected return per hour
Now the ranking. This is the part that makes it a revenue weighted refresh rather than a to-do list. Effort belongs in the denominator, because a large opportunity that costs forty hours can lose to a small one that costs two.
If you have credible evidence of what a change tends to do on your store, use the direct model:
Expected incremental revenue per hour
= baseline attributable revenue x expected relative lift x confidence / estimated hours
If you have reliable margin data, swap revenue for gross profit and multiply by gross margin. Ranking on profit is usually the better decision, because a high revenue, low margin product can be a poor use of an afternoon.
Your estimated hours must include everything: analysis, copy, design, development, merchandising, QA, approvals, and publishing. Counting writing time alone is how a "quick fix" becomes a fortnight.
Do not have a lift estimate? That is completely normal, and inventing one is worse than admitting it. Use a transparent proxy score instead, applied inside comparable cohorts:
| Component | Scale | What the top of the scale means |
|---|---|---|
| Revenue exposure R | 0 to 5 | 0 is no observed revenue, 5 is a top-band or strategically protected revenue page |
| Opportunity evidence O | 0 to 5 | 0 is no diagnosed problem, 5 is a prior comparable test supporting the fix |
| Urgency U | 1 to 3 | 1 is no time pressure, 3 is a live blocker or a closing seasonal window |
| Confidence C | 0.5 to 1.0 | 0.5 is weak attribution, 1.0 is strong attribution and repeatable evidence |
Then:
Priority index = (R x O x U x C) / estimated hours
These weights are a starting framework, not an industry standard. Calibrate them against your own tests. And hold one line: a page scoring R = 0 does not win the revenue queue on opportunity alone. It goes to growth.
When two pages tie, break it in this order: a fixable commercial or technical blocker, then stronger evidence and cleaner attribution, then higher margin or strategic value, then a shorter and more repeatable fix, then lower risk of damaging a page that is already winning.
Done when: every page has a score or a stated reason it is not scoreable, an hour estimate, a queue, and a next action. You can explain the top of your list in one sentence per page. That explanation is your ecommerce refresh ROI story, and it is the thing that survives a meeting.
Where people go wrong: false precision. "This will add 12%" with no test, no peer comparison, and no history behind it is a guess wearing a decimal point.
Step 7: Sequence the work in revenue return waves
A ranked list is not yet a plan. Group it into waves that match what your team can actually ship.
Wave 0: unblock the high-value pages. Fix tracking, canonicals, indexability, feed, availability, pricing, checkout, and template problems on your biggest earners. Recalculate after. A technical repair is not a copywriting result, so do not report it as one.
Wave 1: refresh high-revenue pages with a proven leak. Strong revenue exposure, clear evidence, low to moderate hours. Batch by template or category so implementation and QA costs stay visible.
Wave 2: repair high-exposure discovery pages. Pages with real impressions or entry-page value that are failing to carry demand into the catalog.
Wave 3: protect seasonal and campaign windows. Move a page forward when the window is real and stock, feed, and shipping can be ready in time. If you cannot compare against an equivalent period, call the result directional, not causal.
Wave 4: run growth tests. Low-revenue pages with genuine demand or strategic weight, treated as controlled tests with a hypothesis and a success measure.
Then write the brief. "Improve SEO" is not a task anyone can execute. Name the change: product facts, benefits, use cases, fit and sizing, comparison, FAQs, imagery, titles and descriptions, category labels, internal links, structured data, feed fields, or template behavior.
This is where production becomes the bottleneck for most teams, because a wave of briefs still has to become finished pages. DeepSmith's Content Studio takes a briefed idea from New Ideas through Planned Content into Produced Content, and the Writer returns a researched, brand-grounded article with internal and external links, metadata, and a cover image already in place. Autowrite runs the same thing on a schedule when you plan a batch in advance. That covers the editorial assets around a catalog refresh: buying guides, category copy, comparison pages. Keep the revenue, orders, and margin analysis in your own analytics and warehouse, where it belongs.
Done when: you have a dated, capacity-aware queue, each page has an owner and a change list, and blocker work is reported separately from editorial work.
Where people go wrong: shipping the easiest pages first and calling it ecommerce refresh ROI. Ease belongs in the denominator. It does not get to erase revenue exposure and evidence.
Step 8: QA the change, then re-score the catalog
Before you touch a page, save its baseline: URL, canonical, product and variant IDs, revenue and funnel metrics, search metrics, feed fields, and the change you plan to make. Without that snapshot you cannot tell later whether the refresh worked.
After release, check three layers.
Content and merchandising. Product claims, specs, dimensions, compatibility, warranty, and returns are accurate. Price, currency, discount, availability, shipping, and the selected variant agree across the visible page, the structured data, and the feed. Titles, descriptions, headings, and the visible promise match shopper intent. Important information is real text, not trapped in an image or an interaction. Internal links point at the canonical pages you intend.
Technical. The page returns the expected status and is reachable through crawlable links. Canonical, sitemap, redirects, and internal links do not contradict each other. Paginated listings have unique URLs and crawlable next-page links; a crawler follows links in href attributes and will not reliably reproduce a navigation state by clicking buttons, and URL fragments do not count as pagination. Facets are not creating a new indexable URL for every combination. Product structured data describes the visible variant. Your view_item, add_to_cart, purchase, and refund events still fire with correct IDs, currency, value, and quantity. Loading, interactivity, and visual stability did not regress.
Measurement. Compare the page against its own pre-change window, and against a peer cohort where you have one. Watch the commercial measure you scored on, plus the funnel and organic metrics that motivated the change. Then recalculate. If price, stock, promotions, traffic mix, or checkout changed at the same time, say the result is directional. Claiming causation you cannot support is how a prioritization system loses the trust it needs.
A refresh is done when the page passes QA, the data joins survived, the result is written down, and the next decision is explicit: keep, iterate, roll back, or move on.
What to do next
Do not start with eight thousand rows. Start with one category, your biggest by revenue. Build the inventory for it, score it, and ship wave 1. You will learn more in that one pass than in a month of planning.
Then set a cadence. Rerun the score on a fixed schedule that matches your traffic and capacity, and rerun it sooner after any big price, inventory, template, tracking, or seasonal change. That is how catalog refresh priority stops being a debate and becomes a queue.
The analysis stays in your systems. If the production side is what keeps stalling, DeepSmith can take the briefed opportunities and turn them into finished, on-brand pages while you keep working the list. You can start a free trial and see it on your own catalog before you commit to anything.
One category. One wave. That is the whole first step.
