Magento (Adobe Commerce) builds every page from scratch: it runs PHP code, queries the database and assembles the HTML, and all of that takes time. The Magento full page cache saves a finished copy of each page and hands that copy to the next shopper, so Magento can skip the build.

Most stores keep that cache in Varnish, a caching server placed in front of Magento. Varnish answers repeat requests itself, so they never reach Magento at all, and Adobe strongly recommends it for live stores.

A saved copy helps only when one exists for that exact page and that kind of visitor. The first shopper after a deploy or a cleared cache waits for Magento to build the page. So do shoppers who tick two filters on a category, B2B buyers with their own price list when nobody from their customer group has visited since the cache was cleared, and anyone searching for a rare term. Cart, checkout and account pages skip the cache entirely. Slow catalog pages for logged-in customers and slow category pagination both came up in Magento support requests we handled over the past year.

What is the Magento full page cache?

The Magento full page cache stores the finished HTML of a page so the next visitor with the same context gets it without Magento building the page again. It holds category, product and CMS pages, keyed by URL and context, for guests and logged-in shoppers alike. Cart, checkout and account pages are always built fresh.

The rest of Magento caching stores smaller pieces, such as merged configuration. The admin grid lists this one as Page Cache.

How Magento cache works on a single request

A shopper requests a category URL. Varnish, or the built-in cache, builds a key from that URL and a hash of the HTTP context: customer group, store, language, currency and whether the shopper is logged in. Magento carries that context in the X-Magento-Vary cookie, and Adobe’s page on HTTP context variables lists the full set.

If a saved page matches the key, the cache returns its HTML and Magento does not run. If nothing matches, the request goes to Magento, which builds the page in PHP: it loads the layout, renders each block and runs the database queries behind them. The finished HTML is saved with its cache tags and a TTL, then returned. The next visitor with the same URL and context gets the saved copy.

Only GET and HEAD requests can be cached. A form post goes to PHP every time.

Public and private content: hole punching in Magento 2

Everyone in the same context gets the same cached HTML, so Magento keeps personal data out of it. Public content, the page itself, is stored server side in the cache. Private content such as the customer name, cart, wishlist and address is stored client side and loads in the browser after the page arrives, from customer-data sections. A POST or PUT request invalidates those sections, so the cart updates after an add to cart without touching the cached page.

With Varnish, a block can also carry its own TTL. The top menu in the default theme is marked ttl="3600", so Varnish can cache it apart from the page through ESI and refresh it on its own schedule.

Adobe warns against adding a context variable per user. Every context variable is part of the cache key, so a per-user variable gives each user a separate copy of every page, and the cache stops sharing anything.

Magento full page cache vs Varnish

Magento’s built-in full page cache is a PHP reverse proxy that stores pages in the file system, the database or Valkey/Redis, so every hit still runs PHP. Varnish is a separate caching server in front of the web server, and a hit never reaches the web server. Adobe strongly recommends Varnish in production. Commerce Cloud uses Fastly.

The table shows where the two options differ.

The built-in option is fine on a laptop or a staging server. Production gets Varnish: a repeat request for a cacheable page costs no PHP, database or web server time, and Adobe’s Varnish configuration page calls the built-in cache much slower.

Magento Varnish is a separate HTTP cache that Magento purges by tag whenever it cleans, flushes or refreshes its own cache. The Caching Application setting is the only switch between the two.

Where Fastly fits on Adobe Commerce Cloud

On Adobe Commerce Cloud, full page caching uses Fastly instead of Varnish, so there is no Varnish to install or configure. The cache key and the private-content rules in this article still apply, because Magento sets the headers and the context cookie in the same way.

Magento cache management: cache types, clean and flush

Magento cache management happens in System > Tools > Cache Management or with bin/magento cache commands. The admin lists every cache type, such as Configuration, Layouts, Blocks HTML output and Page Cache, with its status. Refresh any type marked invalidated, clean caches after code or configuration changes, and flush the whole storage only when cleaning fails.

The cache types that matter for page speed

Five types decide most of what a shopper waits for in Magento 2 cache management.

The Cache Management grid lists more types than these, and the exact set depends on the edition and the modules installed. Adobe’s Cache Management page describes each one.

Clean vs flush: which one to run

The two buttons at the top of the grid do different things. Flush Magento Cache runs cache:clean: it removes items by their Commerce tag, from enabled types only, and leaves anything else in the storage alone. Flush Cache Storage runs cache:flush: it empties the whole storage, including files that other applications keep in the same place.

Clean after routine changes, such as a template or configuration edit. Flush only when cleaning does not fix the problem, and schedule it off-peak, because Adobe warns that clearing caches at peak can raise the load enough to take the site down until the operation completes. If you need to clear the cache in Magento 2 from the admin, refresh the affected type rather than everything, and read our post on when to flush the whole cache storage before doing it on a live store.

What “One or more of the Cache Types are invalidated” means

The red banner in the admin reads “One or more of the Cache Types are invalidated”, followed by the list of types, and asks you to go to Cache Management and refresh them. It means the stored data for those types may no longer match the database. Catalog changes are the usual cause, because an edit to one entity can affect other pages and invalidate several caches at once. Configuration saves and deploys do the same.

To fix it, open Cache Management, tick the invalidated types, set Actions to Refresh and click Submit, or run bin/magento cache:clean full_page. Reindexing does not require a cache flush, so leave the cache alone when you reindex. If the banner comes back every few minutes, find what keeps invalidating it, such as an import, a cron job or frequent product saves, instead of refreshing all day. Keeping the Magento indexers on Update on Schedule, which Adobe recommends for performance, removes one common cause.

How to enable, disable and configure full page cache in Magento 2

To enable full page cache in Magento 2:

1. Go to System > Tools > Cache Management, select Page Cache, set Actions to Enable and click Submit.
2. Or run bin/magento cache:enable full_page.
3. Under Stores > Settings > Configuration > Advanced > System > Full Page Cache, set Caching Application to Varnish Caching.
4. Save the configuration.

Enable full page cache in the admin

Go to System > Tools > Cache Management, tick Page Cache, set Actions to Enable and click Submit. Then open Stores > Settings > Configuration > Advanced > System > Full Page Cache and set Caching Application to Built-in or Varnish Caching.

If Enable and Disable are missing from the Actions dropdown, the store is in production mode. Since Magento 2.2, production mode allows enabling and disabling cache types from the command line only, so the admin offers Refresh and nothing else.

Enable or disable full page cache from the command line

Run the commands as the file system owner, from the Magento root:

bin/magento cache:status
bin/magento cache:enable full_page
bin/magento cache:disable full_page

cache:status lists every type with 1 for enabled and 0 for disabled. Enabling a type clears it, so expect the first requests after cache:enable to miss. Omitting the type applies the command to all types.

Disable full page cache in Magento 2 only to turn off the cache during development, when every change has to show at once. Never do it on a live store: every request then goes to PHP, and the server carries the full build cost for every page. Adobe’s Manage the cache page lists the remaining options.

Magento full page cache settings worth checking

All of these live under Stores > Settings > Configuration > Advanced > System > Full Page Cache.

Caching Application: Varnish Caching for production. From the CLI, run bin/magento config:set --scope=default --scope-code=0 system/full_page_cache/caching_application 2.

TTL for public content: 86400 seconds by default, the longest a page stays in the cache without a purge.

Varnish Configuration: access list and backend host (both default to localhost), backend port (8080), grace period (300 seconds, how long Varnish may serve an expired copy while Magento builds a fresh one) and handles param size (100, the most layout handles the ESI endpoint processes). Export the VCL from the same screen and install it on the Varnish host. Then set purge hosts with bin/magento setup:config:set --http-cache-hosts so Magento can purge Varnish when its own cache cleans. Varnish 8 is the version for Magento 2.4.9.

If you stay on the built-in cache, give it its own storage. Adobe recommends a dedicated instance each for sessions, the default cache and the full page cache. To use Redis for the full page cache on 2.4.8 and earlier, run bin/magento setup:config:set --page-cache=redis --page-cache-redis-server=127.0.0.1 --page-cache-redis-db=1, with a database number no other cache uses. On 2.4.9, Valkey replaced Redis in the CLI tooling, so use the Valkey options in Adobe’s CLI reference.

What the Magento full page cache can’t serve

The Magento full page cache never serves cart, checkout or customer account pages, POST requests, or any page with a block marked cacheable="false". It can hold filtered category pages, search results and customer-group versions, but each URL and context needs its own entry, so many of them miss. Every miss goes to PHP.

Requests that always skip the cache

Three groups never touch the cache. Cart, checkout and customer account pages: the default Varnish configuration that comes with Magento passes any URL containing /customer or /checkout straight to the backend, and Adobe’s own examples of uncacheable pages are cart, checkout and compare. POST and every other method besides GET and HEAD: the same VCL only caches those two, so an add to cart or a form submit always runs PHP. Any page with one block marked cacheable="false": Adobe’s rule is that one uncacheable block makes the whole page uncacheable, and that attribute often arrives in a third-party module’s layout file rather than your own code.

The first two groups are by design. The third is the one to check, because it can quietly turn a category or CMS page into one that builds in PHP on every request.

Requests the cache can hold but often misses

Four kinds of request are cacheable and still miss often.

The first request after a deploy, flush or TTL expiry. Cleaning, flushing and refreshing the Magento cache all purge Varnish too, and so does editing a category, price, product or promotional pricing rule. After each one, the first shopper on each page waits for the build and the second gets the copy.

Filtered category pages. Each filter combination is its own URL, so it gets its own cache entry, and combinations multiply with every attribute you expose in layered navigation. The default VCL strips gclid, gbraid, gclsrc and utm_ parameters, so an ad click shares the cache with a direct visit. Filter parameters stay in the key because they change the page.

Search results. In Magento 2.4 the default VCL has no bypass for search URLs and the search results layout has no uncacheable block, so results pages are cacheable, one entry per search term. Popular terms hit. Rare terms miss, and a first-time search always does.

Logged-in customers and B2B customer groups. The context hash gives each customer group, store and currency its own copy of every page. A B2B store that puts companies or price lists in separate customer groups fills many small caches rather than one big one, and a buyer in a quiet group gets a miss on pages that guests see from the cache all day.

How to find and fix full page cache misses

To fix Magento full page cache misses:

1. Confirm Page Cache is enabled and set to Varnish.
2. Check the X-Magento-Cache-Debug header for MISS, then HIT.
3. Remove cacheable="false" from catalog and CMS layouts.
4. Stop flushing caches at peak hours.
5. Warm key URLs after deploys.
6. Make the uncached page build faster.

Check whether a page came from the cache

Magento adds its debug headers in developer mode only, so run this on staging or in a short developer-mode window, never on a live production store. Request the page twice with curl -I and read two headers. X-Magento-Cache-Debug shows MISS on the first request and HIT on the second. If the Magento 2 full page cache is not working at all, it shows MISS every time. X-Magento-Cache-Control shows the TTL, for example max-age=86400, public, s-maxage=86400. Adobe’s Verify Varnish configuration page says a cacheable page should load in less than 150 ms when Varnish works, and that var/page_cache should stay empty.

Then test the miss path: log in, open a filtered category URL right after a cache clean, and run a rare search. Compare those timings with field data from PageSpeed Insights and Google’s guide of 0.8 seconds or less for a good TTFB. If the header says HIT and the page is still slow, the wait is in the browser, in the theme, images or JavaScript, and a frontend such as Hyvä is the place to look.

Fix the misses you can remove

Work through these in order.

1. Remove cacheable="false" from blocks on catalog, product and CMS pages. Move whatever personal data the block showed into private content, so it loads in the browser.
2. Switch production from Built-in to Varnish Caching. A built-in hit still runs PHP.
3. Clean by type instead of flushing, and schedule any flush off-peak.
4. Find what keeps invalidating the cache. Imports, mass product saves and cron jobs that touch the catalog purge pages all day.
5. Keep custom cookies and context variables out of the cache key. Each new variable multiplies the number of copies.
6. Warm the top URLs after each deploy, briefly. A warmer refills the most visited pages so the first shoppers get hits, and it has done its job once the cache is full.

Make the uncached page build faster

Some misses stay. Rare searches, filter combinations and customer groups cannot all be warmed, because there are too many of them and the list changes every day. For those requests, the time Magento takes to build the page is the time the shopper waits, and no cache setting changes it.

