If your team is still merging features in late October and someone has just asked when the code freeze starts, the answer for Black Friday 2026 is: new features stop on Monday, November 2, and the last planned deployment goes out on Friday, November 13. Black Friday falls on November 27 and Cyber Monday on November 30. Count back the time you need to load test, fix what breaks, and test again, and the window for risky changes closes in early November.

The outage you’re trying to prevent rarely comes from a big release. One of our support clients launched a large campaign on a Friday, traffic climbed, and the whole site went down. Restarts didn’t help. The cause was a product label rule meant to cover the whole catalog except five products, set up by selecting every brand, and it made the platform fetch items in a loop. Nobody had deployed code that day.

That’s why this guide treats Black Friday readiness as three engineering jobs: a code freeze that also covers configuration, a load test with a target you can defend, and an incident plan with named people on call. Marketing, merchandising, and promo planning are covered in our Black Friday and Cyber Monday checklist.

What is a code freeze, and what should it cover?

A code freeze is a period when a team stops deploying changes to production, so the live system stays in a known, tested state. For an online store before Black Friday, a code freeze should cover more than application code: configuration, extension and app updates, infrastructure changes, tracking scripts, and price or promotion rules can all take a store down, and none of them needs a developer to deploy.

Software teams use the term in two ways. Before a release, a code freeze means no new features, only bug fixes. Before a peak, it means no changes to production at all unless an agreed process approves them. Some teams call the second one a change freeze, which is the more accurate name for eCommerce, because outages like the one above start with changes that never go through a code review.

The freeze also protects your test results. A load test only describes the store you tested. Every change after it, even a small one, makes the result less true.

What the freeze allows, and what it blocks

A freeze that blocks everything gets ignored by the third day. Agree in writing which changes are allowed, who approves them, and how they’re tested.

Tag manager containers belong on the blocked list. A new marketing pixel is code running in every shopper’s browser, and a slow third-party script can hold up the checkout as effectively as a bad deploy.

When should the code freeze start for Black Friday 2026?

For Black Friday 2026, start the feature freeze on Monday, November 2, and allow no major deployments after Friday, November 13, two weeks before Black Friday. That leaves two weeks for load testing and fixes before the strict freeze, and two weeks of stable production before the peak. Keep the freeze in place through Cyber Monday, November 30, and lift it no earlier than Tuesday, December 1.

These dates match what our team has seen work for years. In a scandiweb Black Friday panel, Glebs Vrevskis described the usual pattern: “A common thing we see is code freeze starting from the first days of November, with no new features being released.” Reinis Groskops added that “the latest time to do any major deployments is probably 2 weeks before Black Friday.” The full Black Friday Q&A with our team covers the rest of their advice.

Two dates in the table are easy to miss. If you’re on Adobe Commerce on cloud infrastructure, Adobe recommends requesting a temporary compute upsize at least 10 business days before a major promotion, and finishing all patching before the code freeze. Promotions don’t count as emergencies, and Adobe notes that capacity during Black Friday and Cyber Monday is limited, so book early. If you’re still on a release line close to end of support, check our Magento end-of-life guide before the freeze, because a patch you can’t apply in November waits until December.

The other date is November 25. Our support team recommends building price and promotion rules on staging, testing them there, and switching them on the evening before the sale, without a customer email going out at the same moment. On high-load stores, that gives the platform a night to reindex before the traffic arrives, and any problem shows up while there’s still time to fix it. It’s the lesson from the outage in the introduction: once the rule was rebuilt to exclude five SKUs, it applied in two to three minutes instead of taking the site down for about an hour, and the fix was worth $500,000 in extra sales for that client.

Read more: How scandiweb Support Saved a Client’s Sales Event

If your sales start earlier, as many now do, move the whole calendar back by the same number of days. Date the freeze from the first day of heavy traffic, whatever the banner says.

Black Friday load testing: targets, scenarios, and pass criteria

eCommerce load testing for Black Friday means simulating your expected peak traffic, measured at the busiest minute, on an environment sized like production, and checking that shoppers can still search, add to cart, and pay within agreed response times. Set the target from your own data, script the full buying journey including checkout, and run at least two rounds with fixes in between.

Can the site take 5× traffic?

It depends on what the 5 multiplies. Five times an average day is often below a real Black Friday peak. On one Black Friday we supported, visits were up 10,955% on an average day, and concurrent visitors went from a couple of hundred to more than 17,000 as the first campaigns went out.

Build the target from numbers you already have:

1. Find last year’s peak minute. Take the busiest hour from GA4 or your server logs, then look for the minute-level spikes inside it. Email sends and campaign launches create bursts that an hourly average hides.
2. Apply this year’s forecast. Multiply by the growth the business expects and add any new traffic sources, such as a bigger email list or paid budget.
3. Translate it into load. Express the target as concurrent sessions, page requests per second, and orders per minute. Orders per minute is the number that matters most, because checkout is the most expensive journey to serve.
4. Add headroom. Test at the forecast peak, then at double it, then keep raising the load until something breaks, so you know where the ceiling is and what fails first.

Black Friday traffic is also different from normal traffic. Most days, shoppers browse cached category pages. After the last deploy before the freeze, warm the cache for your top pages so peak traffic doesn’t start on cold ones. On Black Friday, they add to cart and check out, and those pages aren’t cached, so the same number of visitors puts far more load on the application and the database.

Which scenarios to test

A test that hammers the homepage measures your CDN, and not much else. Script the journeys that make money and the background jobs that run at the same time:

Point payments at a sandbox or a stub. A load test that sends thousands of real authorizations to your payment provider may trip its fraud checks, and nobody wants to explain that on November 20.

Pass criteria that make the result useful

Agree the pass criteria before the first run, so the result is a clear pass or fail. The thresholds below are a starting point to adapt, not a standard:

The last row is the one teams forget. On the Black Friday above, the servers held, but orders arrived faster than the order queue could process them, and confirmation emails would have been delayed by days. The fix was a script that moved orders into separate batches on a dedicated instance. A queue-depth check in the load test would have found it earlier.

Read more: Scaling Up to Accommodate a 40000% Increase in Sales

Where to run the load test

Run the main rounds on an environment with the same size, configuration, and CDN setup as production. A staging server with half the CPU tells you little about Black Friday.

How you test depends on the platform:

• Adobe Commerce on cloud: test on a production-sized environment, watch the results in New Relic, and request the temporary upsize you need for the peak. Adobe’s checklist also covers read replicas, indexers set to Update on Schedule, and asynchronous order processing.
• Self-hosted Magento or headless: you own every layer, so the test has to cover the web servers, database, cache, search engine, message queue, and CDN. Agree any test against production with your host first, and run it at night.
• Shopify and Shopify Plus: Shopify runs and scales the platform, so your test surface is everything you added, such as a headless storefront, custom apps, checkout extensions, and the middleware that connects Shopify to your ERP. Ask Shopify before you point a load generator at the live storefront.

If the test exposes a slow storefront, our guide to speeding up Magento and Shopify performance playbook cover the usual fixes. For drops and limited releases where demand can exceed any capacity you’d buy, a virtual waiting room keeps checkout working for the shoppers already inside.

What to do when the test finds the ceiling

The ceiling is the traffic level where response times climb and errors start. You can move it before Black Friday in two ways: add capacity, so more servers share the work, or make each request cheaper, so the same servers handle more shoppers.

Adding capacity is the quicker lever on most hosting. On Shopify, the platform handles this part for you. On Adobe Commerce on cloud, it is the temporary upsize in the timeline above. On self-hosted Magento, it means more web servers behind the load balancer, and our guide to server autoscaling in Magento 2 explains how to add them automatically. Extra servers cost money for as long as they run, and the database still has to keep up with all of them.

Making each request cheaper raises the ceiling without new hardware. Many Black Friday requests reach Magento uncached, such as filtered category pages, searches and the first visits after a cache flush, and Magento builds each of those pages on the server. Expedio makes that page build at least 2x faster, so the same servers handle 3x the traffic before response times start to rise. The Expedio benchmark shows how we measured it on one merchant’s Hyvä store.

Treat Expedio like any other release. It installs as a module without changing your theme or data, but it still needs a load test, so put it in before the strict freeze on November 13. If that’s too tight, plan it for the next peak.

The incident plan: runbook, roles, and on-call rotation

An eCommerce incident plan for Black Friday is a short document that says who is on call, how an incident is declared, who decides, and what the first action is for each likely failure. It should name people, list phone numbers for every outside provider, define severity levels, and include a tested rollback, so that at 9 p.m. on Black Friday nobody has to work out the process while the checkout is down.

The order of steps matters more than the detail. During an incident, restore sales first, through a rollback, a disabled extension, or a switched payment method. Find the root cause afterward.

Roles to name before the peak

Each role needs a named person and a backup for every shift:

• Incident lead: declares the incident, sets the severity, and keeps the timeline. This person coordinates and doesn’t debug.
• On-call developer: investigates and applies the fix or rollback.
• Infrastructure or hosting contact: scales, restarts, or fails over servers, and talks to the host.
• Business owner: decides on trade-offs, such as pausing a campaign email or switching off a payment method.
• Communications: posts updates to the team every 30 minutes and decides what customers see, such as a site banner.

On-call rotation from Thanksgiving to Cyber Monday

Write the on-call rotation down, with names, shifts, and phone numbers, and keep a copy outside Slack, because the person you need may be offline. For the peak weekend, plan for 24/7 cover with handovers at fixed times, a second person on call for severity 1 incidents, and no one on call for more than 12 hours in a row.

List the outside contacts in the runbook too: hosting, CDN, payment provider, ERP and warehouse integrations, search, and your agency, each with an emergency number and the account ID they’ll ask for. If you’re agreeing response times with an agency for the first time, our guide to support SLA tiers and 24/7 cover explains what to ask for.

Playbooks for the failures you can predict

Most Black Friday website crashes follow a few patterns. Write a first action for each one before the peak:

Each playbook needs a kill switch: a configuration flag or admin setting that turns the risky feature off without a deploy. Test every one of them during rehearsal week.

What to watch on the dashboard

Put the measures that show lost revenue on one screen, compared with the forecast for that hour:

• Orders per minute against the forecast
• Payment success rate by method
• Checkout and cart error rate
• Server response time and error rate
• Queue depth for orders, emails, and stock updates
• Purchase events arriving in GA4 and your ad platforms

The last line catches a quiet failure. If purchase events stop arriving, the ad platforms keep spending on the busiest days of the year with no conversion data. If your tracking runs through a server-side tracking setup, add the server container’s error rate to the same screen.

Practice the plan once before it’s needed. In rehearsal week, simulate one incident, such as a failed payment provider on staging, and time how long it takes from the alert to the workaround.

Test orders on production during peak

Yes, you can place test orders on production during the peak, and you should, as long as they follow agreed rules. A small number of real test orders each morning of the peak and after every approved change is the most direct proof that checkout, payment, stock, and order export still work end to end. Agree who places them, how they’re marked, and how they’re cancelled and refunded.

Mark every test order clearly, for example with a test customer email and an order note, and tell the warehouse and finance teams which orders to ignore. Exclude them from reporting, or your peak-day numbers will be slightly wrong in every dashboard.

FAQ about the Black Friday code freeze

What is a code freeze?

A code freeze is a set period when no changes are deployed to a production system, so it stays in a tested, known state. Before Black Friday, eCommerce teams use a code freeze to protect the store during the peak. A good one also covers configuration, extension updates, tag manager changes, and infrastructure, with an emergency process for security fixes.

When should the code freeze start for Black Friday?

For Black Friday 2026, on November 27, start a feature freeze on November 2 and make the last planned deployment on November 13, two weeks before the peak. Use the time in between for load testing and fixes. If your sales start earlier in November, move each date back by the same number of days.

How long should a Black Friday code freeze last?

Most stores keep the strict freeze for about two to three weeks: from two weeks before Black Friday until the day after Cyber Monday. For 2026, that means November 13 to December 1. Stores with heavy December trade often keep a lighter freeze until their last Christmas delivery date.

Can we deploy a fix during the code freeze?

Yes, through an emergency change process. Security patches (such as the October 2026 PHP2Shell fix) and fixes for bugs that hurt sales can go live during the freeze if they’re tested on staging, approved by a named person, deployed at a quiet hour, and have a rollback ready. Everything else waits until the freeze lifts.

Can the site take 5× traffic?

Only a load test can answer that, and only once you define what 5× means. Base the target on last year’s busiest minute, multiplied by this year’s forecast, then test at that level, at double it, and up to the break point. Five times an average day is often less than a real Black Friday peak.

Should we load test on production?

Run the main load tests on an environment that matches production in size and configuration. Test production itself only with your hosting provider’s agreement, at a low-traffic hour, with payments pointed at a sandbox. On Shopify, check with Shopify before running load against the live storefront.

Can we place test orders on production?

Yes, with rules. Place a few real test orders each morning of the peak and after any approved change, using a small real payment you cancel and refund, or a hidden test product. Mark the orders clearly, tell the warehouse and finance teams, and exclude them from reporting. Don’t switch payment test modes on in a live store.

Who should be on call during Black Friday?

At minimum, an incident lead, an on-call developer, a hosting or infrastructure contact, and a business owner who can pause campaigns or switch payment methods. Cover the full Thanksgiving to Cyber Monday window around the clock, name a backup for each shift, and keep phone numbers for every outside provider in the runbook.

Plan the code freeze this week

A Black Friday code freeze works when it starts from the load-testing plan, covers configuration as well as code, and ends with a team that knows who answers the phone. For 2026, that means locking scope this week, testing from late October, freezing features on November 2, and keeping production stable from November 13 through Cyber Monday. Write the runbook now, while there’s time to rehearse it.

Not sure your store will hold at the peak? Talk to our team about load testing and on-call cover before the freeze starts.

The post Black Friday Code Freeze: 2026 Timeline, Load Testing, and Incident Plan appeared first on scandiweb.

When a buyer asks ChatGPT, Gemini or Perplexity which bank, airline or pharmacy to choose, the answer names a short list of brands, and the order of that list decides who gets chosen. Knowing where your brand stands in those answers is the first step to being recommended more often.

To see where Baltic brands stand, we built the Baltic AI brand ranking. We asked the three assistants 3,419 buyer questions over a month and scored 5,548 companies in 113 industries across Latvia, Estonia and Lithuania, using AnswerRank. Lina Ivanova, our Head of Traffic Acquisition, presented the results at Baltic Brand Forum 2026 in Riga and announced the winners on the main stage.

Banks, an airline, a bookstore and a fuel retailer are among this year’s winners and finalists, and one brand came out on top in three of the four rankings.

The top 10 most AI recommended brands in the Baltics

Circle K leads the Baltic list with a score of 92.6, followed by Swedbank at 88.1 and Revolut at 87.8. The Baltic list only includes brands AI names in all three countries. A company that ChatGPT recommends in Latvia alone appears in the Latvian ranking instead. Two banks, a fuel retailer, a car rental company and an airline make up the top five.

DPD has no Lithuania score in the published table, so its LT cell shows a dash.

The list continues past these ten, and every industry has its own page with results per country. You can see the full Baltic AI Brand Ranking and search it for any company.

Winners and finalists in Latvia, Estonia and Lithuania

Circle K won in Latvia and Lithuania. Rahva Raamat, a bookstore, won in Estonia with 93.5, the highest score among the four winners. The winner of each ranking is the brand ChatGPT, Gemini and Perplexity recommend most, and the finalists hold places 2 to 5. The country lists also include brands AI names in only one or two countries, so the finalists differ from the Baltic top 10.

Latvia

