When the site is wrong, start with the handoff, not the homepage
When a storefront depends on product data, stock, and pricing feeds, how do we spot whether the issue is the website itself or the upstream data layer? Start by tracing one SKU end to end, from ERP or PIM to the storefront response, before anyone touches the theme. Most “site bugs” in ecommerce are actually data sync problems, and most “feed problems” look like site bugs because the browser is where the mistake becomes visible.
That distinction matters because the wrong fix wastes time twice. You can spend hours asking a web team to debug a product page that is faithfully displaying stale inventory, or you can keep trading while the real fault sits in a catalogue feed, pricing rule, or cache layer.
The fastest way to separate website faults from feed faults
When a storefront depends on product data, stock, and pricing feeds, how do we spot whether the issue is the website itself or the upstream data layer? Compare the same item in three places, at the same moment: source system, feed output, and live page. If the source is right, the feed is right, and the page is wrong, you have a storefront problem. If the source is wrong, or the feed is wrong before it reaches the site, the website is usually just the messenger.
Use a single SKU that is easy to recognise and has changed recently. Check:
- The ERP, PIM, or inventory system of record.
- The feed file, API payload, or middleware log.
- The live product page, category page, and search result.
A clean comparison usually tells you more than a week of Slack messages. If the source says A$129.95 and in stock, the feed says A$129.95 and in stock, but the product page shows A$149.95 and low stock, the storefront is stale or misreading the payload. If the source says A$129.95 and in stock, but the feed says A$149.95 and low stock, the problem started upstream.
Key takeaway: The page is the last place to look, not the first. If the source and feed agree, the website is probably rendering the wrong thing. If they do not, the web team is being blamed for someone else’s problem.
Signs you are looking at stale data, not a broken feed
A feed that has failed completely usually breaks in an obvious way. You will see blanks, missing products, default prices, import errors, or a large set of items disappearing together. Stale data is subtler. The site still looks healthy, but the numbers are old.
These are the usual signs of stale product, stock, or pricing data:
- The homepage and category pages look normal, but one or more product detail pages are wrong.
- A price changed in the source system, but the old price persists on the page.
- Stock counts lag behind reality by a predictable window, often minutes or hours.
- One variant is correct while another variant on the same product is not.
- Search results and category tiles disagree with the product page.
That pattern usually points to delayed sync, cached fragments, or a mapping problem, not a total feed outage. If the feed had died outright, you would usually see more than one SKU affected, and the failure would be broader than a single template.
For businesses in Australia, this shows up most painfully during trading peaks, when a price change goes live before a sale ends, or when stock drops in the warehouse but the site keeps selling until the next sync. That is not a “website bug” in the usual sense. It is an ecommerce data sync boundary problem.
How long is normal before you suspect cache or sync trouble?
There is no universal number, because the right answer depends on your architecture. A near real time API sync should usually be visible within seconds to a couple of minutes. A batch feed, especially one run on a schedule, may legitimately lag by 15 minutes, 30 minutes, or longer.
The practical test is not “how long until I feel nervous”. It is “what is the published or agreed sync interval, and did we exceed it by enough to rule out normal delay?”
Use this simple boundary:
| Sync model | Usually acceptable lag | When to suspect a problem | |---|---:|---:| | Real time API / webhook | Seconds to 2 minutes | After 5 to 10 minutes | | Frequent scheduled sync | 5 to 15 minutes | After one missed cycle | | Batch feed | 15 to 60 minutes | After the next scheduled run plus buffer |
If a fix in the feed does not show up on the storefront right away, check the cache headers, CDN rules, and job logs before you blame the build. A stale page can be caused by browser cache, edge cache, application cache, or a queue that has not drained yet. The important question is whether the delay matches the system design. If it does, you have a sync window. If it does not, you have a fault.
What homepage normality tells you, and what product page errors usually mean
When the homepage and category pages look normal but product pages are wrong, the issue usually sits in one of three places: product-level mapping, template logic, or a per-item cache miss. It is less often a whole-site theme failure.
Start by checking whether the same bad value appears everywhere or only on the product detail page.
- If the category tile, search result, and product page all show the wrong price, the feed or source mapping is suspect.
- If only the product page is wrong, the template, metafield mapping, or product-level cache is more likely.
- If only some variants are wrong, look at variant IDs, option mapping, and whether the feed is sending the correct SKU-level data.
This is where a lot of storefront troubleshooting goes sideways. Teams see a wrong price on a product page and assume the theme is broken. In reality, the theme may be reading exactly what it was given, but the upstream data layer is handing it a mismatched identifier, a missing field, or a stale variant record.
When a storefront depends on product data, stock, and pricing feeds, how do we spot whether the issue is the website itself or the upstream data layer? The answer is often in scope. Broad, repeatable errors point to the feed or mapping. Narrow, template-specific errors point to the website.
Real time problem or stale sync?
The cleanest way to tell is to change one field in the source system and watch how long it takes to appear on the live page. Use a harmless field where possible, such as a tag, a description line, or a controlled price on a test SKU. Then note the timestamp at each step.
If the source changes instantly, the feed updates, but the storefront does not, the problem is downstream. If the source changes, but the feed file or API response does not, the problem is upstream. If everything updates except the live page, you are looking at cache, rendering, or indexing.
A few practical checks help here:
- Compare the feed timestamp against the page’s last modified or cache age.
- Inspect the network response, not just the screen.
- Confirm whether search and category pages are reading the same data source as PDPs.
- Check whether the storefront is pulling from a replicated table, a search index, or a headless cache layer.
That last point matters more than people like to admit. Many ecommerce stacks are not one pipeline, they are several. The website can be “correct” according to its own cache and still be wrong according to the source of truth. That is why storefront troubleshooting needs system boundaries, not guesses.
When one item fixes and another does not
If a fix seems to work for one item but not others, the pattern usually tells you what kind of fault you have.
| Pattern | What it usually points to | First thing to check | |---|---|---| | One SKU fixes correctly, others do not | Feed quality or mapping issue | SKU IDs, variant mapping, missing fields | | One category behaves, another does not | Template or content source mismatch | Template logic, collection rules, metafields | | One field updates, another stays old | Partial sync or cache fragmentation | Field-level caching, webhook coverage | | Only changed items fail | Delta sync or queue processing issue | Job logs, retry failures, message queue backlog |
A theme issue normally affects the same presentation rule across many products. A mapping problem usually affects specific fields or variants. A feed quality problem often looks random until you realise the same source field is missing or malformed in every bad record.
This is also why a quick fix can be misleading. If you manually correct one product in the admin and it displays properly, that does not prove the website is healthy. It may only prove that the site can render a clean record when it gets one.
Should you pause trading, hide products, or keep the site live?
Do not default to taking the whole site down. That is rarely the safest move. The right response depends on whether the fault affects price integrity, stock integrity, or only presentation.
A practical decision tree:
- If prices are wrong and customers could be overcharged or undercharged, hide the affected products or disable checkout for those items until the source is corrected.
- If stock is wrong but the discrepancy is small and the business can absorb a short oversell risk, keep trading while you tighten the sync, but watch the affected SKUs closely.
- If the fault is cosmetic, such as a description, image, or badge mismatch, keep the site live and fix it in the next deployment window.
- If the issue is broad, unexplained, and changing in real time, pause the affected catalogue segment rather than guessing.
For Australia businesses, the commercial risk is often not just customer frustration. It is GST-inclusive pricing, freight recalculation, and stock commitments that have to line up with what the buyer saw at checkout. If those are drifting, the safest move is usually to narrow the blast radius, not shut the whole store.
A site like Websites & Online Stores is only as reliable as the data it renders. That is why the operational question is more important than the design question when revenue is on the line.
What evidence to ask for before paying someone to “fix the website”
Before you approve work, ask for proof that the fault is actually in the website layer. You want evidence, not a confident guess.
Ask for:
- A source-to-page trace for one broken SKU.
- The exact feed payload or API response that supplied the bad value.
- Timestamps for source update, feed update, cache purge, and page render.
- Logs showing whether the product page received the correct data.
- A list of affected SKUs, so you can see whether the pattern is global or specific.
If someone cannot show you where the wrong value entered the chain, do not let them bill for a “site fix” yet. You may be paying to patch a symptom while the ERP, PIM, middleware, or catalogue feed keeps producing the same error.
This is where a stronger operating model helps. For businesses with recurring feed and integration issues, Data Analytics & Lakehouses can make the source of truth visible instead of buried across systems. That does not replace the storefront, but it does make it far easier to prove whether you are dealing with upstream data layer problems or a genuine web defect.
The short version for teams under pressure
When a storefront depends on product data, stock, and pricing feeds, how do we spot whether the issue is the website itself or the upstream data layer? Use the chain, not the symptom.
- Source correct, feed correct, page wrong, the website or cache layer is at fault.
- Source wrong, feed wrong, page wrong, the problem is upstream.
- Homepage fine, product page wrong, look at mapping, template logic, or product-level cache.
- One item fixed, others not, suspect field mapping or feed quality before blaming the theme.
- If the lag is within the designed sync window, it may be normal. If it is outside that window, treat it as a fault.
The best teams do not argue about whether it is “the website” or “the feed”. They trace the record, prove where the break starts, and then fix the layer that actually owns the problem.
Common questions
How can I tell whether the problem started after a website change or after a catalogue update?
Check the timestamps first. If the issue appeared right after a theme deploy, template edit, or app install, the website is the likely suspect. If it started after an ERP, PIM, or feed update, trace the affected SKU through the sync path before touching the site.
What signs mean the website is just displaying stale data rather than the feed failing completely?
The page still loads normally, but prices, stock, or descriptions lag behind the source by a consistent window. If only some items are wrong and the rest of the catalogue looks fine, that usually points to cache, delayed sync, or field-level mapping, not a full feed failure.
If a fix in the feed doesn’t show up on the storefront right away, how long is normal before I should suspect the website cache or sync pipeline?
It depends on the sync model. Seconds to a couple of minutes can be normal for real time APIs, while scheduled feeds may take 15 to 60 minutes. If the delay is longer than the agreed interval plus a small buffer, start checking cache, queue, and job logs.
What evidence should I ask for before I pay someone to fix the website?
Ask for a source-to-page trace, the exact feed payload, timestamps for each hop, and logs showing where the bad value entered. If they cannot prove the break is in the website layer, you may be funding an ERP, PIM, or feed issue the web team cannot actually solve.
Make the next step concrete
Start with one broken SKU and map it through source, feed, cache, and page. If you can do that cleanly, you will know whether you have a storefront problem, an upstream data layer problem, or both.
If you want that traced properly and fixed at the right layer, book a call with Artigence. We can help isolate the fault, harden the sync path, and stop the same product data issue from coming back as a “website bug” next week.