Expedio is scandiweb’s software for that part of the request. It speeds up how Magento builds each page on the server by applying Liquid, the open-source template language created at Shopify, and its core is open source. It works on Magento 2 Open Source, Adobe Commerce and Commerce Cloud, with Luma, Hyvä or a custom theme, on any hosting, and it leaves the theme, design, data, admin, catalog, prices, checkout and orders as they are. The page build gets at least 2x faster, and the same server handles 3x the traffic before response times start to rise. In a benchmark on one merchant’s Hyvä store, measured as server response time with no full page cache, category pages opened with all caches empty took a median of 57 ms instead of 181 ms, 3.2x faster. At peak traffic, filtered category pages answered 3.0x faster and search results 3.8x faster. The method and caveats are in the Expedio benchmark.

Frequently asked questions about Magento full page cache

Does the Magento full page cache work for logged-in customers?

Yes, for catalog and CMS pages. Magento keys each cached page by URL plus a context hash from the X-Magento-Vary cookie, which covers the customer group, store, currency and whether the shopper is logged in. Personal details such as the name and cart load separately in the browser. Each customer group fills its own copy, so stores with many B2B groups see more misses.

Should I use Varnish or the built-in full page cache in production?

Use Varnish. Adobe strongly recommends Varnish in production and calls the built-in full page cache, whether it writes to the file system or the database, much slower. A Varnish hit is answered without reaching the web server, while the built-in cache still runs PHP for every hit. On Adobe Commerce Cloud, Fastly does the full page caching instead.

How long does Magento keep a page in the full page cache?

For 86,400 seconds, or 24 hours, by default. That is the TTL for public content under Stores > Settings > Configuration > Advanced > System > Full Page Cache. A page can leave the cache sooner: editing a product, category, price or promotional pricing rule purges the related pages, and cleaning or flushing the Magento cache purges Varnish too.

Are search results pages cached in Magento 2?

They can be. In Magento 2.4, the default Varnish configuration does not bypass search URLs, and the search results layout has no uncacheable block. Each search term is a separate URL, though, so only repeated searches find a cached copy. A rare or first-time search misses, and Magento builds the results page in PHP.

Does flushing the Magento cache slow the store down?

For a while, yes. After a flush, PHP has to build every page again until shoppers or a cache warmer refill the cache, so server load and response times rise. Adobe advises scheduling cache flushes for non-peak times. Use cache:clean for routine changes, and keep cache:flush, which empties the whole cache storage, for cases where cleaning does not help.

Do I need a cache warmer if I already run Varnish?

A warmer helps after deploys and flushes, when Varnish starts empty. It requests your most visited URLs so the first shoppers get cached pages. It adds server load while it runs and cannot reach every filter combination, search term or customer group. For those requests, shoppers wait for the uncached page build, so its speed still matters.

Magento full page cache: what to fix first

The Magento full page cache is the first speed fix for any store with real traffic, and the order of work after turning it on matters more than any single setting. Run Varnish in production rather than the built-in cache. Remove the misses you cause yourself: uncacheable blocks that a module added, flushes at peak, imports that invalidate the cache every few minutes. Warm the pages that matter after each deploy. Then look at the requests that will always miss, filtered pages, rare searches and quiet customer groups, and make the uncached build itself faster, because that is the time those shoppers wait.

The full page cache is one layer of the work to speed up Magento, alongside the server, database and frontend.

If the cache is on and logged-in, filtered or search pages are still slow, ask our Magento team to measure which requests miss and what each one costs your store.

The post Magento Full Page Cache: How It Works, What It Can’t Cache, and How to Fix Misses appeared first on scandiweb.

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. 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.

At 14:00 UTC on October 21, 2026, PHP released fixes for PHP2Shell, two flaws that can let a stranger with no login run code on a PHP web server. Cloudflare’s CEO counted thousands of exploit attempts in the ten hours before the fixes went out, tens of thousands in the 45 minutes after, and millions after that.

Magento, Adobe Commerce, WooCommerce and Shopware all run on PHP, and this PHP security vulnerability is below the store code, where no store patch reaches. The fix is a PHP update on the server, so your store is only as safe as whoever runs that server: your host, Adobe, your agency or your own team. For most store owners, this week’s question is easy to ask and slow to answer: which PHP version is each of our servers running, and who confirmed it?

What is PHP2Shell?

PHP2Shell is the name for two flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, each rated CVSS v4.0 9.2. A crafted web request can trigger them without a login and let an attacker run their own code on the server. PHP fixed both in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on October 21, 2026. Magento, WooCommerce and WordPress have no patch for it, because the fault is in PHP.

PHP is both the language most store software is written in and the program that runs it on the server. The flaws are in how that program handles memory while it reads an incoming request, before your store’s own code starts. An attacker who gets code running at that point can do what a developer with server access could: add a card skimmer to checkout, copy passwords and API keys out of memory, or take the site offline.

PHP’s advisory calls the first flaw remote code execution through out-of-memory corruption, and the second remote code execution through stale state left behind by an earlier request. It covers every PHP setup that serves web requests (PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed) and rates mod_php highest, with a demonstrated exploit that fires before any application code runs. Sansec traced the vulnerable code back to PHP 5.4.0 from 2012, and Wiz researchers said the findings rank among the most severe vulnerabilities discovered in PHP, a language behind about 69.7% of websites whose server-side language is known, according to W3Techs figures cited by Infosecurity Magazine.

PHP2Shell timeline: what happened in October 2026

The flaws went from private bug report to internet-wide scanning in about ten weeks. Researchers reported them to PHP in August, the first exploit attempt hit a honeypot on October 17, details leaked on October 20, and PHP released the fixes at 14:00 UTC on October 21. CISA listed both CVEs as known exploited on October 26.

Three critical flaws in seven weeks for Magento stores

This was the third critical flaw Magento stores had to deal with in seven weeks, and each one needed a different fix from a different place:

• StyleSmuggler, CVE-2026-75650, CVSS 10.0: a Magento zero-day under attack from September 4, fixed by Adobe’s hotfix APSB26-146 on September 7 (see which versions the StyleSmuggler patch covers)
• BlockStrap, CVE-2026-103849, CVSS 10.0: a template-engine injection fixed in Adobe’s APSB26-153 on October 13, which Sansec named and rates higher than Adobe’s priority 2
• PHP2Shell, October 21: a flaw in PHP itself, closed only by a PHP update

A store that installed the October Magento patch and stopped there is still exposed to the PHP flaw, and a store that updated PHP still needs the October Magento patch.

Is your store affected by PHP2Shell?

Your store is affected if any part of it runs PHP and serves web requests, until that PHP is updated or rebuilt with a vendor backport. That covers Magento, Adobe Commerce, WooCommerce, Shopware, WordPress and Drupal, plus the PHP systems around a store, such as a Pimcore or Akeneo PIM, a blog or a custom tool. Clean store code makes no difference.

Sansec confirmed that Magento, Shopware and WooCommerce stores are affected “even when their own code is clean,” and Calif showed unauthenticated code execution on Magento 2.4.9, WordPress 7.1.2 and Drupal 11.4.3, among others. Who installs the fix depends on how you host:

On Adobe Commerce on cloud infrastructure, Adobe Support told us on October 21 that it would deploy updated PHP images as soon as the patches were available, staging before production, and that no customer action was needed. We found no public Adobe bulletin on PHP2Shell, so a support case is how you confirm it for your own environment.

Which PHP version fixes it on each Magento line

Each Magento line supports a fixed set of PHP branches, listed in our Magento end of life guide. Matched against PHP’s fixed releases:

PHP no longer releases 8.1 or older, so stores on 8.1 depend on a Linux distribution or hosting vendor that applied PHP’s source backport, and they need an upgrade plan. Our step-by-step Magento upgrade guide covers the path.

How to check which PHP version your store runs

On a server you control, run:

php -v

The first line shows the version and build date. Anything built before October 21, 2026 can’t contain the fix. Distribution packages sometimes keep an older version number with the fix backported, so check the package changelog for both CVE IDs. The command line and the web server can also run different builds, so check PHP-FPM or mod_php, not only the terminal. On managed hosting, ask for the version and build date in writing.

What PHP2Shell means for your business

An attacker who gets this flaw to work has the access of a developer on your server, about five weeks before Black Friday on November 27. For a store, that can mean a card skimmer in checkout, stolen customer data or a site that’s down in peak season. Exploit attempts are confirmed at internet scale, and as of October 27, 2026, no successful break-in at a specific store had been publicly confirmed.

The sources disagree on how dangerous the attempts are. Amazon described PHP2Shell as broadly exploited in the wild, while saying it was unclear whether the attempts would have worked against real systems. Sansec found the public exploits don’t work against a default PHP installation and that an attack “needs specific knowledge of the target server and specific conditions on it.” CISA still added both CVEs to its known-exploited catalog.

An unpatched server is exposed, which is different from breached, and a patch only stops new attempts. Sansec notes that leaked memory can contain “passwords, session tokens, API keys and TLS private keys from other requests,” so the checks in the next section are what tell you whether anyone got in between October 17 and your patch date.

Outside parties watch the same dates. PCI DSS requirement 6.3.3 expects critical security patches within one month of release (our PCI DSS SAQ guide covers who is responsible for what), and cyber insurers read the bulletins too. The day after PHP2Shell, the CTO of one retail client forwarded us an alert their insurer had sent about BlockStrap, saying they hadn’t seen an update on it yet. Our team had been working on it for two days.

What to do now if PHP2Shell is not patched yet

Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 on every server that runs it, restart every PHP process, then check for signs of compromise and rotate credentials. PHP’s release notes are blunt about the alternatives: “There are no complete mitigations, updating is the only safe choice.”

1. Update PHP everywhere it serves requests: staging first, then production, then the PIM, the blog and any custom tools. The package changelog should list both CVE IDs.
2. Restart every PHP process, including PHP-FPM or Apache, cron and Magento’s queue consumers. A process that wasn’t restarted still runs the old PHP.
3. On PHP 8.1 or older, get a backported build from your Linux distribution or LTS vendor, or build from the PHP team’s source backports for 7.4, 8.0 and 8.1, then plan the move to a supported branch.
4. Check for compromise before cleaning anything, and keep the logs. Look for unknown admin users, script tags in core_config_data, cms_block and cms_page, unexpected PHP files in pub/media, recently changed PHP files, and PHP processes that started shells, in logs from October 17 onward. A Magento code audit is the thorough version.
5. Rotate payment gateway credentials, integration and API tokens, and database and admin passwords.
6. Test checkout end to end with every live payment method.

If you can’t patch PHP today

CISA’s alert says to take PHP systems offline until they’re patched, while Sansec’s view is that stores don’t need to go offline. If you keep the store up, PHP lists partial measures that “reduce exposure to specific attack paths but do not make an installation safe.” Set them in php.ini, the FPM pool or the server config, because ini_set() and .user.ini apply too late:

memory_limit = -1
post_max_size = 8M
session.upload_progress.enabled = 0
fatal_error_backtraces = 0

Set memory_limit where applications can’t override it, such as php_admin_value in the FPM pool, and add a container or cgroup memory cap, because one request can now take all of the server’s memory. If the site needs uploads, use 32M for post_max_size and keep upload_max_filesize below it. fatal_error_backtraces exists on PHP 8.5 only. Restart every worker afterward.

Sansec’s other stopgap is blocking multipart/form-data requests at the web server, which breaks uploads, so test checkout afterward. Magento maintenance mode doesn’t help. A web application firewall gives interim cover: Cloudflare pushed rules for the known exploit vectors to every plan, including free ones. Remove each stopgap once PHP is updated, and put the memory limit back.

How we handled PHP2Shell across our clients’ stores

By 09:00 UTC on October 21, five hours before PHP published the fix, more than 40 of our client projects each had a critical-priority ticket. On one client’s own AWS setup, PHP 8.5.12 was running in production at 16:38 UTC, under three hours after the release. Every store went through the same steps in between: alert, ticket, temporary protection, patch, test and monitoring.

PHP’s advance notice on October 20 gave us a day to prepare. At 08:23 UTC on October 21, our Executive Board emailed clients that the fix was due at 14:00 UTC and that a successful attack could take a site down, wipe data or leak customer data. The email also said, in these words: “This alert does not mean your store has been compromised. No attacks on our clients have been confirmed so far.”

Each store then got a ticket from one template (what is happening, the hosting, the current PHP version, whether it gets the official fix, the other PHP systems in scope, how to verify) and an eight-hour plan:

• Preparation, 1.5 hours: review every PHP system in scope, back up code and database, write the rollback plan
• Applying the fix, 2 hours: staging, then production, then the other PHP systems
• Testing, 3.5 hours: confirm the flaw can no longer be exploited, run checkout with every live payment method, check that ERP, PIM, shipping, search and marketing integrations still sync, and smoke test the admin, order emails and scheduled jobs
• Aftercare, 1 hour: 24 hours of production monitoring and a summary for the client

Before the fix was out, we applied temporary protections with no downtime: upload-progress tracking off, stricter session settings, and file uploads blocked before they reached PHP. One client’s PIM ran PHP 8.0, which gets no official fix, so we rebuilt PHP with the PHP team’s backport where no fixed package existed, kept a rollback copy on each server, and sent an estimate for a supported version. For Adobe Commerce cloud clients, we opened Adobe Support cases that morning and kept following up. For stores on other hosts, we asked each host for the fixed build and the date it went on. One client’s site went offline behind a redirect and came back once patched. September’s StyleSmuggler response has its own write-up.

What clients told us

Most replies were about being told early. A beauty brand thanked us for being “so quick to react with the PHP vulnerabilities,” and a retailer on Adobe’s cloud wrote: “I just want to sincerely thank you for all your efforts in chasing this update.” Our Executive Board’s note to the team the next day drew the lesson: react fast, and keep clients informed before they have to start asking.

How to prepare for the next critical PHP or Magento vulnerability

Preparing for the next critical vulnerability is work you do before the bulletin arrives: supported PHP on every system, a written answer to who patches what and how fast, a list of every PHP system you run, and a patch routine your team has practiced. Three critical flaws in seven weeks is the pace to plan for.

Start with PHP’s support calendar:

PHP 8.2 stops getting security fixes on December 31, 2026, and it is the newest PHP that Magento 2.4.6 supports. Then work through the rest:

1. Keep every system on a supported PHP branch, including the ones nobody logs into often.
2. Write down who patches what: for each system, the owner (host, Adobe, agency or in-house team), the response time for a critical bulletin, and who covers nights and weekends, which a Magento support retainer should spell out.
3. Keep a list of every PHP system. CISA warns that PHP “is often a component of other software and prevalence may not be directly observable,” and PIMs, blogs and internal tools are the ones that get forgotten.
4. Practice a same-day patch routine: backup, rollback plan, staging first, a scripted checkout test with every payment method, and a check that the exploit no longer works.
5. Put a web application firewall or CDN in front of the store, with skimmer and file-change monitoring behind it, so you would know if someone got in before the patch.
6. Write the messages in advance, for stakeholders and for customers. Our 08:23 UTC alert went out before the fix existed because the template already did.
7. Agree that security fixes override the Black Friday code freeze. An unpatched critical flaw is a bigger risk to peak-season revenue than the patch, and our code freeze guide covers how to plan the exception.
8. Decide how many servers you want to patch yourself. Managed Magento hosting or Adobe Commerce as a Cloud Service moves PHP updates to the provider, and you give up control over timing: on October 21, our client on its own AWS was patched within three hours, while cloud clients waited for Adobe’s rollout.

What CTOs, heads of eCommerce, and heads of marketing should each own

Security incidents tend to go wrong at the handoffs, when the host assumes the agency has it and the agency assumes the host patched. Give each role a short list before the next bulletin, so everyone knows what they own.

For CTOs and technical leads

• A runtime inventory with every PHP version and build on every server, kept current
• An ownership matrix for patching, with a response time for critical bulletins
• A test that proves the exploit no longer works, run after every patch
• An end-of-life roadmap with a budget, since PHP 8.1 is already unsupported and 8.2 follows on December 31
• Logs kept long enough to look back, since the first attempts came four days before disclosure

For heads of eCommerce

• A checkout test list with every live payment method, plus the integrations to check after a patch
• A maintenance page that returns a 503 status, so search engines treat a short outage as temporary
• A code-freeze exception for security fixes, agreed before Black Friday
• Host and vendor contracts that name a response time for critical bulletins

For heads of marketing

• A tag inventory, because third-party scripts and tags are where card skimmers hide, and marketing owns most of them
• A pre-approved holding statement, used only when there is something to tell customers
• Campaigns you can pause within minutes if the store goes into maintenance

For store owners and CEOs

Five questions to ask your team or agency this week:

1. Which PHP version and build date does each of our servers run today?
2. Who installed the fix on each one, and when? Do we have that in writing?
3. Which other PHP systems do we run, and who checked them?
4. What did we check for compromise, and which credentials did we rotate?
5. Who gets the next security bulletin first, and how fast do they act on it?

Take the answers to your insurer and your board before either asks. Then budget upgrades on a calendar instead of as emergencies: our website maintenance cost guide shows what planned support work includes, and a Magento technical audit gives you the baseline.

PHP2Shell FAQ

Is PHP2Shell being exploited?

Exploit attempts are confirmed. Amazon logged the first on October 17, Cloudflare counted millions after disclosure, and CISA added both CVEs to its Known Exploited Vulnerabilities catalog on October 26. Sansec expects mass exploitation to be less likely than it first thought, because the public exploits need specific conditions on the target server. As of October 27, 2026, no break-in at a specific store had been publicly confirmed.

Do I need a Magento patch for PHP2Shell?

No. The flaw is in PHP, so the fix is updating PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restarting every PHP process. You still need Adobe’s October security update, APSB26-153, which fixes BlockStrap and other Magento flaws, but it does nothing for this one.

Does Magento maintenance mode protect against PHP2Shell?

No. Magento handles maintenance mode, and PHP reads the request before Magento runs, which matches the PHP advisory’s warning that the attack can trigger before any application code. Sansec says the same of its own store-level Shield. Taking the server offline or blocking requests at the web server works, while maintenance mode leaves the server just as exposed.

Is Shopify affected by PHP2Shell?

Shopify, BigCommerce and Adobe Commerce as a Cloud Service run and patch their own servers, so the store itself needs nothing from you. Anything you host separately still does: a WordPress blog, a PIM such as Pimcore or Akeneo, custom tools or middleware. Find out which PHP version each one runs, and get the same written confirmation you would ask of a host.

What if my server runs PHP 8.1 or older?

PHP no longer releases updates for 8.1 and older, so there is no official fixed version. Linux distributions and LTS vendors received the patches in advance, and the PHP security team published source backports for 7.4, 8.0 and 8.1. Get a backported build, as we did for one client’s PIM on 8.0, then plan the upgrade. CISA’s advice for systems that can’t be patched is to take them offline.

Does a web application firewall stop PHP2Shell?

A WAF buys time. Cloudflare deployed rules for the known exploit vectors to all its customers, including free plans, and CISA says a WAF may offer interim protection but is not a substitute for patching. It blocks the attack patterns it recognizes, and the flaw stays open behind it until PHP is updated.

Check your PHP version before the next bulletin

PHP2Shell was fixed on October 21, 2026, and the fix only counts on servers where someone installed it, restarted every PHP process and confirmed the build. This week, find out which PHP version and build date each of your systems runs, the store, the PIM, the blog and anything else on PHP, and get the answer in writing from whoever owns each server. Anything below 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or on 8.1 without a backport, goes through the steps above in order. Then use the weeks before Black Friday to fix the handoffs and put PHP 8.2’s December 31 deadline on the plan. StyleSmuggler, BlockStrap and PHP2Shell arrived within seven weeks of each other, so plan for the next one at the same pace.

Send us a list of your systems and who hosts each one, and we'll check the PHP and patch status of all of them, then tell you what we found and what to fix first.

The post PHP2Shell: What the Critical PHP Vulnerability Means for Your Online Store appeared first on scandiweb.

Picking a Magento agency in Canada usually starts with two questions. Does it have an office in your time zone that you can visit, and is Magento its main platform or one more logo on its services page?

We started from about 40 agencies that sell Magento work to Canadian merchants and kept seven. For each one we found the office on its own contact page, looked up its tier in Adobe’s and Hyvä’s directories, and read its Canadian case studies. Where a claim could not be checked, the entry says so.

Top Magento agencies in Canada at a glance

The top Magento agencies in Canada are scandiweb, Valtech, MageMontreal, Kinex Media, TWO DEV, Northern, and Rootways. Each one has an office in Quebec or Ontario that you can find on its own contact page. They differ in partner tier, in how much of their work is Magento, and in whether they publish Canadian case studies with numbers.

Adobe tiers without a note come from Adobe’s directory (searched October 26, 2026). “As stated” means the tier appears only on the agency’s site, and “Not listed” means the search returned nothing. The Hyvä column shows the country each listing is filed under.

How we chose these Magento agencies

We kept an agency when it passed four checks, in this order. An Adobe Commerce partner in Canada with a Platinum tier still fell off if Magento is a sideline or its only Canadian presence is a phone number.

• Magento comes first. Magento or Adobe Commerce leads the agency’s services, and its case studies show Magento builds.
• A Canadian office on the agency’s own contact page. A Canadian phone number on a landing page did not count.
• Named Canadian Magento work or a tier you can check. Canadian Magento clients, a tier in Adobe’s Solution Partner Directory, a tier on Hyvä’s agency finder, or a mix.
• A support plan. Adobe Commerce 2.4.6 left support on August 11, 2026, and every later version has a fixed end date, so someone has to own upgrades after launch.

Most of the 40 fell at the first two checks: Shopify-first studios that keep a Magento page for older clients, general web agencies that list Magento next to WordPress, and offshore firms with a Canadian phone number and no Canadian address. Two well-known names no longer exist as brands: Valtech bought Absolunet in January 2022, and Bounteous absorbed Demac Media in 2018. For agencies outside the country, see our list of global Magento development companies. Our lists for the UK and Australia apply the same checks to other markets.

The 7 best Magento agencies in Canada, profiled

The seven profiles below are in the order we would shortlist them for a mid-market or enterprise Magento store. Each ends with the type of merchant the agency fits best.

1. scandiweb

scandiweb is the world’s most certified Adobe Commerce agency, with 894+ Adobe certifications, Adobe Gold Solution Partner status, and Hyvä Platinum Partner status. It has been an Adobe partner since 2009 and has delivered 2,100+ projects since 2003 for 700+ clients, who rate it at 95 NPS. scandiweb is certified to ISO 9001, ISO 27001, and ISO 27017 and is PCI DSS compliant. Its Hyvä listing is filed under another country on hyva.io, so you will not find it in the Canada section.

In Canada, scandiweb works from a Montreal office. Michael Bliah, VP North America, is based there and is the named contact for Canadian clients, and the Canada team works on Eastern Time. Developers come from the wider certified team, so backend, frontend, and integration work can run at the same time. Our Canada page explains how the team works with Canadian merchants.

Canadian clients named publicly include JYSK Canada and Moose Knuckles, the Canadian outerwear brand. The published Canadian number is PUMA’s: scandiweb’s SEO program grew PUMA’s organic revenue in Canada by 73.98% year over year. JYSK’s Hyvä rebuild is covered in our Hyvä case studies.

Best for: mid-market and enterprise brands that want the deepest certified bench with a Montreal contact, for Hyvä builds, upgrades, and SEO run alongside development.

2. Valtech

Valtech is a global multi-platform consultancy with Canadian offices in Montreal, at 7236 Waverly Street, and Toronto, at 100 University Avenue. In January 2022 it bought Absolunet, the Montreal commerce consultancy with about 300 staff, so Absolunet no longer exists as a brand. Adobe’s directory lists Valtech as a Platinum Solution Partner. It is not on hyva.io, and it also works on Salesforce, commercetools, SAP, and Shopify.

Its strongest Canadian Magento case is Structube, the Montreal furniture retailer with 70+ stores, built as headless Adobe Commerce. Valtech reports a 38% increase in pages viewed per session, a 35% increase in mobile conversion rate, and a 13% increase in desktop conversion rate. For Fountain Tire it built Adobe Commerce with Edge Delivery Services, with the B2B catalog first and B2C after it. We did not find a dedicated support offer on its pages, so ask how support is staffed after launch.

Best for: enterprise Canadian retailers that want headless Adobe Commerce and the wider Adobe stack from one global consultancy.

3. MageMontreal