Circle K won Latvia with 91.5. The finalists follow.

• 2nd place: Jānis Roze, Bookstore, 90.2
• 3rd place: Swedbank, Banking, 89.8
• 4th place: Stockmann, Department Store, 89.5
• 5th place: Tet, IPTV, 89.2

Estonia

Rahva Raamat won Estonia with 93.5. The finalists follow.

• 2nd place: Circle K, Fuel Retail, 93.3
• 3rd place: DPD, Parcel Delivery, 90.9
• 4th place: Benu, Pharmacy, 89.7
• 5th place: Selver, Online Grocery Delivery, 89.4

Lithuania

Circle K won Lithuania with 93.2. The finalists follow.

• 2nd place: Revolut, Digital Banking, 91.6
• 3rd place: Pigu, eCommerce Platform, 91.1
• 4th place: Maxima, Grocery / Supermarket, 90.7
• 5th place: Verslo Žinios, Business News, 90.6

Two things stand out in the country results. Circle K won three of the four rankings and finished second in Estonia, 0.2 points behind Rahva Raamat. Bookstores also do well: Rahva Raamat won Estonia, Jānis Roze is second in Latvia and Pegasas leads the Lithuanian bookstore category with 86.5. You can see all winners and finalists, including the company AI names first in each of the 113 industries, on the winners page.

How the Baltic AI Brand Ranking was measured

We ran the study in AnswerRank, our AI search monitoring tool. Over a month, AnswerRank put the same buyer questions to ChatGPT, Gemini and Perplexity for each industry in Latvia, Estonia and Lithuania, 3,419 questions across 113 industries, and recorded every company named in the answers. For each company it tracks how often the answers mention it, how they describe it and where in the answer it appears. A brand only appears in the ranking if AI named it, and the questions behind each industry are listed on that industry’s page of the ranking.

Three measures in one score

Each company gets one score out of 100, built from three measures.

The ranking is independent and built by scandiweb. Baltic Brand Forum does not operate the ranking, and it is separate from the forum’s own Baltic Brand Awards, which are based on Norstat’s Brand Capital research.

Why AI recommendations matter for your brand

When a buyer asks an assistant which bank or pharmacy to use, the answer is a short list, and the order of that list decides who gets seen. Across our industry rankings, the brand named first appears in 67% of answers on average. The brand in fifth place appears in 22%. First place is close to the default answer, while fifth place is an occasional mention.

The ranking page breaks results down by industry and by country, and the same question often gets a different answer in each market. Maxima is the grocery chain AI names first in Latvia and Lithuania, while Prisma leads in Estonia. In parcel delivery, Omniva leads Latvia, DPD leads Estonia and Venipak leads Lithuania. A brand that is well placed in one country needs its own check in the other two.

Visibility in AI answers is the subject of answer engine optimization, or AEO. If the term is new to you, read our post on what answer engine optimization is first. The short version is that assistants build answers from the pages and third-party sources they can read, and a brand can change what those sources say about it.

Announced on stage at Baltic Brand Forum

scandiweb was an official partner of Baltic Brand Forum 2026, held on September 24–25, 2026 at Riga Circus under the theme “Stand Out”. Lina Ivanova, our Head of Traffic Acquisition, spoke on the main stage with the talk “When Buyers Ask AI What to Buy, Is Your Brand in the Answer?” and announced the winners of the AI ranking from that stage.

Brands that heard their name in the hall can find their full industry results on the ranking page.

How to move your brand up in AI answers

AI search optimization builds on SEO. Assistants that search the web read pages that search engines can find, so the technical work you already do for Google still counts. Two more things need attention on top of it: the full-sentence questions buyers ask and the third-party sources AI quotes. Our guide on how to rank in AI search covers each step in detail. The short version follows.

1. Find the questions buyers ask, such as which bank in Lithuania has the lowest fees.
2. Check where AI places you today by searching the ranking for your company and noting your visibility, sentiment, average position and the competitors named ahead of you.
3. Answer those questions on your own site, covering what you sell, where you deliver and what it costs, with one page per market in its own language.
4. Get mentioned in the sources AI reads, including review sites, comparison articles, directories and news coverage.
5. Make your site readable for AI crawlers, with key content in HTML, structured data in place and a robots.txt that does not block GPTBot, OAI-SearchBot, PerplexityBot or Google-Extended.
6. Keep your facts the same everywhere, so your company name, address and product details match across your site, Google Business Profile, social profiles and directories.
7. Work on what AI says about you by answering reviews, fixing the problems customers keep mentioning and correcting outdated facts on third-party pages.
8. Measure the same questions every month, because AI answers change as the assistants update their sources.

For the measurement in step 8, see our post on tracking brand mentions in AI-generated answers.

Where does your brand stand?

Search the Baltic AI Brand Ranking for your company name. The result shows your visibility, sentiment and average position, and the competitors named ahead of you. If your brand is missing from the Baltic list, check the country rankings first, since they include brands named in fewer than three countries. If it is still not there, use the Don’t see your brand? page.

FAQ

What is the Baltic AI Brand Ranking?

It is an independent ranking of 5,548 companies in 113 industries across Latvia, Estonia and Lithuania, ordered by how often ChatGPT, Gemini and Perplexity recommend them. scandiweb built it and gathered the data with AnswerRank, asking 3,419 buyer questions over a month. Each company gets one score out of 100 based on visibility, sentiment and average position.

Which brand does AI recommend most in the Baltics?

Circle K, with a Baltic score of 92.6. Swedbank is second at 88.1 and Revolut third at 87.8. By country, Circle K also won Latvia with 91.5 and Lithuania with 93.2, while Rahva Raamat won Estonia with 93.5. Each of the 113 industries has its own leader per country, listed on the winners page.

How is the AI brand score calculated?

Visibility is the share of answers that mention the company. Sentiment is how favorably the answers describe it. Average position is where the company appears in the answer, with 1 meaning first. The score rolls the three into one number out of 100. Visibility is weighted most, sentiment second, and position separates brands whose scores are close.

Is the ranking connected to the Baltic Brand Awards?

No. The Baltic AI Brand Ranking is independent, built by scandiweb and announced at Baltic Brand Forum, where scandiweb was an official partner. The forum’s Baltic Brand Awards are a separate program based on Norstat’s Brand Capital research. A brand can win one and not appear in the other, so the two should not be read as a single result.

Why is my brand not in the ranking?

There are four common reasons. AI did not name your brand for your industry’s questions. Your brand is listed under another name, as Rimi Eesti Food is in Estonia. Your brand is named in only one or two countries, which keeps it off the Baltic list but still in the country rankings. Or your industry was not among the 113 tested.

How long does it take to move up in AI answers?

There is no fixed timeline. Each assistant refreshes its sources at its own pace, so a change on your site or in a third-party source shows up in ChatGPT, Gemini and Perplexity at different times. That is why the last step in our guide is to measure the same questions every month and compare the results.

What the ranking means for your brand

The Baltic AI brand ranking gives you a measured answer to a question most brand teams have only guessed at: whether ChatGPT, Gemini and Perplexity name you when a buyer in Latvia, Estonia or Lithuania asks what to choose. Circle K, Swedbank and Revolut lead the Baltic list, Rahva Raamat leads Estonia, and 113 industries have their own leaders in each country. The gap between first and fifth place, 67% of answers against 22%, is the number to keep in mind. Congratulations again to the winners and finalists. For everyone else, the eight steps above are where to start, and the ranking page is where to check your position today.

Get a measurement of where AI places your brand, and we will show you which questions it is missing from.

The post We Ranked 5,548 Baltic Brands for AI Search: Meet the Winners appeared first on scandiweb.

If your developer says the filter pages are wasting crawl budget and someone in marketing wants every filtered URL indexed for long-tail traffic, you’re probably waiting to find out which of them is right. Faceted navigation SEO usually gets argued as a choice between those two camps: block every filter URL, or let Google have them all.

Neither works on a real catalog. One category with six filters can produce over half a million URL combinations, and almost none of them match anything a shopper types. A few do, and “black leather ankle boots” alone gets about 1,200 searches a month in the US. The job is to find those few, give them proper pages, and keep Google away from everything else, on Magento, Shopify, or any other platform.

What faceted navigation SEO decides

Faceted navigation SEO, sometimes called faceted search SEO, is the set of rules that decides which filter combinations on your category pages search engines may crawl and which they may index. Filters for color, size, brand, or price each add a parameter or path to the URL, and filters combine. The SEO work is choosing the small set of filtered pages that deserve to rank and keeping crawlers out of the rest.

Those are two separate decisions. Crawling is whether Googlebot fetches the URL at all. Indexing is whether the page can appear in search results. robots.txt controls the first, while canonical tags and noindex act on the second, and mixing them up causes many of the problems we find in store audits.

The scale is what makes it urgent. Take one category with six filters: 12 colors, 10 sizes, 20 brands, 5 price bands, 6 materials, and 4 sort orders. If a shopper can pick one value per filter, that category alone has about 630,000 possible URLs. Allow two colors at once, or let the parameters appear in any order, and the number keeps growing. Google’s own guidance on faceted navigation says filters can generate “infinite URL spaces”, and that crawlers often fetch many of these URLs before they recognize them as low value.

Crawl waste vs long-tail opportunity

Both arguments in your team are about real effects. Filter URLs do use up crawling that could go to new products, and some filter combinations do match searches your main categories can’t win. The answer is to measure each side on your own store before choosing.

Are filter pages wasting crawl budget?

They can be, once enough filter URLs are open to crawlers. Google’s crawl budget guide is written for sites with more than a million pages that change weekly, sites with 10,000+ pages that change daily, and sites with many URLs in “Discovered – currently not indexed”. A store with layered navigation can land in that last group with only a few thousand products, because the filters multiply the URL count far past the catalog size.

Three checks tell you whether it’s happening on your store:

1. In Search Console, open Settings and then the Crawl stats report. Compare the number of daily requests with the number of products and categories you sell, and look for filter parameters in the example URLs under each response type
2. In the Page indexing report, a large and growing “Discovered – currently not indexed” count full of filter URLs means Google keeps putting off crawling them. Our guide to Search Console statuses like duplicate without user-selected canonical explains how to read each status
3. In your server logs, group Googlebot requests by URL pattern. If filter and sort URLs take a bigger share of requests than product pages, crawling is going to the wrong place

The cost shows up as slower discovery. New products and price changes take longer to reach search, because Googlebot is busy with URLs like ?color=black&size=9&sort=price_asc.

Where the long-tail demand is

The opportunity is also real, but it shrinks fast as filters stack up. Here is the US search volume ladder for one footwear category, from Ahrefs in October 2026:

• ankle boots: 27,000 searches a month
• black ankle boots: 5,400
• black leather ankle boots: 1,200
• black leather ankle boots size 8: 0

The same pattern repeats in other categories. “Mens linen shirts” gets 8,200 searches and “blue linen shirt men” gets 300. “Green velvet sofa” gets 3,300. One attribute on top of a category often carries real demand, a second one sometimes does, and size, price, or availability on top of that almost never does.

The decision rule: which filter combinations deserve an indexable URL

A filter combination deserves an indexable URL when people search for it as a phrase, the parent category doesn’t already answer that search, enough products stay on the page, it adds no more than one or two filters to the category, and you can give it a stable page of its own. Every combination that fails any of these tests stays out of the index, and most should stay out of the crawl.

Run each candidate through the five tests in order. The first two decide most cases.

1. Search demand: check the phrase a shopper would type, such as “black leather ankle boots”, in a keyword tool for your main market. Pick one threshold for the whole catalog, for example 50 searches a month, and apply it the same way to every candidate
2. Different intent from the parent: someone searching “green velvet sofa” wants green velvet sofas and would be let down by the full sofa category. Someone searching “sofas under $1,000” is usually happy on the sofa category with a price filter. Color, material, style, brand, and use case tend to pass. Size, price, and availability tend to fail
3. Enough products, consistently: the page needs enough products to fill at least the first screen, in a range that doesn’t empty out every few weeks. A filter page that drops to zero products turns into a soft 404
4. One or two filters deep: a category plus one attribute, or plus two at most, like brand and type. Three or more filters almost never pass test 1
5. A stable page you can own: one clean URL, its own title, H1, and short intro copy, and links from the parent category. If your platform can only produce the combination as a parameter URL whose order changes, build a dedicated page for it instead

Everything that fails goes into one of two groups. Single filters with no demand can stay crawlable with a canonical tag pointing to the category, as long as their number stays small. Deeper combinations, sort orders, page-size options, and price ranges should be blocked from crawling.

Should filtered URLs be indexed?

Only the few that pass all five tests, and usually as dedicated pages. Next to the number of possible filter URLs, that list is short. Leaving the rest out of the index doesn’t cost traffic, because nobody searches for them, and it keeps the category pages as the clear target for their head terms. Our duplicate content guide covers what happens when thousands of near-identical filter pages compete with the category instead.

Index, noindex, canonical or robots.txt: what each does to filter URLs

Use robots.txt to stop crawling of filter URLs you never want in search, a canonical tag for small sets of single-filter pages that should pass their signals to the category, and a self-referencing canonical on the pages you chose to index. Noindex is rarely the right tool for faceted navigation, because Google still has to crawl a page to see the tag.

A few details from Google’s documentation matter here. A URL blocked in robots.txt can still be indexed without its content if other pages link to it. Google says a canonical tag on filter URLs may reduce crawling of them over time, but it calls robots.txt the more effective long-term control. Its crawl budget guide is direct about noindex: Google “will still request, but then drop the page”, so noindex saves no crawling at all.

Combinations that send mixed signals

A broken faceted navigation setup often has the right tools in the wrong combination.

• A robots.txt block plus noindex: Google can’t crawl the page, so it never sees the noindex
• Noindex plus a canonical to the category: one tag says drop the page, the other says merge it into the category. Google advises against noindex for canonicalization, so use the canonical alone
• A canonical to the category on a filter URL that’s in your sitemap or main menu: your internal signals point at the filter URL while the tag points away from it, and Google may ignore the tag
• Blocking filter URLs that are already indexed: they can stay in the index without content. If you need them gone first, allow crawling with noindex until they drop out, then add the robots.txt rule

How to build a filter page worth indexing

A filter combination that passed the five tests needs to work like a real category page. Otherwise Google may treat it as a near-duplicate of the parent and index the parent instead.

1. A clean, stable URL. A path such as /boots/black-leather-ankle-boots is easiest to keep stable. If you use parameters, keep one fixed order and the standard “&” separator, as Google recommends
2. A self-referencing canonical tag, never one pointing to the parent category
3. Its own title, H1, and meta description built on the phrase people search, such as “Black Leather Ankle Boots”
4. A short intro that helps shoppers choose between the products shown, with a few sentences on materials, fit, or care
5. Internal links from the parent category, for example a row of popular styles above or below the product grid, plus breadcrumbs back to the category
6. A place in the XML sitemap next to your regular categories
7. A plan for when stock runs out. Keep the page live with related products while the range is seasonal, and return a 404 or redirect to the parent if it’s gone for good

Filter UX still matters for shoppers on every other combination. Our guide to product listing page best practices covers filter order, labels, and mobile layouts.

Magento and Adobe Commerce implementation notes

By default, Magento adds each filter to the category URL as a query parameter with a numeric option ID, so a filtered page looks like /women/boots.html?color=49&material=148. That makes the parameters easy to block with robots.txt and hard to turn into pages worth indexing. The usual setup has three parts.

Canonical tags for filtered category URLs

Go to Stores > Settings > Configuration > Catalog > Catalog > Search Engine Optimization and set “Use Canonical Link Meta Tag For Categories” to Yes. Filtered URLs then point their canonical to the clean category URL. Adobe recommends enabling the canonical tag for both categories and products.

robots.txt rules for filter parameters

Add your rules under Content > Design > Configuration, in the Search Engine Robots section for the right scope. A typical starting set blocks filter, sort, and toolbar parameters:

User-agent: *
Disallow: /*?*color=
Disallow: /*?*material=
Disallow: /*?*price=
Disallow: /*?*product_list_order=
Disallow: /*?*product_list_dir=
Disallow: /*?*product_list_limit=
Disallow: /*?*product_list_mode=

Replace the attribute codes with the filterable attributes your store uses, and check the live URLs first. Headless frontends, AJAX filters, and search services such as Adobe’s Live Search can produce different parameters. Our guide to the Magento 2 robots.txt setup lists the system paths that belong in the same file.

Indexable filter pages as categories

Build each combination that passed the five tests as a category. Create a subcategory such as “Black Leather Ankle Boots” under Boots, with its own URL key, meta title, meta description, and description, and assign the products. On Adobe Commerce, the Visual Merchandiser can fill the category automatically with “Match products by rule”, using attribute conditions such as color and material. Adobe notes the rule is applied when the category is saved, and products that no longer match are removed. Link the new category from Boots, so shoppers and Google reach it from the parent.

How to choose filterable attributes, set up anchor categories, and speed up filtering with AJAX or Hyvä is covered in our guide to Magento layered navigation setup.

Shopify implementation notes

Shopify’s defaults already handle two of the three outcomes from the decision rule: canonical and block. We checked them on Shopify’s own Dawn demo store in October 2026. Storefront filters, which you set up in the admin or the Search & Discovery app, add parameters such as ?filter.v.option.color=Black or ?filter.p.vendor=Nike to the collection URL, and a store can have up to 25 filters.

What Shopify’s default robots.txt blocks

The standard file disallows sorted collection URLs, combined tag URLs, and any collection URL with two or more filter parameters:

Disallow: /collections/*sort_by*
Disallow: /collections/*+*
Disallow: /collections/*filter*&*filter*
Disallow: /*/collections/*sort_by*
Disallow: /*/collections/*+*
Disallow: /*/collections/*filter*&*filter*

A URL with a single filter stays crawlable. On the Dawn theme, that single-filter URL and even a two-filter one carry a canonical tag pointing to the unfiltered collection. So out of the box, single filters are canonicalized to the collection and combinations are blocked. Custom themes can change the canonical, so check yours with the URL Inspection tool.

The second set of lines covers language and market subfolders. If you sell in several countries through Shopify Markets subfolders, each subfolder repeats the whole filter space, so any rule you add needs the same pair.

Indexable filter pages as collections

Shopify has no admin setting that turns a filter URL into an indexable page, and the theme’s canonical points it at the collection anyway. Build each combination that passed the five tests as its own automated collection, with conditions such as product type equals Boots and a tag or metafield for black leather. It gets its own handle, title, description, and place in the sitemap, and you link to it from the parent collection.

Adding your own rules in robots.txt.liquid

To block single filters with no search value, such as availability or price, edit the robots.txt.liquid template and add rules for those parameters. Keep Shopify’s default rules in the file. Our Shopify SEO checklist covers the rest of the theme-level setup.

How to check faceted navigation after a release or migration

New filters, a theme update, or a replatforming project can undo a working setup in one deploy. Check four things after each one:

1. Fetch the live robots.txt and test a few filter URLs against it. A staging file that blocks everything, or a filter rule lost in the deploy, are both common release mistakes
2. Inspect one filter URL and one indexable filter page with the URL Inspection tool, and compare the user-declared and Google-selected canonical
3. Watch “Indexed, though blocked by robots.txt” and “Discovered – currently not indexed” in the Page indexing report for new filter patterns over the following weeks
4. Check the Crawl stats report. A jump in daily requests right after the release usually means a new parameter became crawlable

Migrations need extra care because filter URLs change format between platforms. A Magento ?color=49 URL has no equivalent on Shopify, so every indexable filter page needs a matching page on the new platform and a 301 redirect in the redirect map, and the new robots.txt rules need to be live on launch day. Our SEO migration checklist covers the full redirect and launch process.

A technical SEO audit checks crawl rules, canonicals, and status codes across every template in one pass. It’s also where our eCommerce SEO team starts when filter URLs outnumber the products on a store.

Frequently asked questions about faceted navigation SEO

Are filter pages wasting crawl budget?

They can be, if search engines can crawl every filter combination. Check the Crawl Stats report in Search Console and your server logs for the share of Googlebot requests that go to filter and sort URLs. A growing “Discovered – currently not indexed” count full of filter URLs is another sign. Blocking combinations with no search value in robots.txt is the fix Google recommends.

Should filtered URLs be indexed?

Only the ones people search for. A filter combination deserves an indexable URL when the phrase has search demand, the intent differs from the parent category, enough products stay on the page, it adds no more than one or two filters, and it has a stable page with its own title and copy. Everything else should stay out of the index.

Should I use noindex or a canonical tag on filter pages?

Use a canonical tag pointing to the category for a small set of single-filter pages, and robots.txt for everything deeper. Noindex keeps a page out of search but saves no crawling, because Google still has to fetch the page to read the tag. Never combine noindex with a canonical to another URL, since the two send opposite signals.

Is robots.txt or rel=canonical better for faceted navigation?

For filter combinations you never want in search, robots.txt is better, and Google calls it the more effective long-term control. A canonical tag still lets Google crawl the URLs and only reduces crawling over time. Use canonicals for the few single-filter pages that should pass their signals to the category, and robots.txt for the rest.

Should sort and page-size URLs be indexed?

No. Sorting by price or showing 48 products per page changes the order and number of products, but the page targets the same search as the category. Block these parameters in robots.txt. Shopify’s default robots.txt already blocks sort_by URLs on collections, and on Magento you add rules for the product_list parameters yourself.

How many filters can a page combine and still be worth indexing?

Usually one, sometimes two. Search demand drops fast as filters stack up. In the US, “black ankle boots” gets about 5,400 searches a month, “black leather ankle boots” about 1,200, and adding a size brings it to zero. Pages with three or more filters almost never have enough demand to justify their own URL.

Do AJAX filters solve faceted navigation SEO?

They solve the crawl side, but they don’t help the long tail. If filters update the product grid without changing the URL, there are no filter URLs to crawl or index. That also means no filter page can rank, so you still need dedicated category or collection pages for the combinations people search for.

What happens to filter pages when you migrate platforms?

Their URLs change, because every platform formats filters differently. List the filter pages that get organic traffic before the migration, build matching category or collection pages on the new platform, and 301 redirect the old URLs to them. Set the new robots.txt filter rules before launch, so the new store doesn’t open its full filter space to crawlers on day one.

Faceted navigation SEO comes down to a short list

Faceted navigation SEO is mostly a list: the filter combinations that earn their own page, and a rule that blocks the rest. Build the list from search demand, give each entry a proper category or collection page, block deep combinations, sort orders, and price ranges in robots.txt, and recheck the setup after every release. Review the list each season too, because new filters and new ranges change which phrases have demand.

Not sure which of your filter pages belong in Google? Send us a category URL, and we'll show you which combinations to index and which to block.

The post Faceted Navigation SEO: Which Filter Pages to Index and Which to Block appeared first on scandiweb.

If your B2B portal has been live for six months and your best customers still email their orders to the same rep, you are where most suppliers are after launch. The platform usually works. What’s missing is B2B customer onboarding, and in most companies nobody has been given that job.

Suppliers also tend to overrate how far they have come. In a Deloitte Digital survey of 530 US B2B suppliers and 530 buyers, 72% of suppliers said their sales processes were mostly or highly automated. Only 47% of buyers said their purchasing processes were.

Launch is day 0. The 12 months after it decide whether the portal replaces the phone or becomes one more channel your team maintains. This guide covers why existing customers don’t switch on their own, a five-stage onboarding plan from go-live to month 12, how to pay reps when their customers order online, and the numbers to report to leadership.

What is B2B customer onboarding?

B2B customer onboarding is the work of moving existing business accounts from ordering by phone, email, EDI, or through a sales rep to ordering on your B2B customer portal. It covers account setup, the first online order, reasons to come back, and changes to how sales is paid. It runs for months after go-live, account by account.

Most guides that rank for this term describe SaaS onboarding: getting a new user to their first “aha” moment in software, the topic of our user onboarding best practices. A supplier’s problem is different. Your customers already buy from you, and the old way of ordering still works for them.

Our B2B eCommerce trends for 2027 put customer adoption among the biggest jobs suppliers face next year. This guide is the detailed plan for that job.

Why B2B customers don’t use a new portal

B2B customers keep ordering offline after a portal launches for five common reasons: the old way still works, the portal’s prices or stock don’t match what the rep says, their account isn’t set up, products they buy are missing online, and their rep has no reason to send them there. These are the B2B eCommerce challenges we see most after go-live.

Buyers do want to order on their own. Gartner found that 67% of B2B buyers prefer a rep-free experience, and Deloitte found that 65% choose purchasing channels on ease of use. The same Deloitte research shows how far suppliers are from that: buyers were six times as likely as suppliers to describe the buying process as “mostly manual,” and three times as likely to say the supplier is difficult to do business with.

The old way still works

A buyer who has emailed the same rep for years often gets a confirmed order back within the hour. Switching means a new login and searching for products they used to name in one line of an email. Unless the portal saves them time on their first order, they go back to email.

Prices and stock don’t match

A portal price that differs from the rep’s quote or the invoice undoes weeks of onboarding. Buyers call to check, and soon they stop logging in. The fix is upstream: one source for contract pricing and stock, usually the ERP, read by the portal in real time. Our guide to eCommerce ERP integration covers the patterns.

The account isn’t ready

Many launches send every customer the same invitation email and a password reset link. The buyer logs in to an empty account: no saved lists, no order history, no colleagues set up with the right approval rights. For larger customers, single sign-on removes the login problem altogether.

Products are missing

Buyers won’t move a whole reorder to a portal that only carries part of what they buy. Wainbee, the largest distributor of Parker products in Canada, had only 10% of its 600,000+ products online because supplier data arrived in CSV and XLS files with no shared structure. A Pimcore PIM connected to its ERP and supplier feeds put the full catalog online.

Read more: Case Study: Unifying Product Information with Pimcore PIM

The rep has no reason to help

If a rep’s commission depends on orders they place themselves, every order a customer places online looks like lost income. So reps keep taking orders by phone, and the portal numbers stay flat. The commission section below covers the fix.

The 5 stages of the B2B customer onboarding process

An onboarding process that works for B2B suppliers runs in five stages: choose and prepare the first accounts before go-live, set up each account in the first 30 days, place first orders together with reps in months 2–3, give buyers reasons to come back in months 4–6, and make online the default for everyone in months 7–12. These B2B customer onboarding best practices come from the B2B projects we support after launch.

Stage 1: Pick the first accounts before go-live

Don’t launch to every customer at once. Pick 20 to 50 accounts for the first wave: customers who reorder often from a stable list, buyers who already use other suppliers’ portals, and accounts whose reps are willing to help. Repeat orders are the easiest to move online, because the buyer already knows what they want.

For each account, decide before launch who owns the move (usually the rep, with support from customer service), which buyers will log in, and what the first online order will be.

Stage 2: Set up each account in the first 30 days

Treat each large account as its own small project. Before the buyer logs in for the first time, the account should already have:

• Its contract prices and payment terms, checked against the last three invoices
• Every buyer and approver, with the right roles and spending limits
• A saved list of the products they reorder most, built from their order history
• Their past orders, so they can reorder from history instead of searching

Then run a short setup call with the buyer, ideally led by their rep. Thirty minutes on a shared screen does more than any welcome email. If you run Adobe Commerce, features such as company accounts, shared catalogs, requisition lists, and quick order cover most of this, as our overview of Adobe Commerce B2B features explains.

Stage 3: Place the first orders together (months 2–3)

Ask reps to place the first online order with the buyer, either on a call or by logging in to the customer’s account and building the cart for them to approve. The buyer sees their own prices, stock, and history in the portal, and the rep stays part of the relationship.

Macron, the teamwear and sports apparel brand, gave its team a “Shop as a Customer” feature on Adobe Commerce. Support staff log in under a partner’s account and help with bulk orders and complex configurations, using the same catalog and prices the partner sees. With SAP integration for live stock and flexible ordering by SKU, CSV upload, and reorder, Macron cut order creation time by 40%.

Read more: Case Study: Macron’s B2B Platform Evolution with Adobe Commerce

Stage 4: Give buyers reasons to come back (months 4–6)

A portal that is only a cart gets used only when someone remembers to order. Give buyers reasons to log in between orders:

• Reorder prompts. Send reminders when an account’s usual reorder date passes, based on its real order history, with a one-click link to the saved list.
• Order status and documents. Tracking, invoices, delivery notes, and certificates in the portal stop the “where is my order” calls.
• Self-service for routine requests. Returns, statement downloads, and user changes the buyer can do alone.

This is also where support costs start to fall. advancedlife, Australia’s national school photography specialist, replaced five legacy systems with one platform that includes a self-service portal for schools. Schools upload rosters, correct student data, and download images without contacting the support team. The platform went live in 14 weeks, before the busiest season, and support load dropped 95% after go-live.

Read more: School Photography Commerce: Production-Ready Platform in 14 Weeks

Reorder prompts work best as a lifecycle email program triggered by order data. Our email marketing team builds these flows on top of the portal’s order history.

Stage 5: Make online the default (months 7–12)

By month 7 the first waves are ordering online and the long tail is still on the phone. Now change the defaults:

• Customer service enters phone and email orders into the portal on the customer’s account, so history and saved lists build up there.
• New customers open accounts on the portal from day one.
• Small accounts below a set order value get portal-only ordering, with a phone line for exceptions.
• Paper order forms and spreadsheet price lists are retired.

Don’t force your largest accounts. Some will keep EDI or move to punchout from their procurement system, and that still counts as digital. Deloitte found that 92% of buyers who use EDI today plan to shift partly or fully to other channels such as eCommerce or procurement systems. Later, some orders may come from AI agents through protocols such as Google’s Universal Commerce Protocol, and they will need the same account prices the portal shows.

How to pay sales reps when customers order online

Pay reps on all of their accounts’ revenue, whatever channel the order comes through. If commission only counts orders the rep places, every online order costs the rep money, and they will steer customers back to the phone. Once channel no longer affects pay, reps can treat the portal as a tool that frees their time for new business.

Three commission models work in practice:

1. Account-based commission. The rep earns on every order from their accounts, online or offline. This is the simplest fix and usually the first one to make.
2. Adoption targets on top. A quarterly bonus for raising each account’s share of online orders, for example from 20% to 60% over two quarters.
3. New business weighting. A higher rate on revenue from new accounts, so time saved on order entry goes into finding new customers.

Agree on the model before go-live. Reps who learn the new rules after the launch have already decided what the portal means for them.

How to measure B2B customer onboarding

Measure B2B customer onboarding by the share of each account’s orders placed online, tracked monthly per account. Add how many invited buyers placed a first order, how many reorder online, and how much time order entry and support take. Logins and traffic alone hide the accounts that never moved.

Report these per account. A few large accounts ordering almost everything online can make the total look healthy while two hundred small accounts still order by phone, and each group needs a different next step. Macron’s results show what to look for: returning visitors grew 32.8% after its new platform launched, and order creation time fell 40%.

If you are not sure where accounts drop off, a B2B customer experience audit maps each step from login to reorder and shows which ones lose buyers.

FAQ about B2B customer onboarding

How long does B2B customer onboarding take?

In our experience, most suppliers need 6 to 12 months to move the bulk of their accounts online. The first wave of 20 to 50 accounts can be ordering online within the first three months. The long tail of small and infrequent buyers takes longer, and some large accounts move to EDI or punchout instead of the portal.

Who should own customer adoption after a B2B portal launch?

One named person should own adoption across all accounts, usually the head of eCommerce or a digital sales manager, with reps owning their own accounts. Without a single owner, adoption falls between the eCommerce team, which built the portal, and sales, which owns the customer, and neither group reports on it.

How do you get B2B customers to order online instead of calling?

Make the first online order faster than calling. Load each account’s prices, buyers, and reorder list before they log in, have the rep place the first order with them, and send reorder reminders based on their order history. Keep prices and stock in the portal identical to the rep’s quote, or customers will call to check.

What should a B2B customer portal include on day one?

On day one, a B2B customer portal needs contract prices, live stock, saved reorder lists, order history, quick order by SKU, and user roles with approvals. Order tracking, invoices, and document downloads give buyers reasons to log in between orders. Features beyond that can wait until the first accounts are ordering online.

Should B2B suppliers force customers to order online?

Not at first. Forcing large accounts usually pushes them to a competitor or to email. Start with the accounts most likely to switch, make online ordering easier than the old way, and only make it the default for small accounts once the portal has proven itself, keeping a phone line for exceptions.

What are the biggest B2B eCommerce challenges after launch?

The biggest B2B eCommerce challenges after launch are customer adoption, prices and stock that don’t match the ERP, incomplete product data, and sales compensation that rewards offline orders. Platform features are rarely the blocker. Most stalled portals work technically but have no plan or owner for moving existing customers online.

B2B customer onboarding is the second half of the project

B2B customer onboarding turns a working portal into a channel your customers use. Plan it before launch, set up accounts one by one, let reps place the first orders, give buyers reasons to come back, and change pay so reps gain when customers order online. Then measure the online share of orders per account every month. If you want help finding new buyers as well, our guide to B2B SEO covers that side.

Portal live but the phone still ringing? Tell us where your accounts are stuck, and we'll help you plan the next 12 months of adoption.

The post B2B Customer Onboarding: Getting Customers to Use Your New Portal appeared first on scandiweb.

If your sales team keeps hearing “we already looked you up in ChatGPT” on the first call, or your reps spend more time correcting what buyers read than selling, the B2B buyer journey has changed under them. In a Gartner survey of 645 B2B buyers, 67% said they prefer a rep-free experience. In the same survey, 69% said they prefer to check AI-generated insights with a sales rep.

Those two numbers describe the same buyer. They research alone, with AI tools and supplier websites, and they bring in a person when they need to know the answer is right. The rep’s job moves from explaining the product to confirming what the buyer already found: the price, the lead time, and the fit for their application.

This guide walks through the six stages of that journey, who is in the buying group, where AI and reps each fit, and what a manufacturer or distributor has to keep consistent so that the website, the AI answer, the rep, and the invoice tell the buyer the same thing.

What is the B2B buyer journey in 2027?

The B2B buyer journey is the path a business buyer, or more often a buying group, takes from noticing a problem to placing an order and reordering. In 2027 most of that path happens before a supplier hears from the buyer. AI assistants and search build the shortlist, supplier websites provide the evidence, and sales reps come in to validate the choice and close it.

Gartner describes the B2B buying journey as six buying jobs: identifying the problem, exploring solutions, building requirements, selecting a supplier, validating the choice, and creating consensus inside the buying group. Buyers loop back between them. A plant manager can be halfway through supplier selection when finance asks for a different budget, and the group goes back to requirements.

For a manufacturer or distributor, the journey continues after the first order. A first order from a new account is often small. The value is in the next fifty orders, and those are won or lost in the portal, the ERP, and the account team long after the first sale.

The 6 stages of the B2B buyer journey

The six stages of the B2B buyer journey are problem definition, research and shortlist, evaluation by the buying group, validation, purchase and approval, and reorder. AI tools now do most of the work in the first two stages. Sales reps matter most in validation and in getting the purchase approved.

1. Problem definition

The journey starts when someone in the business names a problem, such as a packing line that keeps stopping or a new product that needs a component the current supplier doesn’t stock. Today that person often asks an AI assistant to explain the options before speaking to anyone.

Gartner found that reps are still the most important source of information when buyers define a business problem. That applies mostly to complex problems, where the buyer doesn’t yet know what to ask. Your website helps at this stage with content organized by problem and application, such as “how to cut changeover time on a filling line,” linked to the products that solve it.

2. Research and shortlist

Research has changed more than any other stage. Buyers ask ChatGPT, Gemini, or Google which suppliers make what they need, ship to their region, and hold the right certifications. The answer becomes the shortlist. 6sense found that 94% of buying groups rank their preferred vendors before first contact, and they buy from that favorite 77% of the time.

Suppliers get on that list through what AI tools and search engines can read: open product pages, full specs, coverage and certification details, and mentions on sites those tools trust. Our guide to B2B SEO in 2027 covers how to rank on Google and get recommended by AI for this stage.

3. Evaluation by the buying group

Once the shortlist exists, each member of the buying group checks the part they are responsible for. Engineering reads the datasheet. Quality checks the certifications. Finance compares total cost. Sustainability asks for material and origin data, which EU rules such as the digital product passport are turning into a requirement.

Each of them may run their own AI query, on their own schedule, and get a slightly different answer. A supplier whose data is complete and identical everywhere gives every member the same facts.

4. Validation

Validation is the stage where buyers bring in a person. Gartner found that 69% of B2B buyers prefer to validate AI-generated insights with a sales rep. The questions are specific: is this the current price for our account, can you deliver 400 units by the 15th, and is this part compatible with the pump we already run?

The rep wins this stage by answering quickly, with numbers that match what the buyer already saw. A rep who has to check three systems and call the warehouse gives the buyer a reason to doubt everything else.

Many industrial buyers start this stage by phone. Wainbee, an engineering systems distributor in Canada with 14 locations, has many customers who call or write before they buy. When we rebuilt its Google Ads account, we added tracking for phone calls and other contacts the customer starts, so the team could see which searches led to a conversation. In six months, contact form submissions grew 320% and phone calls 21%, while the cost per conversion fell 60.6%.

Read more: PPC Case Study: 320% More Leads in 6 Months with Less Costs

5. Purchase and approval

Procurement usually leads this stage. They want the quote, the contract price, the payment terms, and the PO process to work without surprises, and they compare the final offer against what the buyer saw online.

This is where a broken handoff costs the most. If the quote doesn’t match the web price, or the portal can’t take a PO with net terms, the buyer’s internal approval stalls. B2B platforms such as Adobe Commerce include company accounts with buyer roles, approval rules, and negotiable quotes for this stage. Our list of Adobe Commerce B2B features shows what comes built in.

6. Reorder and expansion

After the first order, the journey turns into a loop. Buyers want to reorder in a few clicks, see their contract prices, track deliveries, and download invoices without asking anyone. Some of those reorders will be placed by software: procurement systems, punchout, and, over time, AI agents using protocols such as the Universal Commerce Protocol.

The rep’s job here is the account. They spot the categories the customer buys elsewhere and bring them in. The first order is day 0 of the relationship, and most of the revenue comes after it.

Who is in the B2B buying group

A B2B buying group is everyone who shapes a purchase decision. Forrester’s 2026 State of Business Buying report puts the typical group at 13 internal stakeholders and nine external influencers, such as consultants, peers, and analysts. The number grows for complex or strategic purchases.

In an industrial purchase, the internal group usually includes engineering or maintenance, operations, quality, procurement, and finance, and sometimes sustainability and IT. Procurement carries real weight: Forrester found procurement professionals are decision-makers in 53% of business buying cycles.

Buyers also test before they commit. More than 60% of business buyers now use a trial, and 78% of those spending $10 million or more do. For a distributor, a trial often means a sample order, a pilot site, or a first small PO.

Every member of the group needs to find their answer without calling. Here is what each role usually checks:

• Engineering and maintenance: specs, drawings, compatibility, and substitutes.
• Quality: certifications, test reports, and standards.
• Procurement: contract prices, lead times, and the PO and invoice process.
• Finance: total cost, payment terms, and credit.
• Sustainability: material, origin, and carbon data.
• IT: punchout and integration with procurement systems and the ERP.

How AI changes B2B buying behavior

AI changes B2B buying behavior mainly at the research stage. In Gartner’s survey, 45% of buyers used generative AI in a recent purchase, mostly to research vendors and products, alongside an average of seven information sources. Buyers use it for speed, and they still check its answers with people.

Buyers also doubt AI and reps about equally. In the same survey, 51% said they are more likely to get misleading information from generative AI, and 49% said the same about sales reps. Buyers treat both as sources that can be wrong. They use AI because it is fast and available at 11 p.m., and reps because a rep can be held to an answer.

Forrester’s 2026 research found the same pattern: AI answer engines are now the starting point for business buyers, but they often deliver incomplete or unreliable information, so buyers look for validation from trusted sources.

For suppliers, that creates two jobs. Make sure the AI answer about you is right, by publishing complete and consistent product data. Then make sure the person the buyer calls can confirm it in one conversation. To see what AI tools say about you today, our guide to tracking brand mentions in LLMs shows a repeatable method, and our AI search optimization team runs the same check across hundreds of buyer prompts.

What the B2B sales rep does now

The B2B sales rep in 2027 mainly validates what buyers have already found and manages the account after the first order. Buyers come to the rep with research already done and ask them to confirm price, availability, and technical fit, to help win internal approval, and to finalize the order.

Gartner names four moments where reps remain the most important information source: defining the business problem, identifying a preferred supplier, securing internal support, and finalizing the purchase. Robert Blaisdell, VP Analyst at Gartner, warned sales leaders not to read the preference for digital self-service as “a signal that sellers matter less.” Gartner’s advice is to stop adding reps to every stage and bring them in where they add the most.

The validator job needs four things many B2B sellers don’t have yet:

• The customer’s view. The rep sees the same prices, stock, and order history the buyer sees in the portal.
• Live data. Stock and lead times come straight from the ERP during the call.
• One price logic. A rep’s quote uses the same contract price rules as the website.
• The research trail. The rep knows which products and pages the account viewed before calling, from the CRM and web analytics.

Macron, the teamwear and sportswear brand, solved the first of these on Adobe Commerce. Its “Shop as a Customer” feature lets Macron’s team log in under a partner’s account and help with bulk orders and complex configurations, using the prices and catalog that partner sees. Macron serves distributors, sports clubs, and retailers in more than 150 countries, and the platform is integrated with its SAP ERP. Order creation time fell 40%.

Read more: Case Study: Macron’s B2B Platform Evolution with Adobe Commerce

What suppliers must keep consistent across the journey

Suppliers must keep product data, prices, stock, lead times, and terms the same everywhere a buyer meets them: the website, AI answers, the rep’s quote, the portal, and the invoice. McKinsey’s 2026 B2B Pulse survey of nearly 4,000 decision-makers names inconsistent information as a leading reason buyers switch suppliers.

McKinsey also found that buyers use around ten channels during a purchase. Each channel is a chance for a different number. Most inconsistencies have the same cause: the fact is stored in more than one system, or typed by hand into a quote.

The fix is usually integration work. Connect the PIM and the ERP to the storefront, the rep tools, and the feeds AI tools read, so every channel reads from one source. Our guides to eCommerce ERP integration and PIM and eCommerce integration explain how to scope both.

Test for your team: ask ChatGPT for the lead time and price range of your three bestsellers, then ask a rep, then check the portal. Every answer that differs is a question a buyer will ask too.

How to map your B2B buyer journey

To map your B2B buyer journey, start from real deals. Interview recent customers, list the roles in each buying group, record which sources each role used at each stage, and mark where your website, AI answers, and reps gave different information. Then fix the stage where the most deals stall.

1. Pick ten recent deals, won and lost. Ask each customer how they found you, who was involved, and what made them get in touch.
2. Name the roles. Write down who in each buying group checked what, using the six stages above.
3. Ask AI what your buyers ask it. Run your buyers’ real questions in ChatGPT, Gemini, and Perplexity, and record whether you are named and whether the facts are right.
4. Trace each fact to its source. For price, stock, lead time, and specs, find the system it comes from on the website, in quotes, and on invoices.
5. Find where deals stall. CRM data on time in stage and lost reasons shows where the journey breaks.
6. Fix one stage at a time. Start with the stage that loses the most revenue, which is usually validation or reorder.

If you are deciding what to fund first next year, our guide to B2B eCommerce trends for 2027 covers which gaps to close first, and our B2B eCommerce solutions page shows how we approach the work after go-live.

FAQ about the B2B buyer journey

What are the stages of the B2B buyer journey?

The B2B buyer journey has six stages: problem definition, research and shortlist, evaluation by the buying group, validation, purchase and approval, and reorder. Buyers often loop back to an earlier stage when the group’s needs change. In 2027, AI tools handle much of the research and shortlist, and sales reps matter most at validation and approval.

Do B2B buyers still want to talk to sales reps?

Yes, at specific moments. Gartner found that 67% of B2B buyers prefer a rep-free experience, and 69% prefer to validate AI-generated insights with a sales rep. Buyers want to research and reorder on their own, then talk to a rep to confirm price, availability, and technical fit, and to get internal approval for larger orders.

How do B2B buyers use AI in the buying journey?

B2B buyers use AI mostly to research suppliers and products. In a 2026 Gartner survey, 45% had used generative AI in a recent purchase, alongside about seven other information sources. Buyers ask AI tools to explain options, name suppliers, and compare specs, then check the answers with a sales rep or the supplier’s website.

How many people are in a B2B buying group?

Forrester’s 2026 research puts the typical B2B buying decision at 13 internal stakeholders and nine external influencers, and the number grows for complex purchases. In manufacturing and distribution, the group usually includes engineering, operations, quality, procurement, and finance. Procurement professionals are decision-makers in 53% of buying cycles.

How is the B2B buyer journey different from B2C?

A B2B purchase involves a buying group instead of one shopper, longer evaluation, contract prices and payment terms, and procurement approval. It also continues after the first order through reorders. A B2C journey usually ends at checkout and depends on one person’s decision, while a B2B journey depends on many people agreeing on the same facts.

What does a B2B sales rep do?

A B2B sales rep helps business customers choose, buy, and reorder products. In 2027 that job is shifting toward validation: confirming the price, stock, and fit that buyers already researched online or with AI, helping them win internal approval, and growing the account after the first order. Reps need access to the same data the customer sees.

The B2B buyer journey in 2027 runs on one set of facts

The B2B buyer journey in 2027 starts with AI and search and ends with a rep, a quote, and a portal that the buyer comes back to. Buyers move between those sources freely and check one against another. Suppliers keep winning orders when their website, AI answers, reps, and invoices all show the same price, stock, and specs. Start by tracing where each of those facts comes from, then give your reps the same view of the account that the customer has.

Hearing "we already compared you in ChatGPT" from new buyers? Tell us where your deals stall today, and we'll show you which part of the journey to fix first.

The post The B2B Buyer Journey in 2027: How Buyers Use AI and Sales Reps appeared first on scandiweb.

If your store backend shows more orders than GA4 again this month, or if the Unassigned row in your traffic report keeps growing, you’re probably asking one question: is this a tracking problem, or are we really selling less?

GA4 unassigned traffic, (not set) values, and missing purchases usually point at the same few causes: consent, blocked tags, payment pages that send shoppers back as referrals, purchase events that fire twice or not at all, and bots. Below, we go through each cause and how to confirm it in your own reports. The guide ends with a monthly check that compares GA4 with your order database, so the next gap gets caught in weeks.

Is the gap between GA4 and your orders normal?

GA4 will never match your order database exactly, and it isn’t meant to. The backend records every paid order. GA4 records the purchases it was allowed to see and managed to receive. A stable gap is normal. A gap that suddenly grows, sits on one payment method, or comes with a jump in GA4 unassigned traffic usually means something in the tracking broke.

Gaps you should expect

Some orders never reach GA4 by design.

• Shoppers who decline analytics cookies, when consent mode blocks the Google tag
• Browsers and extensions that block requests to Google Analytics
• Phone, marketplace, and manually created orders that never pass through the website
• Orders completed on a payment provider’s page when the shopper never comes back to the confirmation page

Other differences come from how each system counts. GA4 reports in the property’s time zone, so orders placed near midnight can land on a different day than in the backend. Standard GA4 properties also keep processing data for 24–48 hours, so yesterday’s numbers may still change. And refunds or cancellations only reduce GA4 revenue if your store sends a refund event.

Signs the gap is a tracking problem

If the gap opened right after a replatform, start with tracking before you look at rankings. The traffic-drop triage in our SEO migration checklist puts the same check first.

What is unassigned traffic in GA4?

Unassigned traffic in GA4 is traffic that GA4 couldn’t place in any default channel. Google defines Unassigned as “the value Analytics uses when there are no other channel rules that match the event data.” It usually appears when a UTM source or medium doesn’t match any channel rule, or when events reach GA4 without the session or user details that attribution needs.

Direct is a separate channel with its own rule: the source has to be exactly “(direct)” with no medium. A session lands in Unassigned when GA4 got a source it couldn’t match to any rule, or got no usable source at all.

Common causes of GA4 unassigned traffic

The most common cause is campaign tagging. GA4 puts a session in Email only when the source or medium is “email”, “e-mail”, “e_mail” or “e mail”, so a link tagged utm_medium=newsletter matches no rule and lands in Unassigned. Medium values like “banner” or “influencer”, or a campaign name typed into the medium field, end up in the same place.

The other causes are technical.

• Purchase or lead events sent from your server through the Measurement Protocol, without the browser’s client ID and session ID, can’t be joined to a session
• Custom events that fire before the Google tag’s config command can’t be tied to a session properly, and Google lists this as a cause of both unassigned and (not set) values
• A cookie prefix that differs between pages, or a cross-domain linker that changes the client ID, splits one visit into short sessions that GA4 can’t attribute

How to fix unassigned traffic in GA4

Start by finding out what is inside the Unassigned row. In Reports, open Acquisition, then Traffic acquisition, and change the primary dimension to Session source / medium while filtering for Unassigned. Each row points to a cause.

1. Readable source and medium values, such as “klaviyo / newsletter”, mean your UTM naming doesn’t match GA4’s rules. Agree a naming convention with the marketing team and fix the links at the source. A custom channel group can relabel these sessions in reports, but the links stay wrong until someone retags them.
2. “(not set) / (not set)” usually means missing session data. Check that the Google tag fires first, on the Initialization trigger in Google Tag Manager, before any event tags.
3. Unassigned traffic that rises around purchase or lead events usually comes from server-side events. Send the client ID and session ID with every Measurement Protocol event.

What does (not set) mean in GA4?

(not set) in GA4 means a dimension had no value: GA4 received the data without a piece of information it expected. The same label appears in many reports, and the cause depends on which dimension shows it, so check the dimension before changing any tags.

• In Session source / medium, (not set) means the session has no session_start event, and Google’s fix is to fire the Google tag on the “Initialization – All pages” trigger in Google Tag Manager
• In Landing page, it means the session has no page_view event, which happens when a session starts with another event, such as a purchase sent from a server
• In Google Ads dimensions, it means the Ads account isn’t linked to GA4 or auto-tagging is off
• In a newly registered custom parameter, it can show for the first 24 hours

Consent settings can also cause (not set). Google notes that calling the consent default command again when a shopper changes their choice, instead of the update command, can drop the session_start event. Sending events marked as denied after the shopper has accepted cookies does the same. If your consent banner went live around the time (not set) appeared, check how it sends consent changes. Our guide to Google Consent Mode v2 covers the setup itself.

Why GA4 is missing transactions

When GA4 shows fewer purchases than your backend, the cause is usually one of three things: the shopper didn’t come back from the payment page, consent or a blocker stopped the tag, or the purchase event fired wrongly. Check them in that order, because the first one leaves the clearest trace in your reports.

Payment redirects and self-referrals

Many payment flows send the shopper away from your store: PayPal, Klarna, bank transfer pages, or a bank’s 3-D Secure check. Two things can go wrong.

The shopper pays but closes the tab before the confirmation page loads, so the purchase event never fires. The order exists in the backend and is missing from GA4.

Or the shopper returns, and GA4 treats the payment domain as a new referral. The purchase then gets credited to paypal.com instead of the ad or email that brought the shopper in. To stop that, add every payment and 3-D Secure domain to the unwanted referrals list in the GA4 data stream settings. GA4 allows up to 50 conditions per stream. The list only works going forward, so sessions already credited to those domains stay as they are.

For the orders that never reach the confirmation page, the only full fix is to send the purchase from your server when the order is created, through the Measurement Protocol, with the shopper’s client ID and session ID attached. Without those IDs, the purchase shows up in GA4 as unassigned.

Consent, ad blockers, and short cookies

Shoppers who decline analytics cookies, or browse with a blocker, don’t send observed purchases to GA4. That gap is real and permanent. With advanced consent mode, GA4 can model some of the missing behavior, but only once the property passes Google’s thresholds: at least 1,000 events a day with analytics consent denied for 7 days, and at least 1,000 daily users who accepted on 7 of the last 28 days. Smaller stores often never qualify.

Safari also limits cookies set by JavaScript to seven days. A shopper who comes back after two weeks looks like a new user, and the earlier campaign gets no credit for the sale. The order still reaches GA4, but the campaign that won it shows up as Direct.

How much consent costs you depends on your markets and your banner. Compare the gap for EU countries with the gap for countries where you don’t show a banner, and you’ll see the size of it. The consent mode guide explains the basic and advanced options.

Purchase events that fire twice or not at all

GA4 removes duplicate purchases when they share the same transaction ID, but only for the same user and only on web data streams. That covers most confirmation page reloads. These four problems get through anyway.

• An empty transaction ID: Google says GA4 deduplicates every purchase sent with transaction_id=””, so they collapse into one and you undercount
• Two tags for one purchase, such as a platform app and a Google Tag Manager tag, where only one of them sends the transaction ID
• A cart ID or quote ID sent in place of the order number, which makes different orders look like duplicates
• A purchase tag that fires on page load before the order data is in the dataLayer, so it sends no value or no items

Test this with real orders. Place orders with each payment method in GA4’s DebugView and compare the transaction ID, value, and currency with the backend. Our guide to dataLayer QA covers the checks for each eCommerce event.

How to spot and filter bot traffic in GA4

GA4 removes traffic from known bots and spiders automatically, using Google’s research and the IAB’s International Spiders and Bots List. You can’t turn this off, and you can’t see how much it removed. Bots that aren’t on the list still get through, and they often appear as sudden spikes in Direct, Unassigned, or Referral traffic.

GA4 bot traffic usually follows a pattern you can see in an exploration.

• A spike in sessions with no matching rise in orders or add-to-carts
• Average engagement time close to zero and an engagement rate far below normal
• Most sessions from one city, often near a data center, or from one unusual screen resolution
• One landing page, or a hostname that isn’t your store

Once you’ve confirmed a spike, you have three options. For reporting, build a segment or a report filter that excludes the pattern, which hides it without deleting anything. For future data, GA4’s data filters cover internal traffic, developer traffic, and traffic from other hostnames. Those filters are permanent and only apply from the day you activate them, so test them on a copy of the report first. For the bots themselves, block them at your CDN or firewall, before they reach the store.

Bots don’t only inflate traffic. Card-testing bots also create real failed or fraudulent orders in your backend, which makes the GA4 gap look worse than it is. Our guide to Magento fraud prevention explains how to spot card testing.

A monthly GA4 reconciliation routine

A monthly reconciliation compares GA4 with your order database on the same terms, so you know your normal gap and spot a new one within weeks. Once the exports are scheduled, it’s a short monthly job.

1. Export last month’s paid orders from the backend, without test orders, and with the order number, payment method, country, and total
2. Export GA4 purchases for the same month with transaction ID, payment method if you send it, country, and purchase revenue
3. Set both exports to the same time zone and currency before comparing
4. Calculate the capture rate: GA4 purchases divided by backend orders
5. Match transaction IDs to order numbers and list the missing orders by payment method and country
6. Check for transaction IDs that appear more than once in GA4
7. Record the share of Unassigned and (not set) sessions, and note any traffic spikes
8. Compare everything with the last three months, next to a log of site releases and changes to the consent banner or payment methods

On Magento, the order export can be scheduled, so step 1 runs on its own. Our guide to exporting orders in Magento 2 shows the options.

When the capture rate moves by more than a few points from its three-month average, treat it as a tracking incident first. Most of the time, the cause is in the release log from the same week.

Frequently asked questions about GA4 unassigned traffic

Why is GA4 showing unassigned traffic?

GA4 shows unassigned traffic when it can’t match a session’s source and medium to any default channel rule. The most common cause is UTM tagging that doesn’t follow GA4’s naming, such as utm_medium=newsletter instead of email. Server-side events without a client ID and session ID, and tags that fire before the Google tag’s config command, also create unassigned sessions.

What does (not set) mean in Google Analytics 4?

(not set) means GA4 received data without a value for that dimension. For session source / medium, the session is missing its session_start event. For landing page, the session has no page_view event. For Google Ads dimensions, the Ads account isn’t linked. The fix depends on the dimension, so check which report shows it before changing tags.

Why doesn’t GA4 revenue match Shopify or Magento?

GA4 revenue rarely matches Shopify or Magento because the store records every paid order, while GA4 only records purchases it is allowed to see. Declined consent, blocked tags, shoppers who don’t return from payment pages, time zone differences, and refunds that aren’t sent to GA4 all widen the gap. A stable gap is normal, and a sudden change points to a tracking fault.

Does GA4 filter bot traffic automatically?

Yes, GA4 automatically excludes known bots and spiders using Google’s research and the IAB International Spiders and Bots List. You can’t turn it off or see how much traffic it removed. Bots that aren’t on the list still get through, so spikes with near-zero engagement time need a segment, a data filter, or blocking at your CDN or firewall.

How do I stop PayPal from showing as a referral in GA4?

Add paypal.com, and every other payment or 3-D Secure domain your checkout uses, to the unwanted referrals list in your GA4 web data stream settings. GA4 then ignores those domains as traffic sources when shoppers return to your store. The change only applies to new data, so sessions already credited to PayPal stay in past reports.

How much difference between GA4 and backend orders is normal?

There is no single normal figure, because it depends on your markets, consent banner, and payment methods. Stores that show a consent banner to EU shoppers can expect a bigger gap than stores without one. What matters is that the gap stays stable from month to month. Track the capture rate each month and investigate when it moves by more than a few points.

Tracking problem or real drop: how to tell

GA4 unassigned traffic, (not set) values, and missing orders are almost always tracking questions before they are sales questions. Check the gap against your own baseline, look inside the Unassigned row, follow the missing orders by payment method, and filter out bots before anyone cuts a budget. If the capture rate holds steady while orders fall in both systems, the drop is real, and the conversation can move on to demand and pricing.

Not sure whether your GA4 gap is tracking or real? Send us your last month's numbers, and we'll show you where the orders go missing.

The post Why GA4 Doesn’t Match Your Orders: Unassigned Traffic, (not set), and Missing Sales appeared first on scandiweb.

If your support invoice came in higher this month and nothing new went live, or if you’re about to sign a retainer and can’t tell whether 40 hours is too many, the answer to your website maintenance cost question is in the hours. You scroll down the invoice: an emergency security patch, a payment extension that broke after an update, a Saturday call about checkout errors, and six lines called “minor changes.” Each line looks reasonable. The total doesn’t.

Most price guides won’t help much, because they’re written for brochure sites and add up domains, hosting, and SSL certificates. For an online store, those are rounding errors. This guide follows the hours instead: where they go, which ones belong in a retainer, what 24/7 cover adds, and how to check them on an invoice.

How much does website maintenance cost for an online store?

Website maintenance cost for an online store runs from a few hundred dollars a month for a small store on a hosted platform to several thousand dollars a month for a custom or self-hosted store, and more for enterprise stores with 24/7 cover. Published guides from GoDaddy, Network Solutions, and Hostinger put eCommerce sites between $300 and $5,000 a month. Most of that bill is developer time.

Treat these as signposts. None of the vendor guides explains its method, and each one mixes hosting, content writing, and development into the same total. A better way to estimate your own number is to count hours.

A support retainer is mostly developer, DevOps, and QA time. Network Solutions puts technical support at $50 to $200 an hour. The examples below use a round $100 an hour, and the hours are there to show the arithmetic, not as benchmarks:

Swap in your agency’s rate and your real hours, and you have a number you can defend in a budget meeting. Our Magento pricing guide shows how maintenance fits into total cost of ownership over five years.

What drives the monthly number

Five things set the monthly number for eCommerce website maintenance: security patching and platform upgrades, monitoring and hosting operations, incident response, small features and fixes, and the extensions and integrations that break when anything else changes. Hosting, domain, and SSL are a small share for most online stores. The platform matters most, because a self-hosted Magento store carries its own patching, while Shopify runs hosting and core updates.

Security patching and platform upgrades

On a self-hosted platform, patching is the line that never goes away. Adobe releases security patches for every supported Magento (Adobe Commerce) release line at least once a year, plus isolated security fixes in between, and you can only apply those if you’re already on the latest security-only patch. Each one has to be applied, regression-tested, and deployed. Stores that fall behind pay twice: first to catch up, then to patch.

Every release line also has an end date. Regular support for 2.4.6 ended on August 11, 2026, and 2.4.7 follows on May 31, 2027, according to Adobe’s released versions page. For many stores, an upgrade belongs in next year’s maintenance budget. Our Magento 2 upgrade process breakdown shows what that work involves.

If your store is in scope for PCI DSS, requirement 6.3.3 also expects critical security patches to be installed within one month of release. That deadline turns patching from “when we get to it” into a monthly commitment.

Monitoring and hosting operations

This line covers uptime checks, error logs, server load, cron and queue health, backups, and certificate renewals. Most of it is automated, so the cost is in setting up alerts that matter and acting on them. On Shopify the line is small, because Shopify runs hosting and core updates and completes its own annual PCI DSS assessment. On self-hosted Magento or a headless build, someone has to own the servers, the CDN, and the deployment pipeline, and that someone bills hours.

Incident response

Incidents are the least predictable line. A payment provider changes an API, a cache fills up during a sale, or a critical vulnerability gets exploited before most stores have patched. In September 2026, Adobe released an emergency hotfix for StyleSmuggler, a Magento flaw with a CVSS score of 10.0 that attackers were already using. Stores had to apply the hotfix, check for signs of compromise, and rotate their credentials. Our StyleSmuggler patch guide covers what that took. Weeks like that one are why a retainer needs a stated rate for unplanned work.

Small features and fixes

This is where hours drift. Marketing wants a new banner slot before the weekend, and operations needs a shipping rule changed for one region. Each request is small, so it rarely gets a formal estimate, and twenty of them add up to a week of developer time. Small improvements are a good use of a retainer, as long as someone approves them against a monthly budget.

Extensions and integrations

Every extension, app, and integration is another thing to update and another way for an update to break checkout. ERP, PIM, payment, search, and shipping connections can fail without an error on the storefront: stock stops syncing, and nobody notices until orders oversell. On any platform, a store with 60 extensions and four integrations costs more to maintain than a store with 15 and one. A Magento code audit is a practical way to find the extensions you can remove.

What a support retainer should include

A support retainer, or website maintenance plan, should include security patching on a stated cadence, uptime and error monitoring, a defined response time for each priority level, bug fixes, minor updates to extensions and integrations, and a set number of hours for small improvements. New features, redesigns, major version upgrades, and third-party license fees usually sit outside it and are quoted separately.

The line between a bug and a change request is behind a lot of billing disputes. Agree in writing that a bug is existing functionality that stopped working as specified, and that everything else is a change. Then ask how the agency handles a fix that turns out to need new code.

Hosting is the other gray area. If the agency runs your infrastructure, the retainer should say who answers when the server goes down at night: the agency or the host.

Our Magento support is built this way: monitoring, patching, bug fixes, performance work, version upgrades, and new features, with scope and cost approved before any work starts.

Support SLA tiers and when 24/7 cover is worth it

A support SLA sets how fast the agency responds to each priority level, usually from under an hour for a site-down P1 incident to one or more business days for a minor request. 24/7 cover is worth paying for when an hour of downtime costs more than the monthly premium, when traffic peaks outside office hours, or when you sell across several time zones.

Agencies call these priority or incident severity levels, and there is no industry standard for their response times. The example below shows one common structure that you can use as a starting point when you negotiate.

Response time vs resolution time

Most SLAs promise a response time, meaning how fast a person acknowledges the ticket. Fewer promise resolution, because a fix can depend on a payment provider or a hosting company. Ask for a third number: time to workaround for P1 incidents, such as switching off a broken extension or rolling back a release. That’s the number that stops the revenue loss.

When 24/7 website support pays for itself

Start with uptime. In a 30-day month, 99.5% uptime allows 3.6 hours of downtime, 99.9% allows 43 minutes, and 99.99% allows just over 4 minutes. An uptime promise means little if the people who fix problems only work office hours.

Then work out what an hour offline costs. A store that sells $20 million a year online averages about $2,300 an hour, and far more during a sale. With office-hours support only, an outage that starts at 7 p.m. on a Friday can wait more than 60 hours for a developer.

24/7 cover is usually worth it when:

• An hour of downtime at peak costs more than the monthly premium for on-call cover
• A large share of your orders come in during evenings and weekends
• You sell across time zones, so your busy hours fall outside one office’s working day
• You run your own infrastructure, so no hosting provider watches the servers for you
• You run launches, drops, or sales events outside office hours

It’s harder to justify for a small Shopify store with steady daytime traffic, where Shopify already watches the platform. A middle option is 24/7 cover for P1 incidents only, with everything else handled in office hours.

How support hours are tracked and billed

Most eCommerce support is billed as hours. Pay-as-you-go bills each approved task, a retainer prepays a block of hours each month, and a dedicated team bills fixed capacity. Ask for a time log per ticket with the date, person, category, and minutes, so you can see whether the hours went to incidents, maintenance, or new work.

The billing increment matters more than it looks. Thirty five-minute fixes come to 7.5 hours when an agency bills in 15-minute increments, and 30 hours when it rounds every ticket up to a full hour.

How to read a support invoice

A good invoice can be read without calling the account manager. Look for these lines:

1. Base fee or prepaid hours, and how many of them were used
2. Hours per ticket, with the ticket number, date, person, and category (incident, maintenance, or change request)
3. Out-of-hours work, shown separately with its rate
4. Project management and QA time, inside each ticket or as its own line with a stated share
5. Pass-through costs, such as extension licenses, hosting, or third-party services
6. Hours carried over or expired at the end of the month

If a line says “general maintenance, 12 hours” with no tickets behind it, ask for the log.

Why this month’s bill is higher

When a support bill jumps, the cause is usually one of these:

• An emergency security patch outside the normal cadence, such as the PHP2Shell update in October 2026
• An out-of-hours incident billed at a higher rate
• A run of small change requests before a marketing campaign
• An extension or platform update that broke something and needed regression testing
• Pre-peak work, such as load testing, code freezes, and extra monitoring before Black Friday
• Fixes on a version close to end of support, where every change also needs a compatibility check

Ask your agency to tag every hour with a category. After three months, you’ll know your baseline, and a higher bill becomes a conversation about one category instead of the whole invoice.

Red flags in a support contract

Read the contract with these questions in hand. Each “no” is worth a conversation before you sign. If you’re still comparing providers, our overview of Magento support and maintenance companies covers the selection side.

1. Does the SLA define priority levels, and can you set the priority? If only the agency decides what counts as P1, the response time promise means little.
2. Is there a workaround or resolution target for P1? A 15-minute acknowledgment followed by a six-hour fix still costs six hours of sales.
3. Does “24/7” mean a person on call? Some contracts mean round-the-clock ticket intake, with someone reading the queue the next morning. Ask who answers at 3 a.m. and how.
4. Is the patching cadence written down? “Patches applied as needed” leaves the decision to whoever has spare time.
5. What happens to unused hours? Expiring hours are normal in some retainers, but you should know the rule before the first month ends.
6. What are the billing increment and the overage rate? Rounding each ticket up to an hour, or an overage rate far above the base rate, can move the monthly cost more than the headline price.
7. Do you get a time log per ticket? Without one, you can’t check an invoice.
8. Do you own your code, repositories, and hosting accounts? If the agency holds the only access, switching providers turns into a negotiation. The contract should cover handover.
9. How long is the notice period? A 12-month term with automatic renewal and 90 days’ notice can keep you paying long after the relationship stops working.

Frequently asked questions about website maintenance cost

How much does website maintenance cost per month?

For an online store, published guides put website maintenance cost between about $300 and $5,000 a month, and enterprise stores go well past that. The real number depends on developer hours. At $100 an hour, a store that needs 10 hours a month pays about $1,000, and one that needs 40 hours pays about $4,000, plus any 24/7 premium.

Do websites need monthly maintenance?

Online stores do. Security patches, extension updates, monitoring alerts, and broken integrations come up every month, and every hour a checkout or payment issue stays open costs orders. A brochure site can get by with occasional updates, but a store that takes payments needs continuous monitoring and patching on a schedule.

Is Shopify cheaper to maintain than Magento?

Usually, for the platform itself. Shopify runs hosting, core updates, and its own PCI DSS assessment, so maintenance is mostly apps, theme, and integrations. Self-hosted Magento (Adobe Commerce) adds patching, upgrades, and infrastructure. The gap narrows for complex stores, where custom apps, integrations, and Shopify Plus fees carry their own costs.

How many support hours does an online store need?

There’s no standard number, so measure it. Count the hours from the last three to six months of tickets, split them into incidents, maintenance, and changes, and size the retainer on the maintenance baseline plus a buffer for incidents. Keep feature work in a separate budget, so it doesn’t eat the hours you need for patches.

What is a good SLA response time for eCommerce?

For a site-down or checkout failure, look for a first response within an hour, around the clock if your store sells at night or on weekends. Lower priorities usually get a response within a few business hours to a business day. Ask for a workaround target for critical incidents too, because a quick acknowledgment doesn’t restore sales.

Do unused retainer hours roll over?

It depends on the contract. Some retainers let unused hours roll into the next month, often with a cap or an expiry date, and others reset every month. Pay-as-you-go billing avoids the question, because you only pay for the hours used. Whatever the model, get the rule in writing before you sign.

What to check before you sign or renew

Website maintenance cost for an online store comes down to hours: how many your store needs for patching, monitoring, incidents, and small changes, and what each one costs. Pull the last three months of invoices, tag the hours by category, and check them against the scope and SLA you need. If the numbers still don’t add up, have that conversation with your agency before the renewal date.

At scandiweb, 450+ active clients use our support, and we’ve handled 9,000+ tickets on a pay-as-you-go model where you approve the scope and cost of each task before work starts.

Want a second opinion on your support contract? Tell us what you're paying for, and we'll show you which hours your store needs.

The post eCommerce Website Maintenance Cost: What a Support Retainer Should Include appeared first on scandiweb.

Stores that ask us about Klaviyo vs Mailchimp have usually felt the gap already: the abandoned-cart flow that was never built, or the second store view that never synced. Most of them want to know two things. Is the move worth the migration work, and if the store keeps growing, is Bloomreach the next stop or an expensive detour?

The answer turns on how much store data you have and how much of it you will put to work. List size mostly changes the bill.

Klaviyo vs Mailchimp: the short answer

Klaviyo is the better fit for most eCommerce stores because it is built around store data: orders and browsing events from Shopify or Magento (Adobe Commerce) feed every segment and flow. Mailchimp is cheaper at the entry level and simpler for newsletter-led marketing, but its flows and audiences are capped by plan. Bloomreach fits large, multi-market retailers that want one customer profile behind email, on-site personalization, search, and ad audiences.

Klaviyo vs Mailchimp pricing as your list grows

Mailchimp’s paid plans start lower: Essentials from $13 a month and Standard from $20 a month for 500 contacts, against $20 a month for Klaviyo’s Email plan at 251–500 active profiles. The comparison changes as lists grow because the two count people differently. Klaviyo bills active profiles, the contacts who can still receive marketing. Mailchimp’s bill includes unsubscribed contacts until you archive them.

Both prices rise with your list, so run your own count through each calculator. Two billing rules matter more than the entry price:

• Klaviyo counts only contacts who can receive marketing. Mailchimp counts subscribed, unsubscribed, and non-subscribed contacts, and only archived, cleaned, or deleted contacts drop off the bill.
• Mailchimp bills overages automatically after the trial and keeps sending, with a monthly send allowance of 10x your contact limit on Essentials, 12x on Standard, and 15x on Premium. Klaviyo moves a paid account to the plan that matches its active profile count.

Magento (Adobe Commerce) and Shopify integrations

On both platforms, Klaviyo has the deeper integration. Its Magento extension and Shopify app send orders, checkouts, and product views as events you can trigger flows on, and Shopify names Klaviyo its preferred email partner for Shopify Plus. Mailchimp connects to both platforms too, but on Magento each store view links to its own audience, and the number of audiences depends on your plan.

Magento (Adobe Commerce)

Klaviyo’s extension installs from the Adobe Commerce Marketplace. According to Klaviyo’s Magento guide, the native integration tracks Placed Order, Fulfilled Order, Canceled Order, Refunded Order, and Started Checkout, and the extension adds Active on Site and Viewed Product. A headless storefront needs Klaviyo.js added by hand. Anything outside that list, such as a canceled payment, is custom development.

Mailchimp for Adobe Commerce is a free connector that syncs customers and orders to an audience. The catch for multi-store setups is that each store view connects to its own audience. A store with four store views needs four audiences, which rules out Free (1 audience) and Essentials (3). Most sync failures come from leftover MageMonkey data or orphan stores, and our Mailchimp Magento integration guide covers the fixes.

Shopify

Klaviyo and Shopify announced a strategic partnership in August 2022: Klaviyo became the recommended email solution for Shopify Plus, and Shopify invested in Klaviyo. Mailchimp’s official Shopify app, built by Intuit Mailchimp, syncs customers and purchase data as well.

On Shopify, the integration gap is smaller than on Magento, and the tools differ more in what they let you do with the data in flows and segments. If you need flows on custom events, the Shopify Klaviyo integration is where we start.

Flows, segmentation and deliverability

Klaviyo includes automation flows and segments on every plan, Free included, and any segment can use the store’s order and browsing data. Mailchimp limits flows by plan: up to 4 steps on Essentials and up to 200 flows on Standard and Premium, which is also where predictive segments start. Deliverability depends mostly on your own setup, and Gmail’s sender rules apply to both tools in the same way.

Flows

The flows that earn most store email revenue are triggered by behavior: welcome, browse abandonment, abandoned checkout, post-purchase, and win-back. A 4-step cap is tight for an abandoned-checkout series that splits first-time and returning buyers. Our guide to shopping cart abandonment solutions covers what goes into those emails.

Segmentation and predictive data

Klaviyo segments update in real time on any event or property the store sends. Its predictive analytics, such as predicted lifetime value and expected next order date, need at least 500 customers who have placed orders, 180 days of order history, and orders in the last 30 days, according to Klaviyo’s help center. Below that point, predictions stay blank and you segment on rules you write yourself. Mailchimp keeps predictive segments for Standard and Premium.

Deliverability

Neither tool gets you into the inbox on its own. Since February 2024, Google has required anyone sending more than 5,000 messages a day to Gmail to authenticate with SPF, DKIM, and DMARC, offer one-click unsubscribe, and keep the spam rate in Postmaster Tools below 0.30%. Both tools support an authenticated sending domain. After that, inbox placement depends on mailing people who open and click, which our email marketing best practices cover in detail.

Should you move from Mailchimp to Klaviyo?

Move from Mailchimp to Klaviyo when email should earn revenue from store behavior: abandoned checkouts, browse abandonment, replenishment and win-back flows, and segments built on orders. Stay on Mailchimp if most of your email is newsletters and announcements and your list is small. The entry price is lower, and the flows you would gain have little data to run on.

These signs usually mean the move is due:

• You run several store views or languages and work around Mailchimp’s audience limits.
• A flow you need is blocked by a step limit or a plan level.
• You build segments from CSV exports instead of from purchase data.
• You can’t tell which flow earned which order.

Flows and templates don’t transfer between the tools. A migration means importing audiences with their custom properties, rebuilding every flow, authenticating the sending domain, and moving transactional emails. We did this for a cycling brand whose Mailchimp setup couldn’t handle multistore, multilanguage sending or abandoned-cart, birthday, and review flows. We imported the audiences with custom properties, built metrics the standard Magento integration didn’t track, verified DMARC, and launched the flows in several languages. Email-attributed revenue grew 4.8x YoY.

Read more: Email Marketing Revenue Increased by 4.8x After Klaviyo Migration

Bloomreach vs Klaviyo: when stepping up is worth it

Bloomreach is worth it when email is one of several channels that should share a single customer profile, and your traffic is large enough to pay for it. Bloomreach’s own pricing page says most brands start at $60K or more a year and that its smaller customers serve 500K+ monthly visitors. Below that scale, Klaviyo usually covers the email and SMS work most stores need.

The step up makes sense when most of these are true:

• You sell in several markets with separate store views, languages, and consent rules.
• Customer data comes from POS and ERP systems as well as the online store.
• You want the same segments in email, on-site personalization, search, and ad audiences.
• You have a team or partner to run it. Bloomreach itself says it isn’t for brands still building an audience or looking for a lightweight email platform.

The biggest sportswear retailer in the Baltics made this move from Klaviyo. With separate store views per market and customer data split across systems, we helped them compare CDPs, and once Bloomreach was chosen, we rebuilt their flows on it. Automated flows now generate 39% of their email revenue from 3% of sends. Twelve months after launch, email orders were up 20.6% and ROAS on paid media was up 39.1%.

Read more: CDP Case Study: Multi-Market Personalization for the Biggest Baltics Sportswear Retailer

If you are weighing the same move, our guide to customer data platforms explains what a CDP adds over an email tool. We build both the Magento Bloomreach integration and the Shopify Bloomreach integration.

How to choose between Klaviyo, Mailchimp and Bloomreach

For most eCommerce stores, Klaviyo is the default: it uses store data in every flow and segment and grows with the list. Mailchimp is the right call for small, newsletter-led stores that want the lowest entry price. Bloomreach is for retailers with several markets, large traffic, and a team ready to run one customer profile across email, website, and search.

Choose Klaviyo if:

• You sell on Shopify or Magento (Adobe Commerce) and want flows triggered by orders, checkouts, and product views.
• You have, or will soon have, 500+ paying customers and want predictive segments.
• You run several store views and don’t want one audience per view.
• You expect most email revenue to come from automated flows.

Choose Mailchimp if:

• Most of your email is newsletters, announcements, and promotions.
• Your list is under a few thousand contacts and the entry price matters most.
• You run one store view or one Shopify store.
• You send a few campaigns a month and rarely use automation.

Choose Bloomreach if:

• Your site serves hundreds of thousands of visitors a month across several markets.
• Customer data lives in POS and ERP systems as well as the store.
• You want one profile behind email, on-site personalization, search, and ads.
• You have people to run it day to day.

Frequently asked questions about Klaviyo vs Mailchimp

Is Klaviyo better than Mailchimp for eCommerce?

For most online stores, yes. Klaviyo syncs orders, checkouts, and product views from Shopify and Magento and uses them in every flow and segment, on every plan. Mailchimp is simpler and cheaper to start and works well for newsletter-led email, but flows and predictive segments depend on your plan, and on Magento each store view needs its own audience.

Can you migrate from Mailchimp to Klaviyo without losing subscribers?

Yes, if you plan it. Export each Mailchimp audience with consent status and custom properties, import them into Klaviyo, and keep unsubscribes suppressed. Flows and templates have to be rebuilt. Authenticate your sending domain before the first campaign and start with your most active contacts to protect deliverability.

Does Mailchimp work with Magento 2?

Yes. Mailchimp for Adobe Commerce is a free connector that syncs customers and orders to a Mailchimp audience. Each store view connects to its own audience, so multi-store setups may need a higher plan. Leftover MageMonkey data and orphan stores cause most sync failures.

What are the weaknesses of Klaviyo?

Cost and scope. The bill grows with active profiles, so large lists get expensive. Klaviyo is built for email and SMS, so data from POS, ERP, or support tools needs extra work or its paid data platform. On Magento, events beyond the standard set need custom development.

How much does Bloomreach cost?

Bloomreach doesn’t publish a rate card. Pricing combines a platform fee with a usage fee based on audience and catalog size, the products you turn on, and the volume you run. Its pricing page says most brands start at $60K or more a year, and its smaller customers serve 500K+ monthly visitors.

Klaviyo vs Mailchimp: choose the tool your data can feed

In Klaviyo vs Mailchimp, the store data you plan to use decides the winner. If your store sends orders and browsing events and you want email to earn from them, Klaviyo is the better tool on both Shopify and Magento. If you mostly send newsletters to a small list, Mailchimp costs less and does the job. Bloomreach is worth it once several markets and channels need one customer profile. Our email marketing services cover the move and the flow build for any of the three.

Weighing a move off Mailchimp, or wondering whether Bloomreach fits your size? Tell us about your setup, and we'll tell you which tool your data can support.

The post Klaviyo vs Mailchimp for eCommerce, and When Bloomreach Is Worth It appeared first on scandiweb.

If you’ve just forwarded a Search Console email to your developer asking “is this bad?”, or you’re looking at thousands of URLs marked “Duplicate without user-selected canonical”, you probably want one answer: is any of it costing the store sales?

On most online stores, the answer is no. Google’s own help page says that not indexed “is not necessarily bad”, and a store creates far more URLs than it wants in search: color variants, sorted and filtered categories, tracking parameters, cart and account pages. This guide goes through the statuses that stores see most, with a store example for each, a verdict on whether to act, and the fix when you should.

What the Page indexing report is telling you

The Page indexing report in Google Search Console lists every URL Google knows on your site and sorts the ones it didn’t index by reason. Google’s stated goal is to get the canonical version of every important page indexed, and it says you should not expect all URLs on your site to be indexed. So the useful question for each status is whether the URLs in it are pages you want customers to find.

Start with two numbers before reading any status. Compare the count of indexed pages with the number of products and categories you actually sell, then check whether the indexed count dropped recently. A store with 4,000 products and 400 categories that has 4,600 pages indexed is in decent shape, whatever the not indexed column says.

Duplicate without user-selected canonical on an online store

“Duplicate without user-selected canonical” means Google found a page that is a duplicate of another page, the page has no canonical tag saying which version you prefer, and Google picked a different URL to index. Google says this is not an error and is working as intended, because it doesn’t show duplicate pages in search. On a store, it mostly collects parameter URLs for variants and sort orders.

Google groups pages by how similar their content is. Every URL in the group except the one it chose as canonical lands in this status, so a big count often just means your store generates a lot of URL versions of the same page.

Product variants and color URLs

Many platforms and themes create a URL per variant, such as /rain-jacket?color=blue or /rain-jacket?size=m. If the only difference is the selected swatch, Google treats those URLs as copies of the main product page and indexes one of them. That is usually fine, as long as the URL it keeps is the clean product URL.

It becomes a choice when the variants are different enough to earn their own searches. A sofa sold in eight fabrics may deserve separate pages for “green velvet sofa”, while a T-shirt in five sizes doesn’t. Decide per product type, then make the canonical tags follow that decision.

Sorted, filtered, and tracking URLs

Sorting a category by price, showing 48 products per page, or arriving from a newsletter link with a utm_source tag adds a parameter to the URL while the products shown stay the same. Google’s own documentation uses a category URL with a gclid ad parameter as its example of a duplicate. These URLs belong in this status.

Filters are different, because some filter pages match real searches. If “black leather boots” brings in buyers through a filter URL, that page needs its own canonical and a place in your internal links. Our guide to layered navigation explains how to choose which filter pages stay indexable.

Products assigned to several categories

On Magento (Adobe Commerce) in particular, a product that sits in three categories can be reachable at three category paths, such as /men/jackets/rain-jacket and /sale/rain-jacket. Without a canonical tag, Google picks one of them. Platform settings can add a canonical tag to product pages or drop category paths from product URLs entirely, and either one keeps the count down. The duplicate content guide covers the other sources of duplication on stores, from trailing slashes to manufacturer descriptions.

When this status is a problem

Look at the example URLs in the status and filter for the ones you care about. It’s a problem in two cases. Your main product or category URL appears in the list, which means Google indexed a parameter or variant URL instead of it. Or the same content is indexed under the HTTP and HTTPS, or www and non-www, versions of your domain, which points to a redirect gap our guide to HTTP and WWW in URLs explains.

How to fix it

1. Inspect one affected URL with the URL Inspection tool and read the “Google-selected canonical” line
2. If Google chose the right page, leave it, because the status is working as intended
3. If Google chose the wrong page, add a self-referencing canonical tag to the page you want indexed and point the duplicates at it
4. Link to the canonical URL in menus, breadcrumbs, and product grids, so internal links stop pointing at parameter versions
5. List only canonical URLs in your XML sitemap

Google treats redirects and canonical tags as strong signals and sitemaps as a weak one, so the canonical tag and internal links do most of the work. Google also advises against using robots.txt or noindex to handle duplicates. A blocked duplicate can still be indexed without its content, and noindex removes the page from search altogether. For stores with several countries or languages, each version needs its own canonical and matching hreflang, which our hreflang and canonical guide walks through.

Duplicate, Google chose different canonical than user

This sister status means you did set a canonical tag, and Google indexed a different URL anyway. It is worth more of your time, because a tag that Google overrules usually points to a mixed signal: the canonical says one URL, while internal links, the sitemap, or redirects point to another. Inspect the URL, compare the “User-declared canonical” with the “Google-selected canonical”, and make every signal point the same way. If two categories really have the same products, merging them is often the cleaner fix.

Crawled – currently not indexed

“Crawled – currently not indexed” means Googlebot fetched and read the page, then decided not to add it to the index for now. Google says the page may or may not be indexed in the future and that there’s no need to resubmit it. On a store, this status usually collects thin or near-identical pages.

Google doesn’t give a reason per URL, so read the list for patterns. In store audits, the same groups come up again and again.

• Categories or brand pages with one or two products and no copy
• Product pages that use the manufacturer’s description, which hundreds of other retailers also publish
• Tag, archive, or internal search pages that repeat the category listings
• Out-of-stock products that show little more than a name, a price, and a “notify me” button
• New pages that Google crawled once and hasn’t come back to yet

If the list holds pages you’d never link from a campaign, leave it. If it holds bestsellers or main categories, the fix is to make the page worth indexing: write category copy that answers what buyers compare, rewrite product descriptions for your top sellers, link to the page from the menu or related categories, and merge categories too small to stand on their own. Google says there’s no need to resubmit these URLs, so the time is better spent on the page itself.

Discovered – currently not indexed

“Discovered – currently not indexed” means Google knows the URL exists, usually from a link or a sitemap, but hasn’t crawled it yet. Google says it typically postponed the crawl because crawling at that moment was expected to overload the site, which is why the report shows no last crawl date. On a store, a growing count points to too many URLs, a slow server, or both.

A few hundred URLs here after a product launch is normal and clears as Google catches up. A count that keeps climbing is a sign Google is spending its crawl on URLs that don’t matter. Google’s crawl budget guide is written for sites with more than a million pages, sites with 10,000+ pages that change daily, and sites where a large share of URLs sit in this exact status, which can include a mid-size catalog with layered navigation.

These are the usual causes on a store, each with its fix.

1. Filter combinations can create millions of crawlable URLs. Block crawling of the ones you don’t want indexed in robots.txt, as Google’s faceted navigation guide recommends, and return a 404 for filter combinations that show no products
2. The server is slow or returns errors under load. Check the Crawl stats report in Search Console for slow response times, then fix hosting or caching first
3. Soft 404s and long redirect chains keep getting recrawled, so fix those and Google has more crawl left for real pages
4. The XML sitemap lists filtered, redirected, or noindexed URLs. Keep it to canonical, indexable product and category pages
5. Important new pages have few internal links. Link new categories and products from the menu, the homepage, or a parent category

If you run Magento, our guide to a Magento robots.txt setup shows which paths are safe to block.

Other statuses stores see, and the fix for each

The remaining statuses are mostly confirmations that your setup works. Two of them, soft 404 and server errors, need action on most stores.

Alternate page with proper canonical tag

This page points to another page as canonical, and Google indexed that page. Google says there is nothing you need to do. Filtered categories, sorted views, and variant URLs with a correct canonical tag all belong here, so a large count is a good sign.

Soft 404

A soft 404 is a page that looks like a “not found” page to Google but returns a 200 status code. On stores, the usual cases are empty categories, internal search pages with no results, and sold-out products whose page only says the item is unavailable. Keep temporarily sold-out products live with their full description, a stock message, and alternatives. Return a real 404 or 410 for products gone for good, or 301 redirect them to a replacement. Google’s crawl budget guide notes that soft 404 pages keep getting crawled, so they cost crawl as well as rankings.

Not found (404)

Google says 404s are not necessarily a problem if the page was removed without a replacement. Discontinued products with no successor can stay 404. Act when the list includes URLs that still get traffic or backlinks, or old URLs that moved, which should 301 redirect to the new page. Our guide to 404 page tracking shows how to spot the ones that still get visits.

Page with redirect

The URL redirects to another page, so Google indexes the target instead. After a migration, this status fills up with old product and category URLs, which is exactly what should happen. Check that the redirects go straight to the final URL in one hop, and that the SEO migration checklist steps for your redirect map were done.

Excluded by ‘noindex’ tag

The page carries a noindex directive, so Google left it out. Cart, checkout, account, wishlist, and internal search pages should be here. Look through the examples for product or category templates. A staging noindex left on after go-live also shows up here.

Blocked by robots.txt and indexed, though blocked

“Blocked by robots.txt” means Google didn’t crawl the URL because your robots.txt file disallows it, which is expected for checkout, account, and filter paths you blocked on purpose. Robots.txt only controls crawling, so a blocked URL with links pointing to it can still appear in search without its content. Google files those under “Indexed, though blocked by robots.txt”. To keep a page out of search, remove the robots.txt block and use noindex instead, since Google can only see a noindex tag on a page it is allowed to crawl.

Server error (5xx)

Googlebot couldn’t reach the page because the server failed, timed out, or was busy. Treat it as a hosting problem first. Match the dates in the report against traffic peaks, deployments, and sales, because a store that slows down every time a campaign starts is also slow for customers.

When to ignore a Search Console status

Ignore a status when the URLs in it are pages you don’t want in search, or when Google indexed the right version of the page under another URL. Act when your product, category, or content pages that should earn traffic appear in the examples, or when the indexed page count drops while the store’s catalog didn’t shrink.

Run each status through the same four questions, in this order.

1. Should this URL be in Google at all? Cart, checkout, account, search results, sort orders, and tracking parameters: no, so leave them
2. Is the page indexed under another URL? Inspect it and read the Google-selected canonical. If that is the URL you want, you’re done
3. Is the count growing week over week? A flat count can wait, while one that grows every week needs a look
4. Did the indexed page count drop at the same time? Google suggests looking for a matching rise in not indexed URLs, and checking robots.txt, noindex tags, and login requirements first

How to fix and validate an indexing issue

Fix the cause on the template, then tell Google. On a store, one setting or theme file usually produces thousands of affected URLs, so one change clears the whole group.

1. Open the status and export the examples. The list is limited to 1,000 rows, so treat it as a sample of the full set
2. Group the URLs by template or pattern, such as product, category, filter parameter, or search page
3. Inspect two or three URLs per group with the URL Inspection tool to see the live status and the Google-selected canonical
4. Fix the template, setting, or rule behind the group, and test it on a few URLs with a live test
5. Click “Validate fix” in the report. Google says validation typically takes up to about two weeks and sometimes longer

If the same statuses keep coming back after every release, add them to your release checks. A technical SEO audit checks canonicals, robots rules, and status codes across every template in one pass, and it’s where our eCommerce SEO team starts when a store’s indexing numbers look wrong.

Frequently asked questions about Search Console indexing errors

Is duplicate without user-selected canonical bad for SEO?

Usually not. Google says duplicate without user-selected canonical is not an error, because it means Google found a copy of another page and indexed the other version. On a store, those copies are mostly variant, sort, and tracking URLs. It’s only a problem when your main product or category URL is the one left out, which you can check with the URL Inspection tool.

How do I fix crawled – currently not indexed?

Make the page worth indexing. Google crawled it and decided to leave it out, so resubmitting the URL doesn’t help. On a store, add unique copy to thin categories, rewrite manufacturer product descriptions for your bestsellers, link the page from menus or related categories, and merge categories with only a few products. Ignore the status for pages you never wanted in search.

How long does Google take to index pages after a fix?

Google says a Validate fix request in Search Console typically takes up to about two weeks, and sometimes longer. Individual pages can be indexed sooner, especially ones with strong internal links. Large stores take longer because Google has to recrawl many URLs. Fix the template first and validate once, which saves requesting indexing for pages one at a time.

Should out-of-stock products be noindexed?

No, not if they’re coming back. Keep temporarily out-of-stock products indexed with their full description, a clear stock message, and alternatives, so they keep their rankings. A page reduced to a short “unavailable” message can be treated as a soft 404. For products discontinued for good, redirect to a replacement or the closest category, or return a 404 or 410.

Does blocking a page in robots.txt keep it out of Google?

Not reliably. Robots.txt stops Google from crawling a page, but the URL can still be indexed without its content if other pages link to it. Google lists those under “Indexed, though blocked by robots.txt”. To keep a page out of search results, allow crawling and add a noindex tag, because Google can only read the tag on a page it can crawl.

Why does Google show the wrong snippet for my product page?

Google builds snippets mostly from the page content and uses your meta description only when it describes the page better for that search. If the snippet shows old text, a shipping banner, or a cookie notice, rewrite the meta description to match the page, and make sure the main description appears early in the HTML. The data-nosnippet attribute keeps parts of the page out of snippets.

Why does Google show the wrong price or currency for my products?

Google reads price and currency from your product structured data and from Merchant Center. Wrong values usually come from markup that lists the default variant’s price, a price loaded with JavaScript after the page renders, or one currency used for every country. Test the page with the Rich Results Test and check that the price and priceCurrency match what customers see. Our product structured data guide lists the fields Google uses.

Why are my products disapproved in Merchant Center?

The cause stores run into most is a mismatch between the feed and the product page, usually on price or availability. Merchant Center checks the feed against your page and its structured data, so a sale price missing from the feed or a variant URL that shows another price can trigger it. Update the product feed more often, fix the markup, and use the right currency per country. Google recrawls disapproved products within hours or days.

Fix the statuses that touch the pages you sell

Duplicate without user-selected canonical, crawled – currently not indexed, and the other Page indexing statuses are mostly Google telling you how it handled the extra URLs your store creates. Start from the pages you sell from, check whether each one is indexed under the URL you want, and fix the template behind any group that includes them. Leave the rest, and check each month whether the counts are growing.

Search Console report full of statuses and no time to sort them? Send us the export, and we'll tell you which ones are costing you traffic.

The post Duplicate Without User-Selected Canonical and Other Search Console Errors appeared first on scandiweb.

If Meta says your ads drove 140 purchases last week, GA4 credits Meta with 60, and your store backend shows 118 orders in total, your tracking isn’t necessarily broken. Each tool counts on its own date and by its own rules about who gets the credit.

The gap still costs you. Part of it is purchases the browser never reports, and part of it can be the same order counted twice. Server side tracking fixes some of that, which is why so many vendors are pitching it right now. This guide explains why the numbers disagree, what server-side tracking and the Meta Conversions API change, how event deduplication works, what a server container costs to run, and when a mid-size store can skip it.

Why Meta, Google Ads, and GA4 never match

Meta, Google Ads, and GA4 never match because each one answers a different question. Meta counts purchases by people who clicked or saw a Meta ad. Google Ads counts purchases after a Google ad click. GA4 assigns credit across every channel a shopper used. They also date conversions differently, and each loses its own share of browser data to ad blockers and consent choices.

Each platform gives itself the credit

A shopper clicks a Meta ad on Monday, comes back through a Google ad on Wednesday, and buys. Meta counts the purchase because it happened within seven days of a Meta click. Google Ads counts it too. GA4 gives the credit to Google, or splits it, depending on the attribution model. Both ad platforms claim the same order, and both are following their own rules.

Meta also counts purchases by people who only saw an ad and bought within a day. GA4 can’t see an ad view at all, so on a store that spends most of its budget on Meta, view-through purchases are often a large part of the difference. Our guide to offline and online attribution covers how to compare channels without taking any single platform’s word for it.

The same purchase lands on different days

Google Ads reports a conversion on the day of the ad click, and GA4 reports it on the day of the purchase. In Google’s own example, a click on May 5 and a purchase on May 10 show up on May 5 in Google Ads and on May 10 in GA4. Meta’s Ads Manager also dates conversions back to the ad impression or click. Weekly comparisons drift for that reason alone, and the most recent days keep filling in as late purchases arrive.

Google says more than 95% of conversions are attributed within 14 days, so compare platforms on date ranges that ended at least two weeks ago.

Browsers and consent hide some purchases

Every platform misses purchases that its browser tag never reports. Ad blockers stop tags from loading, and Safari limits cookies set by JavaScript to seven days, so a shopper who returns after two weeks looks like a new visitor. Visitors who decline cookies are only partly counted, and how much Google models back depends on your Google Consent Mode v2 setup.

Duplicate events inflate Meta

If your store sends a purchase to Meta from the browser pixel and again from the server, and the two events don’t share an ID, Meta counts the order twice. Of all the causes here, this is the only plain error. When Meta’s purchase count comes close to your total order count, check deduplication first.

What is server side tracking?

Server side tracking sends conversion data from a server you control to platforms such as Meta, Google Ads, and GA4, instead of relying only on tags in the shopper’s browser. The browser sends one request to your own subdomain, or your store backend reports the order directly. The server then forwards each event to each platform, under rules you set.

On a typical store, it works like this. A shopper places an order, and the browser sends the purchase event to a server container on a subdomain such as data.yourstore.com. The container, often server-side Google Tag Manager, formats the event for each destination and sends it to GA4, the Meta Conversions API, and Google Ads. Because the request goes to your own domain, fewer ad blockers stop it. The server can also set cookies through HTTP headers, which Safari doesn’t cap the way it caps cookies written by JavaScript in most setups.

Client-side vs server-side tagging

Client-side tagging runs every vendor’s script in the shopper’s browser. Server side tagging moves most of that work to a server: the browser sends one stream of events, and the server decides what goes to each platform.

What server-side tracking can’t change

A server container doesn’t change attribution. Meta will still count view-through purchases and GA4 will still split credit across channels, so the platforms will keep disagreeing. It doesn’t override consent either. If a visitor declines marketing cookies, the server has to respect that, so consent signals need to travel with each event into the container.

What it can change is the share of real purchases each platform receives and the quality of the customer data attached to them. That improves the signal Meta and Google use to optimize bids. Your dashboards will look closer, but rarely identical.

How the Meta Conversions API works

The Meta Conversions API, often called Meta CAPI, lets your server send events such as purchases and add-to-carts directly to Meta, next to or instead of the browser pixel. Each server event carries an event name, a timestamp, an event ID, and customer details such as a hashed email or phone number, which Meta uses to match the purchase to a Facebook or Instagram account.

Meta scores that matching with Event Match Quality, a rating out of 10 for each event type in Events Manager. Email, phone number, name, and IP address are among the parameters Meta lists as high quality, and the browser user agent is required for website events. Unless you use Meta’s Business SDK, your server has to hash the customer details before sending them.

Meta recommends what it calls a redundant setup: send the same events through both the pixel and the Conversions API. The browser pixel adds context the server doesn’t have, while the server covers purchases the browser missed, and deduplication removes the overlap. Meta accepts server events up to seven days after they happened, which helps when an order is confirmed later, for example after a bank transfer.

A store has four common ways to send server events to Meta:

1. Shopify’s Facebook & Instagram app sends purchases through the Conversions API when data sharing is set to Enhanced or Maximum, with no server of your own
2. Magento (Adobe Commerce) stores usually add a Meta Pixel and Conversions API extension from the Adobe Commerce Marketplace, which sends events from the store backend
3. A server-side Google Tag Manager container forwards the same events to Meta, GA4, and Google Ads from one place
4. Meta’s Conversions API Gateway is free software that runs in your own cloud account and sends events to Meta only

For step-by-step setup in Google Tag Manager, our earlier guide to setting up the Facebook Conversions API walks through the pixel and the server tags.

How Meta event deduplication works with event_id

Meta deduplicates a browser event and a server event when both have the same event name and the same event ID, and the second one arrives within 48 hours of the first. The pixel passes the ID as eventID, and the Conversions API as event_id. When they match, Meta keeps one purchase. When the IDs are missing or different, Meta counts the order twice.

Picture two cashiers ringing up the same order. If both write the order number on the receipt, the accountant spots the copy and files one. If neither does, the books show two sales. For purchases, the order number is the obvious ID because the store already creates one for every order.

In the browser, the pixel call carries the ID as its fourth argument:

fbq('track', 'Purchase', {value: 129.00, currency: 'USD'}, {eventID: 'order_10482'});

On the server, the Conversions API event carries the same ID:

{
  "event_name": "Purchase",
  "event_time": 1792233177,
  "event_id": "order_10482",
  "action_source": "website",
  "event_source_url": "https://www.yourstore.com/checkout/success",
  "user_data": {
    "em": ["<sha256 of the lowercase email>"],
    "client_ip_address": "203.0.113.24",
    "client_user_agent": "Mozilla/5.0 ...",
    "fbp": "fb.1.1792230000.123456789"
  },
  "custom_data": {"value": 129.00, "currency": "USD"}
}

The result depends on which events arrive and what they carry:

• Both events arrive with the same name and ID: Meta keeps one, generally the first it received
• Only the server event arrives because an ad blocker stopped the pixel: Meta records the purchase from the server
• Only the pixel event arrives because the server call failed: Meta records the purchase from the browser
• The IDs differ, for example the pixel sends the order number and the server sends an internal transaction ID: Meta counts two purchases
• The event names differ, such as “Purchase” and “purchase”: Meta treats them as two separate events

Meta also supports a fallback that matches on the fbp browser cookie or external_id instead of the event ID. It only works when the browser event arrives first, which means it misses the very purchases a server setup is meant to rescue, so use the event ID.

To check your setup, open the Purchase event in Meta Events Manager and compare the deduplicated event count with your backend orders for the same days. If Meta’s purchases are close to or above your total orders while GA4 shows far fewer, place one test order and compare the IDs both sources sent.

What server side tagging costs to run

A server-side Google Tag Manager container on Google Cloud Run costs roughly $90 a month at minimum, based on Google’s estimate of about $45 per server per month and its advice to run at least two servers. Traffic peaks scale that up. The bigger cost is the work to build the setup and keep it running.

Google’s Cloud Run setup guide, last updated in May 2026, gives these numbers:

• Each server is a Cloud Run instance with 1 vCPU and 0.5 GB of memory, at about $45 a month
• Google recommends at least two instances, so one server outage doesn’t lose data
• Two to ten servers handle roughly 35–350 requests per second, depending on how many tags you run
• A separate preview server is provisioned for debugging in Tag Manager

At ten servers during a Black Friday peak, the same estimate works out to about $450 a month for those days. Cloud Run is Google’s recommended host, but the container can run in other environments too. Managed providers such as Stape sell server-side GTM hosting on monthly plans priced by request volume, starting with a free tier for low traffic. That removes the cloud setup and adds a vendor.

If Meta is the only platform you need server events for, Meta’s Conversions API Gateway is a lighter option. The software is free, you pay for the cloud resources, and Meta’s own setup flow estimates AWS costs upwards of $30 a month.

Google also offers Google tag gateway for advertisers, which serves the Google tag from your own domain through your CDN or load balancer. It isn’t a full server container, and Google recommends running both for the most durable setup.

Someone also has to rebuild each tag in the server container, pass consent signals through, test purchases against real orders, and watch for drops after every release. If nobody owns that work, a broken container can go unnoticed for weeks.

Is server-side tracking worth it for a mid-size store?

Server-side tracking is worth it when paid media drives a large share of revenue across several platforms and someone can own the setup after launch. If your store runs one ad platform on Shopify or Magento, a native Conversions API connection with working deduplication usually closes most of the fixable gap for a fraction of the effort.

Server-side tracking is worth it if:

• Paid media is one of your largest costs, so a few percent of missing conversions changes bidding decisions
• You send purchases to several platforms, such as Meta, Google Ads, TikTok, and GA4, and want one place to manage them
• A high share of your traffic uses Safari and iOS, where cookie limits hit returning shoppers hardest
• You want to control exactly which customer data each platform receives
• You have an analytics team, or a partner, to maintain and monitor the container

It isn’t worth it yet if:

• Meta is your only paid channel and your platform has a native Conversions API connection you haven’t switched on
• Your purchase events aren’t deduplicated, since moving broken events to a server keeps them broken
• Your consent banner and Consent Mode setup aren’t working, because a server container passes the same consent problems on
• Nobody can debug the container when a release breaks it
• You expect it to make Meta and GA4 report the same numbers

If the first list describes your store, our server-side tracking team starts every setup by measuring the gap against backend orders, so the result is a number you can check.

Measure the gap before you build anything

Before choosing a setup, measure how many backend orders each platform receives. Compare orders in your store backend with purchases in GA4 and with the purchase events Meta received for the same days. That shows how much data you lose today, which is the only part a server setup can recover.

1. Export backend orders by day for a period that ended at least two weeks ago, so late conversions are included
2. Pull GA4 purchases by day for the same dates across all channels, and compare the totals with the backend
3. Pull the received Purchase events in Meta Events Manager for the same dates, instead of the attributed purchases in Ads Manager
4. Check with one test order that the pixel and server events share an event ID
5. Check your consent rate and Consent Mode setup, so you know how much of the gap is visitors who declined

If GA4 receives 90% of backend orders and Meta’s event count is in line with GA4, the browser setup is doing most of the job. If GA4 sees 70% and Meta’s events exceed your orders, you have both lost and duplicated events, which is a strong case for fixing tracking first. Our analytics team runs this comparison as the first step of a tracking audit.

Frequently asked questions about server side tracking

Is server-side tracking legal?

Yes, server-side tracking is legal, but it doesn’t change what you need consent for. Under GDPR and similar laws, sending a visitor’s data to Meta or Google for advertising still requires their consent, whether the request comes from the browser or your server. A compliant setup passes consent signals into the server container, and the container forwards data only where the visitor agreed.

Why does Meta report more purchases than GA4?

Meta reports more purchases than GA4 because it counts purchases within seven days of a Meta ad click and one day of an ad view, even when another channel got the last click. GA4 assigns that credit elsewhere and can’t see ad views at all. Duplicate pixel and server events without a shared event ID can also inflate Meta’s count.

Does server-side tracking bypass ad blockers?

Server-side tracking gets past many ad blockers because the browser sends data to your own subdomain instead of Meta’s or Google’s domains. Events your store backend sends directly don’t depend on the browser at all. It must never be used to get around a visitor’s consent choice, because data protection law applies to server requests exactly as it does to browser tags.

Do I still need the Meta Pixel with the Conversions API?

In most cases, yes. Meta recommends running the pixel and the Conversions API together and sending the same events through both, with a shared event ID for deduplication. The pixel adds browser details that help Meta match visitors, and the Conversions API covers purchases the browser misses. The Conversions API works on its own, usually with lower match quality.

How much does server-side tracking cost?

Hosting a server-side Google Tag Manager container on Cloud Run costs about $45 per server per month, according to Google, which recommends at least two servers, so roughly $90 a month before traffic peaks. Managed hosting providers charge monthly plans by request volume. Setup and maintenance usually cost more than hosting and depend on how many platforms and markets you track.

What is the difference between client-side and server-side tracking?

Client-side tracking runs each platform’s tag in the shopper’s browser, and each tag sends data straight to its vendor. Server-side tracking sends one stream of events to a server you control, usually on your own subdomain, and the server forwards data to each platform. It gives you more control over the data and loses fewer events to blockers, at the cost of hosting and maintenance.

Fix the gap you can measure, then decide on the server

Server side tracking helps a store send more of its real purchases to Meta, Google Ads, and GA4, with better customer data attached. It won’t make the platforms agree, because they assign credit and dates by different rules on purpose. Start by measuring how many backend orders each platform receives, then fix deduplication and consent, and switch on the Conversions API your platform already offers. Build a server container when your paid media budget and the number of platforms justify someone owning it.

Not sure whether your gap is lost data or counting rules? Talk to our analytics team, and we'll compare your backend orders with what Meta and GA4 receive.

The post Server-Side Tracking and Meta Conversions API: Why Ad Platforms and GA4 Disagree appeared first on scandiweb.