Despite the name, MageMontreal works from Sainte-Agathe-des-Monts, Quebec, about 100 km north of Montreal. It says it has 19+ years of experience. Adobe’s directory lists it as a Silver Solution Partner working exclusively on Magento, though its own site now also markets Shopify, BigCommerce, and WooCommerce. It is not on hyva.io.

Its Quebec Magento cases come with numbers. For Biron, the Quebec sleep-health and medical equipment company, a Magento 2 rebuild is credited with revenue up 205% from 2024 to 2025. Momo Sports moved to Adobe Commerce Cloud in a Magento 2 rebuild and reports over 300% more sessions. FLB Solution, a Quebec food distributor, had an inherited Magento store rescued with PIM and ERP integration and reports a 35% higher average order value. MageMontreal also sells a dedicated maintenance and improvement service.

Best for: Quebec mid-market and B2B merchants that need Magento with SAP integration, a rescue of an inherited store, or an improvement retainer.

4. Kinex Media

Kinex Media has its head office in Mississauga at 25 Watline Avenue, a Toronto office at 250 University Avenue, and has been in business since 2008. Adobe’s directory lists it as a Silver Solution Partner, and hyva.io lists it as Hyvä Silver, the highest Hyvä tier under Canada. It is a full-service agency, and many of its case studies are WordPress builds, but Magento 2, Adobe Commerce, migration, support, and Hyvä each have their own service page.

Its best Magento case is Ontario Medical Supply, a client since 2013, for which it built a B2B ordering portal on Adobe Commerce 2.4.7 B2B integrated with Pronto ERP. Kinex reports that 100% of online orders transfer to Pronto automatically, that orders reach the ERP about 10 to 20 seconds after checkout, and that the mobile usability score rose from 54 to 93.

Best for: Ontario B2B and B2C brands that want a Hyvä frontend or Adobe Commerce B2B with ERP sync, plus design and marketing from one team.

5. TWO DEV

TWO DEV works from 4000 Saint-Ambroise in Montreal and calls itself an “Alternative eCommerce Agency” built on Adobe Commerce and Akeneo PIM. Every case study on its site is Magento or Adobe Commerce. We found no entry for it in Adobe’s directory, so its Adobe tier is not listed. On hyva.io it is Hyvä Bronze under Canada.

Its Quebec projects are mostly migrations. For Avril Supermarché Santé, the Quebec health-food chain, it moved the store from Magento 1 to Adobe Commerce with a PWA, SAP, and click and collect, and says the full migration took nine months. For SHAN, the Canadian haute-couture brand, it migrated Magento 1 to 2 with Cegid, Mirakl, and a Canada Post integration. For Bicycles Quilicot, the Montreal bike store founded in 1915, it took over maintenance first and then rebuilt the store on Magento 2 with Lightspeed and Akeneo. None publishes metrics, so ask for numbers. Its site promises the team is available 24/7, all year.

Best for: Quebec retailers on Adobe Commerce with Akeneo PIM who want a small senior team and round-the-clock support.

6. Northern

Northern, formerly Northern Commerce, has its head office in London, Ontario, with offices in Toronto and Edmonton. Adobe’s directory lists it as a Gold Solution Partner. It is not on hyva.io. The agency now positions itself around content, data, and operations, so Magento is one practice among several.

Its published Magento 2 case is Andrew Peller, the Canadian winery group, for which Northern reports a 132% increase in mobile revenue and a 28% increase in conversion rate. We could not confirm a support offer on its site, so ask what the support model looks like.

Best for: Canadian brands that want Adobe Commerce alongside content and data work from one Ontario team.

7. Rootways

Rootways works from 2970 Drew Road in Mississauga and has done Magento-led development and support since 2010. It describes itself as an Adobe Bronze Solution Partner, a tier we could not find in Adobe’s directory, so treat it as stated by the agency. It is not on hyva.io.

It sells its own Magento extensions for Canada Post, Purolator, and Day & Ross shipping. Its portfolio includes Canadian Magento stores such as Dimar Canada, a B2B store on Magento 2, Firearms Outlet Canada, and The Pacific Smoke, with no published metrics.

Best for: smaller Canadian Magento stores that need Canadian shipping extensions and affordable support.

Two more names deserve a line. Novatize in Quebec City, an Adobe Silver partner, built a Magento 2 B2B platform for Groupe LD but now leads with Shopify Plus. Bounteous, an Adobe Platinum partner, absorbed Demac Media in 2018, but we found no current Canadian Adobe Commerce case on its site.

Magento agencies in Montreal, Toronto, and the rest of Canada

Six of the seven agencies have an office in Montreal or the Greater Toronto Area. Montreal has scandiweb, Valtech, and TWO DEV, with MageMontreal about 100 km north. The GTA has Valtech, Kinex Media, Rootways, and Northern’s Toronto office. The rest of Canada is served remotely from those two regions, plus Northern’s offices in London, Ontario and Edmonton.

Montreal and Quebec

Four of the seven are in or near Montreal. scandiweb’s Montreal office is the base for its VP North America, Valtech is on Waverly Street, and TWO DEV is on Saint-Ambroise. A workshop with MageMontreal means a drive to Sainte-Agathe-des-Monts. If you need a Magento agency in Montreal with Quebec case studies, Valtech, TWO DEV, and MageMontreal all publish them.

Toronto and the GTA

For Magento developers in Toronto or Magento website development in Mississauga, there are four agencies with offices: Valtech and Kinex Media on University Avenue, Kinex’s head office and Rootways in Mississauga, and Northern’s Toronto office. scandiweb has no Toronto office and serves the GTA from Montreal on the same Eastern Time, as our Magento agency in Toronto page explains.

Elsewhere in Canada

Northern is the only agency on this list with offices outside Quebec and the GTA, in London, Ontario and Edmonton. None of the seven has a Vancouver or Calgary office, so a Magento developer in Calgary or Vancouver on this list means working remotely with an Ontario or Quebec team.

What a Magento agency in Canada should handle

A Canadian Magento agency should handle six things a US or European build does not, and raise them before you do: French for Quebec, sales tax by province, Law 25 consent, AODA accessibility, Canadian payment gateways, and Canadian carriers. Statistics Canada puts retail eCommerce sales at $5.6 billion in August 2026, 7.6% of total retail trade, seasonally adjusted, according to its Retail trade, August 2026 release.

• French in Quebec. Under the Charter of the French Language as amended by Bill 96, commercial websites must be available at least in French, with no other language more prominent, since June 1, 2022. Online terms must be provided in French first since June 1, 2023, and new product-labeling rules for trademarks started June 1, 2025, with a sell-through period for older stock to June 1, 2027, according to the OQLF. In Magento that means a French store view, French checkout emails, and French terms rather than a translated banner.
• Sales tax by province. GST is 5% in Alberta, BC, Manitoba, Quebec, Saskatchewan, and the territories. HST is 13% in Ontario, 15% in New Brunswick, Newfoundland and Labrador, and PEI, and 14% in Nova Scotia since April 1, 2025. On top of GST, BC charges 7% PST, Saskatchewan 6% PST, Manitoba 7% RST, and Quebec 9.975% QST, per the Canada Revenue Agency. Ask to see a test order into each province.
• Privacy. Quebec’s Law 25 phased in from September 22, 2022 to September 22, 2024. Since September 2023, consent must be explicit for each purpose, tracking and profiling tools must be off by default, and penalties reach $10 million or 2% of worldwide turnover, according to the Commission d’accès à l’information. This changes how analytics, pixels, and personalization load on a Quebec storefront.
• Accessibility. In Ontario, businesses with 50+ employees must meet WCAG 2.0 Level AA on public websites under the AODA, and organizations with 20+ employees file their next accessibility compliance report by December 31, 2026, per the Government of Ontario.
• Payments. Interac Online has been discontinued in favor of Interac Debit for online payments and the Konek wallet, and PayBright is now Affirm. Moneris and Worldline (formerly Bambora) are common gateways. Ask which module the agency uses for each and who maintains it.
• Shipping. Canada Post and Purolator both offer developer APIs, and their Magento modules come from third parties rather than the carriers. Ask which module the agency uses and who updates it when the carrier API changes.

How to choose a Magento agency in Canada

Choose a local Magento specialist when your store serves Canada with one main workstream and an ERP that already works. Choose a larger certified Adobe Commerce partner when several workstreams run at once, when you sell outside Canada too, or when one developer leaving would stop your launch.

Choose a local Magento specialist if:

• You run one Canadian store, with English and French store views at most
• The project has one main workstream, such as a Hyvä rebuild or a 2.4.x upgrade
• Your ERP or PIM is already connected and stable
• You want the same people in every meeting and a short drive to the office
• Your budget fits a small team better than an enterprise program

Choose a larger certified Adobe Commerce partner if:

• You need backend, frontend, integrations, and SEO running at the same time
• You sell in the US or Europe as well as Canada and want one instance for all of it
• A developer leaving or on vacation cannot delay your launch
• You want tiers and certifications you can check in Adobe’s and Hyvä’s directories
• You need support cover for incidents outside Eastern Time business hours

If the answer depends on what your ERP and PIM should do after launch, we can map your target architecture first, so every agency quotes against the same picture.

Questions to ask before you sign

A Magento development company in Canada that has done this before will answer these on the first call, with links.

• Which Adobe Solution Partner tier do you hold, and can you send the directory link?
• What is your Hyvä tier, and which country is it listed under on hyva.io?
• Which office will run our account, and which hours does the delivery team overlap with Eastern Time?
• Which French storefronts have you launched for Quebec, and can we see one live?
• How will you set up GST, HST, PST, RST, and QST, and can we see a test order into each province?
• How do you handle Law 25 consent, and what loads before the shopper accepts cookies?
• Which Adobe Commerce version will we run? Under Adobe’s lifecycle policy, 2.4.7 leaves support on May 31, 2027, 2.4.8 on May 31, 2028, and 2.4.9 on May 31, 2029.
• Who owns the code, the repository, and the hosting account when the contract ends?

What does Magento development in Canada cost?

Magento development in Canada is priced in three ways: fixed quotes for builds, migrations, and Hyvä projects, monthly retainers for support, and hourly or daily rates for open-ended work. The drivers that move a Canadian quote most are a French store view, ERP or PIM integration, B2B features, provincial tax setup, and the Adobe Commerce license. Send the same scope to three agencies. The one that itemizes the French store view and the tax setup has probably done it before. Our Magento pricing guide covers license, build, and support costs in detail.

Frequently asked questions about Magento agencies in Canada

What are the best Magento agencies in Canada?

The strongest picks with a Canadian office you can check are scandiweb, Valtech, MageMontreal, Kinex Media, TWO DEV, Northern, and Rootways. scandiweb leads on certifications and Hyvä, Valtech on headless enterprise builds, MageMontreal and TWO DEV on Quebec work, and Kinex Media on Ontario B2B with the only Hyvä Silver tier in Canada.

How much does Magento development in Canada cost?

It depends on the scope. Canadian agencies quote fixed prices for builds, migrations, and Hyvä projects, monthly retainers for support, and hourly or daily rates for ongoing work. Send every agency the same written brief so the quotes compare like for like.

Which Canadian agencies are Hyvä partners?

Hyvä’s directory lists two agencies under Canada: Kinex Media at Silver and TWO DEV at Bronze. Larger Hyvä partners serve Canadian stores from elsewhere. scandiweb, for example, is a Hyvä Platinum Partner with a Montreal office, but its hyva.io listing is filed under another country. Ask any agency which country its listing shows before you count the badge.

Does my Magento store need a French version for Quebec?

Yes, if you sell to consumers in Quebec. Since June 1, 2022, commercial websites must be available at least in French under the Charter of the French Language, and since June 1, 2023, online terms must be provided in French first. In Magento, that means a French store view with French checkout emails and French terms.

Do I need a Magento agency with an office in Canada?

Not always, because most development runs remotely. A Canadian office helps with Eastern Time overlap, in-person workshops, and Quebec language and privacy questions. Ask for a named Canadian contact and the hours the delivery team overlaps with yours.

What is the difference between a Magento agency and an Adobe Commerce agency?

The skills are the same. Adobe Commerce is the licensed edition of Magento and Magento Open Source is the free one, both built on the same codebase, so an agency that works on one works on the other. Our guide to Magento Open Source vs Adobe Commerce explains the trade-offs.

Choosing from the top Magento agencies in Canada

The top Magento agencies in Canada fit different stores. scandiweb fits brands that want the deepest certified bench and Hyvä with a Montreal contact, and Valtech fits enterprise retailers on headless Adobe Commerce. MageMontreal and TWO DEV fit Quebec merchants with SAP or Akeneo, Kinex Media fits Ontario B2B with a Hyvä frontend, Northern fits brands that want content and data work, and Rootways fits smaller stores that need Canadian shipping extensions. Pick three, send them the same brief, and check every tier yourself. If you also sell in the UK, our list of Magento agencies in the UK covers that market the same way.

Talk to our Montreal team about your shortlist, and a Magento lead will tell you which agency fits your store, including when that is another name on this list.

The post Top Magento Agencies in Canada (2026) appeared first on scandiweb.

Adobe Commerce 2.4.6 left support on August 11, 2026, and 2.4.7 follows on May 31, 2027. A store on either version needs an upgrade soon, and the Magento agency in Australia that runs it will probably look after the store for years afterwards.

We checked about 45 agencies that sell Magento work in Australia, each against Adobe’s Solution Partner Directory and Hyvä’s directory, then against the agency’s own contact and case study pages. Eight passed. Every fact below comes from those sources, and where something could not be checked, we say so.

Top Magento agencies in Australia at a glance

The top Magento agencies in Australia are scandiweb, Aligent, Balance Internet, Acidgreen, Overdose, OSE, Netable Australia, and Magenable. They differ in Adobe tier, Hyvä listing, office city, how much Australian Magento work each one publishes, and where the developers work.

Adobe tiers for Aligent, Balance Internet, Acidgreen, and Overdose come from Adobe’s directory (checked October 26, 2026), scandiweb’s and Netable’s from their own sites, and the Hyvä column from hyva.io. Ask every agency for its directory link before you sign.

How we chose these Magento agencies

We kept the agencies that pass four checks, in this order. About 45 went in, and most fell out at the first or second check.

• Magento comes first. Magento or Adobe Commerce leads the agency’s services, and its published case studies are Magento builds.
• A way to work in Australian hours. An office on the agency’s own contact page or a stated same-day AEST working window, with named people behind it.
• Named Australian Magento work or a tier you can check. Australian Magento clients, an Adobe Solution Partner tier in Adobe’s directory, a Hyvä tier on hyva.io, or a mix.
• A support plan after launch, so every later upgrade has an owner.

The names that dropped out were general web studios that list Magento next to WordPress and Webflow, agencies that now lead with Shopify (Convert Digital is a Shopify Platinum partner), and eWave, which Globant absorbed. For agencies outside Australia, our list of global Magento development companies applies the same checks. For other markets, see our lists for the UK and Canada.

The 8 best Magento agencies in Australia, profiled

Each profile gives the office from the agency’s own site, the partner tiers we could check, the Australian Magento work it publishes, and the kind of merchant it fits.

1. scandiweb

scandiweb is the world’s most certified Adobe Commerce agency, with 894+ Adobe certifications, Adobe Gold Solution Partner status, and Hyvä Platinum Partner status. We have been an Adobe partner since 2009 and have delivered 2,100+ projects since 2003 for 700+ clients, who rate us at 95 NPS. We hold ISO 9001, ISO 27001, and ISO 27017 certifications and are PCI DSS compliant.

Australian merchants work with our global team remotely, with a same-day working window on AEST and delivery in English, as our page for Magento Developers in Australia explains. Our Hyvä Platinum listing is not under Australia, so a search of hyva.io by country will not show it.

Our published proof is international. When Scouting America moved from a legacy Luma storefront to Hyvä, average order value rose 27.3% year on year, checkout starts rose 23.9%, and LCP improved by 12–13%. The full numbers are in Scouting America’s Hyvä rebuild.

Best for: merchants that want the deepest certified bench, a Hyvä theme build, or an upgrade run by a large team, and are comfortable with remote delivery.

2. Aligent

Aligent is an Adelaide agency at Level 1, 212 Pirie Street, working since 2008. Adobe’s directory shows it at Silver with the award Adobe APAC Partner of the Year 2025. It is not listed on hyva.io.

Aligent is multi-platform: Adobe Commerce is listed first, then BigCommerce, Shopify Plus, and Fluent Commerce order management. For The Athlete’s Foot in Australia and New Zealand, a headless Adobe Commerce build, Aligent reports +26% conversion, +$10 AOV, and 21% faster average page load. For Rockwear, a headless PWA on Adobe Commerce, it reports click and collect adoption above 30% and real-time inventory across almost 100 stores. Aligent offers ongoing 24/7 support and BAU support.

Best for: enterprise retailers and B2B merchants on Adobe Commerce, headless builds, and OMS integration.

3. Balance Internet

Balance Internet is in Southbank, Melbourne, at the address on its Adobe directory profile. It was founded in 2008 with roots in Magento and has been part of Publicis Groupe since 2021. Adobe’s directory lists it at Platinum, the only Australian-headquartered commerce agency at that tier, and its profile lists health checks, technical support, implementation, integration, and hosting. It is not listed on hyva.io.

Its own website could not be read on our research date, so this profile has no named client or metric. Ask for recent Australian references.

Best for: large retail, education, and government programs that want a Platinum partner with a global network behind it.

4. Acidgreen

Acidgreen is at 100 Market Street, Sydney, with a Melbourne contact by phone. It was established in 2000, has been owned by France’s DATASOLUTION since 2019, and says it was one of the first Magento partners in Australia. Adobe’s directory lists it at Silver, and its profile cites over 60 Magento 2 builds, upgrades, or replatforming projects. It is not on hyva.io. It also sells Shopify, BigCommerce, OroCommerce, and Pimcore and Akeneo PIM.

For Legend Corporation, an electrical and industrial products group, Acidgreen launched 13 websites in six months on a single Magento 2 backend, integrated with SAP, a PIM, Salesforce, and Mirakl. For Woolworths Plus Club, a members-only portal on Magento Open Source for 250k+ eligible employees, it reports four to five years of continuous maintenance with zero major security incidents.

Best for: B2B and multi-brand Magento estates that need PIM and ERP integration.

5. Overdose

Overdose has three Australian offices: South Yarra in Melbourne, 388 George Street in Sydney, and 200 Adelaide Street in Brisbane. Its headquarters are in Auckland, where it was founded in 2016. Adobe’s directory lists it at Silver (its own profile text still says Gold). It is not on hyva.io. Overdose lists Shopify Plus first, then Adobe Commerce, commercetools, and BigCommerce, and its Adobe page says “The answer is not always another Adobe build.”

On Adobe Commerce it reports a 45% increase in conversion rate and a 20% increase in average order value for Camera House, and it lists Petbarn and Signet as Adobe Commerce clients.

Best for: ANZ retailers that want Adobe Commerce alongside growth marketing, and an honest stay-or-move recommendation.

6. OSE

OSE is an Australian-owned agency at 4/110 Eagle Street, Brisbane. Its site does not state an Adobe tier, and it is not on hyva.io, so ask for both. Adobe Commerce is its first service, with Shopify Plus second, and all three of its published case studies are Adobe Commerce builds. For Pedders, on Adobe Commerce with Pronto ERP, OSE reports a 150% increase in brake, steering, and suspension check inquiries across 120+ stores. For Unique Health Products, an Adobe Commerce B2B store, it reports 52% of total sales processed online and about a 4.4% increase in average order value. It publishes four support tiers with agreed service levels.

Best for: mid-market and enterprise retailers and wholesalers on Adobe Commerce with Pronto ERP who want SLA-backed support.

7. Netable Australia

Netable Australia is in Moorabbin, Melbourne, and has been in business for about 21 years. It is the one agency on this list with a Hyvä listing under Australia, at the entry Partner tier. Its site shows an Adobe Bronze Partner badge, which we could not confirm in Adobe’s directory. Netable is Magento-led, covering support, integrations, migrations, hosting, and B2B, and it takes over existing Magento stores from other agencies.

Its published work includes Minidisc on Hyvä with Cin7, with a PageSpeed score above 90, and Build-A-Bear Workshop, supported for over 12 years including the Magento 1 to 2 move.

Best for: mid-market B2B and B2C merchants that need ERP integration with NetSuite, SAP Business One, or Pronto, and long-term support.

8. Magenable

Magenable is in South Melbourne, with management and consulting in Melbourne and the development team overseas. It does not state an Adobe tier, is not on hyva.io, and focuses on Magento, Adobe Commerce, and BigCommerce. Published work includes Access Hardware, a B2B store on Adobe Commerce Cloud, Bondi Sands, for maintenance and development, and Dahlsens, a data center migration with close to zero downtime. Magenable publishes no metrics, so ask for numbers from a comparable project.

Best for: B2B merchants that want a small, director-led Magento consultancy.

A few more names are worth knowing. webqem in North Sydney is Hyvä Bronze and Adobe Silver and reports revenue up 110% for 99 Bikes on Adobe Commerce, but it now sells Shopify, Webflow, and WooCommerce as widely as Magento. Rival Ecommerce in Sydney is Hyvä Bronze and Magento-first, but publishes no client metrics. Krish TechnoLabs (Sydney) and 18th DigiTech (Baulkham Hills) are both Adobe Gold with Australian offices and delivery teams in India.

Magento agencies in Sydney, Melbourne, Brisbane, and Adelaide

Melbourne and Sydney have the most Magento agencies on this list, Brisbane has two, and Adelaide has one. The city matters for workshops and launch week. Day-to-day development matters less by city, because most Magento work in Australia runs remotely.

Magento agencies in Sydney

Sydney has Acidgreen, established in 2000, and Overdose’s George Street office, plus the two Hyvä Bronze partners Rival Ecommerce and webqem. For a Magento developer in Sydney working on a B2B or multi-brand estate, Acidgreen’s Legend Corporation project is the published reference.

Magento agencies in Melbourne

Melbourne has four: Balance Internet in Southbank (Adobe Platinum), Netable Australia in Moorabbin (the Hyvä-listed pick for ERP work), Magenable in South Melbourne, and Overdose in South Yarra. For a Magento developer in Melbourne, that is a Platinum partner, a Hyvä partner, a consultancy, and a growth agency to compare on one brief.

Magento agencies in Brisbane

Brisbane has OSE on Eagle Street and Overdose on Adelaide Street. If you are looking for Magento developers in Brisbane with agreed service levels after launch, OSE publishes four support tiers.

Magento agencies in Adelaide

Adelaide has Aligent on Pirie Street, whose headless builds for The Athlete’s Foot and Rockwear are the references for enterprise retail. None of the agencies on this list has a Perth office, so a Magento developer in Perth usually means working remotely with an east-coast team.

What a Magento agency in Australia should handle

An Australian store has rules that a build for another market does not, and a good agency will raise them in the first call. Australians spent $82.6 billion online in 2025, up 14% year on year, and 24% of all retail spend is now online, according to the Australia Post 2026 eCommerce Report. The points below are the ones to check.

• GST. Australian GST is 10% on most goods and services, and overseas sellers have collected GST on goods worth A$1,000 or less sold into Australia since July 1, 2018 (ATO). Magento’s tax rules need to match.
• Buy now, pay later. Zip publishes an open-source Magento 2 plugin. For Afterpay, confirm with the agency and with Afterpay which Afterpay integration your store will use.
• Delivery. 69% of shoppers want a range of delivery options at checkout, including parcel lockers, per the same Australia Post report. Australia Post offers shipping and tracking APIs for eParcel contract customers, and there are Australia Post extensions on the Adobe Commerce Marketplace.
• Checkout pricing from July 1, 2027. The Competition and Consumer Amendment (Unfair Trading Practices) Act 2026 bans drip pricing, where mandatory fees are added late in checkout, from that date (Parliament of Australia bills digest). Mandatory fees must show up front in cart and checkout.
• Privacy. From December 10, 2026, privacy policies must explain the kinds of personal information used in computer-made decisions that could significantly affect people (OAIC). That covers personalization and fraud rules.
• Selling to government. Commonwealth entities pay Peppol eInvoices within 5 days, versus 20 for other invoices, which matters if your B2B store sells to government.
• Accessibility. The Disability Discrimination Act covers online services. Aim for WCAG 2.2 AA as practice, and ask the agency which of its live stores it has tested against it.

How to choose a Magento agency in Australia

Choose a local Magento specialist when the project has one main workstream and you want a team you can meet in person. Choose a larger certified Adobe Commerce partner when backend, frontend, and integrations run in parallel, or when one developer leaving would put your launch at risk.

Choose a local Magento specialist if:

• You run one Australian store, or Australia plus New Zealand
• The project has one main workstream, such as a Hyvä frontend or a 2.4.x upgrade
• Your ERP is already connected and stable
• You want the same people in every meeting, in your time zone
• Your budget fits a small team better than an enterprise program

Choose a larger certified Adobe Commerce partner if:

• You need backend, frontend, integrations, and SEO running at the same time
• You plan to add markets or brands on the same Adobe Commerce instance
• A developer leaving or going on leave cannot delay your launch
• You want tiers and certifications you can check in Adobe’s and Hyvä’s directories
• You need support that covers AEST business hours and out-of-hours incidents

If the choice depends on how your ERP, payments, and marketplaces connect today, we can map your target architecture before any agency quotes.

Questions to ask before you sign

A good Magento development company in Australia will answer these in the first call and send links where it can. Compare the answers across your three.

• Which Adobe Solution Partner tier do you hold, and can you send the directory link?
• What is your Hyvä tier, and which country is it listed under?
• Where does the team on our project work, and which hours overlap with AEST?
• Which Australian stores have you launched in the last two years, and can we see one live?
• Which ERPs (Pronto, NetSuite, SAP Business One) have you integrated with Magento, and can we talk to the merchant?
• Which Adobe Commerce version will we run? 2.4.7 leaves support on May 31, 2027, 2.4.8 on May 31, 2028, and 2.4.9 on May 31, 2029.
• How will mandatory fees show in cart and checkout before July 1, 2027?
• Who owns the code, the repository, and the hosting account?

What does Magento development in Australia cost?

Agencies price Magento work three ways: fixed quotes for builds, migrations, and Hyvä projects, monthly retainers for support, and hourly or daily rates for open-ended development. The total depends on catalog size, store views, integrations, and your edition, because Adobe Commerce carries its own license.

Send two or three agencies the same written scope, including GST, BNPL, Australia Post, and the July 2027 checkout changes, and compare how precisely each one answers. Our Magento pricing guide breaks down license, build, and support costs line by line.

Frequently asked questions about Magento agencies in Australia

What are the best Magento agencies in Australia?

The eight that passed our checks are scandiweb, Aligent, Balance Internet, Acidgreen, Overdose, OSE, Netable Australia, and Magenable. Balance Internet is the only Australian-headquartered Adobe Platinum partner, Aligent and Acidgreen are Silver, Netable is the one Hyvä partner listed under Australia, and scandiweb has the deepest certified bench and works remotely. The right pick depends on your edition, your ERP, and how much of the team you need on AEST.

How much does Magento development in Australia cost?

It depends on scope. Agencies quote fixed prices for builds and migrations, retainers for support, and hourly or daily rates for ongoing work, and catalog size, integrations, and the Adobe Commerce license set the total. Give each agency the same written brief so the quotes compare like for like.

Which Australian agencies are Hyvä partners?

Hyvä’s directory lists five agencies under Australia: 23 Digital, Gold Coast Ecommerce, Rival Ecommerce, and webqem at Bronze, and Netable Australia at Partner tier. No Silver, Gold, or Platinum Hyvä agency is listed under Australia, so the larger Hyvä partners, scandiweb at Platinum among them, serve Australian merchants remotely. Our list of Hyvä theme development companies covers the global tiers.

Do I need a Magento agency with an office in Australia?

Not always. An Australian office helps with workshops, launch week, and same-day contact, but most Magento development runs remotely, and several agencies with Sydney or Melbourne addresses deliver from other countries. Ask where the developers work and which hours overlap with AEST. A remote team with a same-day window can serve you as well as a local office with an offshore bench.

Is Magento still a good choice for Australian retailers?

Yes, if your store needs catalog depth, B2B features, or ERP integration. Adobe Commerce 2.4.9 is supported to May 31, 2029 under Adobe’s lifecycle policy, and Magento Open Source is free to license, with the cost in build, hosting, and support. Our piece on whether Magento is dying covers the question in detail.

What is the difference between a Magento agency and an Adobe Commerce agency?

There is no difference in skills. Adobe Commerce is the licensed edition of Magento and Magento Open Source is the free edition, and both run on the same codebase. Our guide to Magento Open Source vs Adobe Commerce covers the differences between the two editions.

Choosing from the top Magento agencies in Australia

The top Magento agencies in Australia fit different stores. scandiweb fits a Hyvä build or a large upgrade with a certified remote team, Aligent fits enterprise retail on headless Adobe Commerce, and Balance Internet fits large programs that want a Platinum partner. Acidgreen fits multi-brand B2B estates, Overdose fits ANZ retail with growth marketing, and OSE fits Adobe Commerce with Pronto. Netable Australia fits ERP-heavy mid-market stores, and Magenable fits merchants that want a small consultancy. Pick three, send them the same brief, and check every tier yourself. If you also sell in the UK, our list of Magento agencies in the UK runs the same checks there.

If you have a shortlist of Australian agencies and want a straight answer, send us the names and your brief. A Magento lead will reply with the one that fits, even when it is another agency.

The post Top Magento Agencies in Australia (2026) appeared first on scandiweb.

We recently hosted a webinar on product data – what it costs a business when product information is spread across spreadsheets, inboxes, the ERP, and the eCommerce backend, and what the fix looks like on real projects.

One story from the session shows the problem better than any definition. A retailer’s eCommerce team kept learning about new products from customers tagging them on Instagram. The products were already on the shelves and the data was already in the ERP, but nobody told the eCommerce team. Three to five days later someone retyped the details by hand into a spreadsheet, then waited for copy and images from a third party. About 40% of that retailer’s range was not for sale online. We’ll recap the main points of what this means in this article, or you can watch the recording here:

How many places is your product data in

Two to five, for most webinar attendees, according to the poll result when Ana asked how many places they store or manage product information today. When you need a product detail, how many places do you go to get it? Usually more than one.

Product data arrives from suppliers, factories, the ERP, content teams, and translators. It lands in spreadsheets, inboxes, shared drives, and the eCommerce backend. Every copy drifts a little from the others, and after a while nobody is sure which version is right. Each new sales channel adds one more place to keep updated.

Where the cost shows up

Manual work

There are usually teams of one to five people whose only job is managing product data by hand. That is a payroll cost before anything else, and it grows with every new market and channel.

Late launches

During the webinar, hosts used an example of a North American manufacturer with a large store network. One full-time employee creates products in the eCommerce system. For each product he contacts roughly nine departments. He asks marketing for photos, content for descriptions, and the product team for ingredients and manufacturing data, then goes back to marketing to turn those ingredients into language a shopper understands. The company adds few products a season, and launching one is still a project.

Often the information exists. It is in a manufacturing format that cannot go straight onto a product page, and the enrichment step gets stuck between approvals, marketing, legal, and translation.

Lost sales

The retailer above was missing 40% of its range online. A US distributor of packaging and industrial supplies had only 10% of a large catalog on its site before its PIM project, with descriptions and images missing on part of that. Its full range is online now. Every day a product is on the shelf and not on the site is a day of revenue the business does not get.

Returns

Wrong or missing product information means customers get something they did not expect, and they send it back. The return is a lost sale plus the cost of handling it.

The reverse holds too. For Sportland, user research showed product pages were short on descriptions. scandiweb redesigned the pages, expanded the attribute sets in the PIM, reworked the size guides, and A/B tested the result. The new product page, which the team calls the super PDP, lifted sales by 39%.

Growth and AI

Every new market, channel, or product multiplies the places that need updating, so a setup that works today becomes a brake as the catalog grows. AI has the same problem. It handles messy data better than it used to, but with three versions of the same product it cannot tell which one is true.

What the fix looks like

One record per product, with the descriptions, images, documents, translations, and approval workflows attached to it. Every channel reads from that record.

It’s like a spreadsheet row with anywhere from 20 to several hundred fields, where each department owns its own cells. The photographer uploads images in their own view. The designer assigns images to products. The content team writes the descriptions. Teams can work inside the PIM or keep the tools they already use and connect them through an API, as long as the PIM holds the master copy.

Companies are organized by function, and product information does not belong to any one function. It is between several teams, so it needs a shared place where each team adds its part without making a mess somewhere else.

A product’s journey through a PIM

Here are the four stages a product passes on its way from a supplier file to a customer’s screen, with screens from live projects.

Getting data in

One client takes product data from many suppliers, each in a different format, and did not want to change how those suppliers work. So each supplier got an SFTP folder. They drop in their XML files, the client’s team runs the import, and the products appear in the PIM.

Not every supplier sends XML or has an API. Some send PDFs. Maris said AI extraction now pulls product data from those with good accuracy.

The PIM then normalizes what came in. A US packaging distributor sells box tape that suppliers list as either 5 centimeter or 2 inch. Its customers search in inches, so every tape now shows as 2 inch and sits in the same results. The same applies to shoe sizes or clothing sizes, and to any attribute that arrives in more than one standard.

Attribute sets define which fields every product of a type needs, with validation, so a new team member creates a product the same way as everyone else. Variants inherit everything from the parent product except what makes them different, such as color and size.

A food, drink, and restaurant equipment supplier in Latvia and Estonia ran several domains on two platforms, with ERP data moved between them by hand. scandiweb consolidated the domains into one store, added a Pimcore PIM with a two-way sync to SAP, and gave suppliers a file upload with automated product creation behind it. Over 20,000 products moved into the new setup, and the suppliers kept working the way they were used to.

Enriching it

In Pimcore, the asset management and the PIM are linked, so a size guide or spec sheet is dragged in once and connected to its product. Nobody hunts for the right file later.

Descriptions can be generated from the product’s attributes and images with AI, at least as a draft, and editing a draft is faster than starting from a blank page.

Translations run per language, get reviewed and approved, and update the main product and every variant that inherits the text. scandiweb has also built scheduled AI translation across an entire catalog for some clients.

Controlling it

Once data is in and enriched, user roles, permissions, and workflows decide what goes out. If a product is not approved, it does not reach the customer.

A Lithuanian cosmetics retailer had product data in its eCommerce platform and ERP, plus a few spreadsheets, with several teams needing to sign off before anything went live. In Pimcore, scandiweb set up roles for supplier managers, product data managers, the eCommerce team, and the translation team. A new product arrives from the ERP with its SKU, price, and stock level, and the right person gets notified. They fill in the attribute set, the supplier manager adds what they know about the brand, translations are reviewed and approved, and the product goes live. Price and stock changes from the ERP update the record on their own.

Reports show what is pending approval and which products are missing which fields in which language, so the person responsible opens the right product straight from the list.

Distributing it

The record feeds the website, marketplaces, print catalogs, distributors, and franchisees. For external partners, a brand or partner portal is safer than a backend login. They see the data and assets you choose, download what they need, and build collections for their own team.

One school photography company used the same approach for more than product data. Student and staff records and the photos themselves lived in different repositories and went out by email. scandiweb built a master data backbone in Pimcore with single sign-on, plus a portal where each school logs in, downloads its photos, and edits or uploads student and staff records without seeing anyone else’s.

What a PIM project takes

Discovery first. Every team has different data, workflows, stakeholders, and output channels, so scandiweb starts by mapping how the business works today and how it wants to work. Only then come the data model, the data cleanup, the system connections, and the training and rollout. scandiweb uses Pimcore for many of these projects because it bends to the way a team already works.

Our rule is to find the gap the PIM fills and shape the PIM around the existing teams. If the goal is only to put product data in one place, the project can be fairly simple. If the content has to be created inside the system, as with a fashion brand where photo shoots and image approvals need defined roles at each stage, it is more involved. Most projects land somewhere between the two.

If you want to see how a PIM would handle your own catalog, request a free PIM prototype. Upload a sample spreadsheet if you have one, and our team will build the prototype on your data and walk you through it, including how different roles see different parts of the catalog.

The post Webinar Recap: What Fragmented Product Data Costs You & How to Fix It appeared first on scandiweb.

If your Adobe Commerce renewal is coming up and someone has asked why you pay for software that also comes in a free edition, the honest answer starts with an inventory. You can downgrade Adobe Commerce to Magento Open Source, because both editions share the same core. The license line disappears. What you get back depends on how many Commerce-only features your team uses every week, and on whether you also leave Adobe’s cloud hosting.

It’s one of the questions our clients ask most often this year, usually together with a second one: Cloud, on-premise, or ACCS, what are we paying for? Both have the same starting point. List the Commerce-only features your team uses, find a replacement for each, and set the total cost against three more years of license fees, well before the renewal date.

What you lose when you downgrade Adobe Commerce to Magento Open Source

When you downgrade Adobe Commerce to Magento Open Source, you lose the B2B suite, content staging and scheduled updates, customer segments, Live Search, Product Recommendations, gift cards, store credit, reward points, and returns management. You keep the catalog, customers, orders, checkout, Page Builder, multi-store setup, and most of your custom code. Data stored by the removed features has to be exported or migrated first.

These are the features that change the decision. For the full edition-by-edition feature list, see our Magento Open Source vs Adobe Commerce comparison.

B2B features: company accounts, quotes, and approvals

If you sell to companies through Adobe Commerce, the B2B suite is the first thing to check. Company accounts with buyer roles, shared catalogs with customer-specific prices, negotiable quotes, purchase order approvals, requisition lists, and company credit are all part of B2B for Adobe Commerce, which installs on top of the Commerce license. Our overview of Adobe Commerce B2B features covers what each one does.

On Open Source, these come from third-party extensions or custom work, and the data does not move by itself. Open quotes, approval rules, and company hierarchies have to be exported and rebuilt in the new module. A B2C store with a wholesale price list in a customer group usually loses nothing here. A distributor whose buyers request quotes every day loses a working sales process.

Content staging and scheduled updates

Content staging lets merchandisers schedule price changes, banners, and category updates for a future date and preview them before they go live. Open Source has no staging, so scheduled campaigns stop running after the switch, and marketing goes back to publishing changes by hand or through an extension.

Staging also changes the database. To keep versions, Adobe Commerce stores products, categories, CMS pages, and blocks under a row_id key with several rows per entity, where Open Source uses one row per entity_id. That difference makes the move a database project as well as a code change, which the project section below covers.

Live Search and Product Recommendations

Adobe lists Live Search as supported on Adobe Commerce on Cloud and on-premises, version 2.4.4 and later, according to the Live Search installation guide. Magento Open Source isn’t on that list, and Product Recommendations has the same scope. After a downgrade, storefront search goes back to OpenSearch, which comes with Magento, and your synonyms, merchandising rules, and recommendation units need rebuilding in whatever you choose next.

For a store with a small catalog, OpenSearch with good attribute setup is often enough. For a large catalog where search drives most sales, budget for a third-party search service, which is a subscription priced by usage.

What you keep after a downgrade

The core stays the same, so most of the store survives:

• Catalog, customers, order history, and CMS content, once the database is converted
• Checkout, payment and shipping integrations, and multi-store setup
• Page Builder, which has been in Magento Open Source since version 2.4.3
• Adobe Payment Services, which Adobe lists as compatible with Open Source 2.4.4 and later
• A Hyvä storefront, since the Hyvä Theme became free and open source in November 2025
• Custom modules, unless they extend Commerce-only classes

Adobe Commerce Cloud vs on-premise vs ACCS: what you pay Adobe for

With Adobe Commerce on-premise, you pay Adobe for the Commerce code and support, and you run the hosting. With Adobe Commerce on Cloud, the license also covers managed infrastructure: hosting environments, Fastly CDN with WAF and DDoS protection, and New Relic monitoring, while your team still owns the codebase and upgrades. With Adobe Commerce as a Cloud Service (ACCS), Adobe runs the application as well and upgrades it for you.

Our guide to Adobe Commerce Optimizer, SaaS, PaaS, and on-premise compares the four Adobe editions in detail. For a downgrade decision, two of them matter most.

Moving from Cloud to on-premise keeps the features

If the license is the problem and the features are not, moving from Adobe Commerce on Cloud to Adobe Commerce on-premise may solve it with less work. Based on aggregated partner estimates, the on-premise license runs roughly $22,000 to $125,000 a year, against roughly $40,000 to $190,000 for Cloud. Adobe doesn’t publish prices, so treat these as planning anchors.

You keep B2B, staging, and Live Search, the database stays as it is, and the project is a hosting move. In exchange, you pay for the infrastructure yourself, and someone has to run it. Managed Magento hosting is one way to avoid building that team.

Is moving to ACCS a downgrade?

No. Adobe Commerce as a Cloud Service is a different product, and moving to it is closer to a rebuild. The storefront moves to Edge Delivery Services, customization moves out of the application into App Builder, and neither Luma nor Hyvä storefronts carry over. Adobe’s contract also caps a subscription at 250,000 SKUs. Our guide to Adobe Commerce as a Cloud Service covers who it fits, and our breakdown of ACCS migration cost prices the move.

What a downgrade from Adobe Commerce to Magento Open Source involves

A downgrade from Adobe Commerce to Magento Open Source runs in seven steps: audit the Commerce features and data you use, export the data you’ll lose, choose replacements, swap the Composer packages, convert the database, move hosting if you leave Cloud, then test and cut over. The database conversion is the risky part, so it runs on a copy first.

1. Audit what you use. List every Commerce-only feature with live data behind it: staging updates, customer segments, B2B companies and quotes, gift card accounts, reward point balances, and returns. Check extensions and custom modules for dependencies on Commerce classes.
2. Export what you’ll lose. Customer balances, open quotes, company structures, and return history need a destination before anything is removed.
3. Choose and install replacements. Pick an extension or custom build per feature, and test that it can import the exported data.
4. Swap the code. Replace the Adobe Commerce metapackage with the Open Source one in Composer, and remove or rewrite modules that depend on Commerce code.
5. Convert the database. Remove the Commerce-only tables and convert row_id back to entity_id for products, categories, CMS pages, and blocks.
6. Move hosting, if you leave Cloud. Set up the new environment, CDN, WAF, monitoring, backups, and a deployment pipeline to replace the Cloud tooling.
7. Test and cut over. Run a full regression on staging, freeze catalog changes, migrate, and switch DNS in a low-traffic window.

The database step is where downgrades go wrong. Adobe Commerce adds around 90 tables that Open Source doesn’t have, plus the staging key structure. Deploy eCommerce, a UK agency, published an open-source command-line tool for this conversion in March 2026 and warns that it makes irreversible changes to the database. Whatever tool you use, run it on a production copy, compare row counts before and after, and keep the backup until the store has run cleanly for a few weeks.

URLs, product data, and customer accounts stay where they are. Compared with a replatform, SEO risk is low, and customers don’t need to reset passwords.

How long a downgrade takes

The timeline depends on how many Commerce features you replace and how much data moves with them, plus a hosting move if you leave Cloud. The database conversion and its rehearsal on a copy set the critical path, and each replaced feature adds its own build and test time.

Start early enough to finish before the renewal date. If the project runs late, you either renew for another term or run a store you no longer have a license for. Check your contract’s renewal and notice terms first.

Which Magento version to downgrade on

Downgrade on a supported version. Adobe’s October 2026 security bulletin offered Magento Open Source patch files only for 2.4.7 and later, and 2.4.8 is supported until May 31, 2028. If you run 2.4.6 or older, combine the downgrade with an upgrade. Our guide to Magento end of life lists the support dates for every 2.4 version.

Adobe Commerce vs Magento Open Source: the 3-year cost check

A downgrade pays off when the license fees you stop paying are larger than everything the move adds. Over three years, the license is the ceiling. The one-time project, the replacement features, and any hosting the Cloud license used to cover have to come in under it. A B2C store that uses few Commerce-only features usually clears that bar. A store that depends on B2B or staging may not.

The license range comes from our Magento pricing guide, which breaks down all seven cost categories of running Magento. It is an estimate from aggregated partner data, because Adobe quotes privately and by GMV.

Take a B2C retailer with $5–10 million in annual GMV on Adobe Commerce on Cloud. Partner estimates put that license at about $80,000 a year, or $240,000 over three years. That $240,000 is the ceiling. The downgrade project, the replacements for staging and Live Search, and three years of hosting together have to cost less than that for the move to pay off. The project cost depends on which features you replace, how much data has to migrate, and whether you move hosting, so it has to be priced against your store.

scandiweb gives you a detailed quote for the downgrade after a short scoping call.

Where the saving disappears

Four things eat into the saving, and none of them shows up in a license comparison:

• B2B rebuilds: recreating quotes, approval flows, and company accounts as custom work can cost more than three years of license fees for a store that sells mostly to companies.
• Running infrastructure: leaving Cloud means someone handles scaling for peak traffic, incidents, and server security, either in-house or through a managed host.
• Card data and compliance: Adobe’s Cloud infrastructure comes with PCI-certified hosting. On your own hosting, keeping the environment in scope for PCI DSS is your job and your host’s.
• Adobe support: escalations to Adobe end with the license, so your agency or team becomes the only line of support.

Who should downgrade Adobe Commerce, and who shouldn’t

Downgrade Adobe Commerce to Magento Open Source if you sell mostly to consumers, use few Commerce-only features, and have a team or agency that can run hosting and patching. Stay on Adobe Commerce if your B2B sales depend on its native quotes and company accounts, your marketing team relies on staging, or the license is a small share of your total platform cost.

Downgrade to Magento Open Source if:

• You sell mostly to consumers and don’t use the B2B suite
• Your team rarely schedules content or price changes in staging
• Your catalog search works well enough on OpenSearch or a search service you’d pay for anyway
• You have an in-house team or agency that already handles upgrades and security patches
• The license is one of your three largest platform costs

Stay on Adobe Commerce if:

• Your buyers use negotiable quotes, purchase order approvals, or company accounts every day
• Your merchandisers schedule campaigns and price changes in staging every week
• Live Search and Product Recommendations drive a measurable share of revenue
• You have no team to run servers and a CDN outside Adobe’s Cloud
• The renewal is due before the project could finish

If you land in the middle, there are other options. Moving from Cloud to on-premise keeps the features and lowers the license band. The renewal is also the time to renegotiate your GMV tier. And if the platform itself is the problem, our guide to Magento to Shopify migration compares that path over three years.

Frequently asked questions about a downgrade from Adobe Commerce

Can you downgrade from Adobe Commerce to Magento Open Source?

Yes. Both editions share the same Magento core, so you can move from Adobe Commerce to Magento Open Source without changing platforms. The project removes the Commerce modules, replaces the Commerce metapackage in Composer, converts the database from the row_id structure back to entity_id, and replaces any Commerce-only features you still need with extensions. It needs a full rehearsal on a copy of production.

Do I lose my data if I downgrade Adobe Commerce?

You keep products, categories, customers, orders, and CMS content, as long as the database conversion runs correctly. You lose the data that belongs to Commerce-only features: scheduled staging updates, customer segments, B2B companies and quotes, gift card accounts, reward points, store credit, and returns. Export each of these before the conversion and import them into the replacement modules.

What happens to gift card balances, store credit, and reward points?

They are removed with the Adobe Commerce modules, so you have to migrate them. Export each customer’s balance, install replacement extensions, and import the balances before go-live. Gift cards and store credit are value customers already paid for or were promised, so check the totals before and after the move and keep the export as a record.

Is Magento Open Source still supported by Adobe?

Yes. Adobe still releases Magento Open Source, with 2.4.9 out since May 2026, and publishes security patches for it. Support is narrower than for Adobe Commerce: the October 2026 security bulletin offered Open Source patch files only for 2.4.7 and later. Open Source also comes without Adobe’s ticket support, so your team or agency handles issues directly.

How much does Adobe Commerce cost compared to Magento Open Source?

Magento Open Source has no license fee. Adobe doesn’t publish Adobe Commerce prices, but aggregated partner estimates put the on-premise license at about $22,000 to $125,000 a year and Adobe Commerce on Cloud at about $40,000 to $190,000 a year, scaled by GMV. Hosting, development, extensions, and maintenance apply to both editions.

Can I downgrade Magento Enterprise to Community?

Yes. Magento Enterprise Edition is today’s Adobe Commerce, and Community Edition is today’s Magento Open Source, so it is the same project under the old names. On Magento 2, you swap the Composer metapackage, convert the database, and replace Enterprise-only features. Magento 1 Enterprise stores have no supported version to move to, because Magento 1 support ended in June 2020.

Does Hyvä work on Magento Open Source?

Yes. The Hyvä Theme runs on both Magento Open Source and Adobe Commerce, and it has been free and open source since November 10, 2025. If your Adobe Commerce store already uses Hyvä, the storefront carries over in a downgrade. Check any Hyvä compatibility modules for Commerce-only features you’re removing, such as gift cards or B2B.

Is ACCS cheaper than Adobe Commerce on Cloud?

Not always, and moving to it costs more than a downgrade. ACCS replaces hosting, upgrades, and the license with one subscription, which removes upgrade projects. Getting there means rebuilding the storefront on Edge Delivery Services and moving customizations to App Builder, and Adobe caps a subscription at 250,000 SKUs. Compare that one-time cost with several years of upgrade spending first.

Decide on an Adobe Commerce downgrade before the renewal date

A downgrade from Adobe Commerce to Magento Open Source pays off when the license buys features your team doesn’t use. Start with the inventory: every Commerce-only feature with live data behind it, and what replacing it would cost. Then set the one-time project and the new running costs against three years of fees, and leave enough time for a database rehearsal before the renewal is due.

Weighing a downgrade before your next Adobe Commerce renewal? Send us your feature list and renewal date, and after a short scoping call we'll send a detailed quote, with what you'd lose and what you'd keep.

The post Downgrade Adobe Commerce to Magento Open Source: What You Lose and What You Save appeared first on scandiweb.

If two people on your team start every morning matching supplier invoices to purchase orders, you already know what three way matching costs when it’s done by hand. Every invoice gets checked against the order and the delivery note, line by line, before anyone pays it. The check itself is simple, but with dozens of suppliers whose documents never look the same twice, it fills the morning.

The numbers show how common this is. In Ardent Partners’ State of ePayables 2025, a survey of 204 accounts payable teams, 18.4% of invoices hit an exception, and only 35.4% were processed straight through without anyone touching them.

This guide explains what three way matching is, how it differs from two way and four way matching, and why it breaks down for wholesalers. Then it walks through how AI does the matching, using one of our own rollouts: a Baltic electrical wholesaler with 100+ suppliers that now matches 87% of its invoices with nobody touching them.

What is three way matching?

Three way matching is an accounts payable control that checks a supplier invoice against two other documents before it is paid: the purchase order and the goods receipt, usually based on the supplier’s delivery note. If the items, quantities, and prices agree within set tolerances, the invoice is approved for payment. If they don’t, it goes to a person as an exception.

Each document answers a different question:

• The purchase order shows what you agreed to buy, at what price.
• The goods receipt or delivery note shows what actually arrived. For cross-border road freight, the CMR consignment note is often part of that proof.
• The invoice shows what the supplier wants to be paid for.

A three way match catches the mistakes that cost money quietly: paying for 100 cable reels when 80 arrived, paying last quarter’s price after a discount was agreed, or paying the same invoice twice. Ardent’s benchmark shows how much of the work starts from orders: 65.4% of invoices are linked to a purchase order, and those are the invoices this check can cover.

Two way vs three way vs four way matching

Two way matching compares only the invoice and the purchase order. Three way matching adds proof of delivery. Four way matching adds an inspection or quality check on top. The more documents you compare, the more errors you catch, and the more exceptions you create when one document is missing or late.

For a distributor or wholesaler buying physical stock, three way matching is the sensible default. Two way matching misses short deliveries, and those are the most common problem when goods arrive by pallet from many suppliers.

Why three way matching breaks down for wholesalers

The documents rarely line up on their own. A supplier invoice describes the goods in the supplier’s words, and your ERP describes them in yours. Most of the time in manual matching goes into translating between the two.

These are the exceptions we see most often:

• Item codes don’t match. The supplier invoices “W-5G4-H07RNF” and your order says “CC-CBL-5X4.” A person has to know they are the same cable.
• Units differ. You ordered 10 boxes, and the supplier invoices 500 pieces.
• Deliveries arrive in parts. One order is delivered on three delivery notes and billed on two invoices.
• Prices changed. A discount agreed by phone never reached the purchase order.
• Every supplier has its own layout. With 100 suppliers, you get roughly 100 invoice formats, in different languages, as PDFs, scans, and phone photos.
• The receipt is missing. The goods arrived, but the warehouse hasn’t booked the delivery note yet, so the match can’t finish.

Microsoft Dynamics NAV, like most ERPs, stores purchase orders and posts invoices. It doesn’t read 100 different PDF layouts or match supplier lines to your items, so people do both. According to Ardent, only 51.4% of invoices reach accounts payable teams electronically, which means about half still have to be read before anyone can match them.

How AI three way matching works

AI invoice processing for three way matching follows six steps: read every document, find the matching order and delivery, match each line, score how confident the match is, post the result to the ERP, and learn only from corrections that repeat. People review only the invoices the software is unsure about.

This is the sequence we built for the wholesaler with OperaLayer, our product for the work that falls between business systems.

1. Read every document, in any layout

The software extracts the supplier, invoice number, dates, lines, quantities, units, and prices from each PDF, scan, or photo, and gives every field a confidence score. Invoices, delivery notes, and CMR documents all go through the same reader, so the delivery evidence is available when the invoice arrives.

2. Find the order and the delivery

Each invoice is linked to its purchase order in the ERP and to the delivery notes booked against it. When one order spans several deliveries or invoices, the software keeps track of what has already been received and billed, so a partial delivery doesn’t look like an error.

3. Match line by line: barcode, SKU, alias, then fuzzy

Line matching is where most of the manual time goes, so it runs in a fixed order, from the most reliable signal to the least:

1. Barcode. If the supplier line carries an EAN or GTIN that exists in your item data, that is the match.
2. SKU. The supplier’s item number is compared with your item numbers and the supplier item numbers already stored in the ERP.
3. Known alias. A table of supplier codes your team has already confirmed, such as “W-5G4-H07RNF is our CC-CBL-5X4.”
4. Fuzzy match. If nothing else works, the description, unit, and price are compared with open order lines to suggest the closest candidate.

A match from step 1 is almost always right. A match from step 4 is a suggestion and counts for less in the confidence score.

4. Score confidence and send only exceptions to people

Every invoice gets an overall confidence score built from the extraction, the line matches, and the quantity and price checks. Above the threshold, it goes through. Below it, it lands in a review queue with the reason shown: an unknown item code, a price above tolerance, or a delivery not yet booked. The reviewer fixes one line instead of rechecking the whole invoice.

5. Send matched invoices to the ERP

Purchase orders are read from the ERP, and matched invoices go back to it as a batch ready to post. For the wholesaler, that means Dynamics NAV: purchase orders come in, and approved invoices go out as a Navision-ready journal batch. The ERP stays the system of record, and nothing is migrated.

6. Learn from corrections, but only when they repeat

A reviewer’s correction becomes a standing rule only after the same correction recurs, so one mistaken click can’t change how every future invoice from that supplier is matched.

Case: a Baltic electrical wholesaler with 100+ suppliers

The wholesaler buys from about 100 suppliers and runs on Microsoft Dynamics NAV. Before the project, two people checked every supplier invoice against orders by hand, every morning, together with the delivery notes and CMR documents. NAV could store the orders, but it couldn’t read 100 different PDF formats or match lines to purchase orders.

We built the matching app on OperaLayer, on top of NAV. A first working version ran on the wholesaler’s own documents in about two weeks. As we wrote in why custom software is becoming cheaper than SaaS, AI has changed how fast software can be built around a single workflow: work that once took years can now take weeks.

Earning the team’s trust took another month. The people who had matched invoices for years needed to see the software get the hard cases right before they let it send anything to NAV. During that month, they checked its suggestions against their own work and corrected the mistakes. Corrections that came up again turned into rules. Those were the same people who knew which supplier codes meant what, and their knowledge went into the alias table.

The results:

• 87% of invoices are matched with nobody touching them. People see the rest.
• Around 100 supplier formats are read without templates.
• About 2,000 documents a month go through the system: invoices, delivery notes, and CMR documents.

The next phase is scoped: supplier documents will come in straight from email instead of being uploaded, and approved invoices will go into NAV through its API instead of an export batch.

The same approach works on other old systems. When LegacyBridge joined OperaLayer, its first IBM i (AS/400) workflow went live in two weeks and now processes more than 10,000 documents a month, each in under 10 seconds instead of 10 to 15 minutes by hand. The details are in our post on LegacyBridge joining OperaLayer.

Why seller-side automation comes before buyer-side AI agents

Most talk about AI agents in B2B is about the buyer’s side: an agent that searches suppliers, compares prices, and places the order. Those agents still struggle with B2B basics such as contract prices and purchase orders, as we cover in our B2B eCommerce trends for 2027 and our guide to the Universal Commerce Protocol.

The seller’s own side is ready now. Invoice matching repeats every day and follows rules your team can already write down, using data the ERP holds. The outcome is easy to measure: the share of invoices nobody touched. That makes it a good first job for AI inside a distributor or wholesaler.

The same pattern covers the other paperwork that arrives in many formats:

• Purchase order automation on the buying side: reading order confirmations and checking them against your POs before the goods arrive.
• Sales order automation on the selling side: customer orders that arrive by email or PDF, read and checked against price lists and stock.
• Order entry automation for the ERP: entering what was read into the right screens, with a person approving anything unusual.

AI order entry and invoice matching use the same parts: a reader, a matcher, a confidence score, and a review queue. Once the first one is live, the next one starts with most of the work done.

How to prepare for automated invoice matching

You don’t need clean data to start, but a few decisions speed up the first weeks. Collect these before the project begins:

• Tolerances. How far can price and quantity differ before an invoice becomes an exception? Write the rule down, per supplier if needed.
• A sample of real documents. A month of invoices, delivery notes, and CMR documents from your largest and messiest suppliers.
• Your alias knowledge. The supplier codes your team already translates in their heads. Even a rough spreadsheet saves weeks.
• ERP access. Read access to purchase orders and receipts, and a way to post invoices back. For Dynamics NAV, plan around the move to Business Central, and see our guide to ERP integration for the options.
• One owner. Someone from accounts payable or purchasing who reviews exceptions in the first month and decides which corrections become rules.

E-invoicing mandates will make part of this easier. Belgium has required structured B2B e-invoices since January 2026, France started in September 2026, and Germany requires larger companies to issue them from January 2027, as our guide to the digital product passport lists. Structured invoices remove the reading step, but the line matching and the exceptions stay, and so do suppliers from outside those countries.

FAQ about three way matching

What is the difference between two way and three way matching?

Two way matching compares an invoice with the purchase order: the items and prices must agree. Three way matching adds the goods receipt or delivery note, so you only pay for what actually arrived. It catches short and missing deliveries that two way matching misses, which is why most wholesalers and distributors use it for physical goods.

What are common three way matching errors?

The most common three way matching errors are supplier item codes that differ from yours, different units of measure, partial deliveries spread across several delivery notes, prices that changed after the order, missing goods receipts, and duplicate invoices. Most of them are translation problems between the supplier’s documents and your ERP, which is why a confirmed alias table removes so many exceptions.

Can AI do three way matching?

Yes. AI reads invoices, delivery notes, and orders in any layout, matches each line to your items, and scores how confident each match is. Invoices above the confidence threshold go to the ERP without a manual check, and the rest go to a person with the reason shown. At one Baltic electrical wholesaler, this matches 87% of invoices with nobody touching them.

What auto-match rate is realistic for invoice matching automation?

It depends on your suppliers and data, but well above the market average is realistic. Ardent Partners’ 2025 benchmark puts straight-through processing at 35.4% of invoices on average. A wholesaler we work with reached 87% across about 100 supplier formats. Expect a lower rate in the first weeks, rising as repeated corrections become rules.

Does AI invoice processing replace the accounts payable team?

No. It removes the routine matching and leaves the decisions to people. The team reviews exceptions, approves anything unusual, and confirms which corrections become rules. In our wholesaler rollout, the people who used to match every invoice by hand now review only the exceptions, and their knowledge of supplier codes is what made the high match rate possible.

How long does it take to automate three way matching?

With an operational layer on top of your existing ERP, a first working version can run on your own documents in about two weeks. Plan for roughly another month of side-by-side review before your team trusts it to post invoices on its own. The ERP stays in place, so there is no migration to schedule.

Three way matching works when your team trusts it

Three way matching is a simple control that takes hours when the documents come in 100 layouts and the item codes don’t line up. AI can now read the documents and match the lines, then send people only the invoices that need a decision. At our wholesaler, the first version took about two weeks. The month of side-by-side review that followed is what made the team trust it to run on its own.

Still matching supplier invoices by hand every morning? Tell us which documents your team checks, and we'll show you what automated matching would look like on your own data.

The post Three Way Matching: How AI Matches 87% of Invoices Without a Human 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.