On 15 September 2026 we externally measured 43 live online stores on three platforms: 22 on Horoshop, 9 on Prom with their own domain and 12 on OpenCart. We wanted a simple comparison: how long the server thinks, whether there is a canonical, whether the product is marked up, what is in the sitemap.
We got the comparison, but first we had to sort out two errors in the measurement itself. Because of the first, Prom would have come out as the fastest platform. Because of the second, it would have looked as if almost all Horoshop stores had neither analytics nor a canonical. Both conclusions would have been false, and both traps await anyone who checks a site with an automated tool.
Who we measured and how
The sample is not random, and that has to be said right away. Horoshop means 22 stores, selected mostly from the platform’s public client list, that responded with code 200 on 15 September. We discarded two domains: one returned an empty response, the other had no signs of the platform. Prom means 9 stores on their own domains, found as examples in another agency’s article and through search. OpenCart means 12 stores from our August sample, one studio’s portfolio and search. None of the 43 is our client.
We confirmed the platform from the page code, not from the name. For Prom, these are resources and a header from the platform’s own domains. For Horoshop, the robots.txt template and a sitemap in the platform’s directory. For OpenCart, the paths to the engine’s theme and scripts.
Everything was measured from one network location in one evening, and only the homepage plus one product page where we managed to open it. So what follows is about this sample specifically, not about the platform in general.
Trap one: the tool measured a refusal, not the page
Our external audit script takes time to first response with a HEAD request. Such a request asks the server only for headers, without the page body. For Prom, the script produced a median of 138.7 ms. That would have looked like the best result in the sample.
In fact, Prom responds to HEAD with code 405, meaning “method not allowed.” The server refuses quickly, and the script measured exactly that refusal. When we switched to a regular GET of the final address (five runs per site, taking the median of each), the picture reversed: the median across the nine Prom stores came to 713.8 ms.
On 16 September we repeated the check on three Prom stores. HEAD returned 405 in 0.16–0.32 s, while GET of the same address returned 200 in 0.78–1.09 s.
This kind of error is easy to miss because the figure looked plausible: a fast server on a large platform surprises no one. It only became visible when we looked at the response code, not just the time.
Trap two: Horoshop serves a check page to non-browsers
The second problem is bigger. On 21 of 22 Horoshop stores, a request without a browser receives a tiny page with a single script instead of the store. That is how both curl and our audit were answered on 15 September. The response size is from 295 to 778 bytes.
The script on this page runs an empty loop for 800 ms plus a random addition of up to 500 ms. Then it sets a challenge_passed cookie for 30 minutes and reloads the page. A browser passes this on its own and shows the store. A client that does not execute JavaScript sees only the script.
What our tool “saw” on 22 Horoshop homepages:
- canonical on the homepage — in 1 store of 22;
- no analytics counters — in 21 of 22;
- Product markup on the product page — in 0 of 19 where we managed to open a product.
All these figures describe the check page, not the stores. We declared them invalid and do not publish them as a characteristic of the platform.
On 16 September a repeat pass gave the same result: 21 of 22, size from 295 to 777 bytes. The same day we opened one of these stores in Chrome via Playwright. The page loaded immediately, the check cookie did not appear, canonical and hreflang were in place, and the homepage itself was transferred at over 50 KB.
What is served without the check: on 16 September robots.txt opened on all 22 stores. 21 of them have the line Content-signal: search=yes, ai-input=yes, ai-train=no. None of the Prom and OpenCart stores in the sample has such a line.
What we do not know. We did not check whether search crawlers and AI assistants receive this page. To do that we would have had to fake a crawler’s User-Agent, and we do not do that. Only the store owner has an honest check, in Search Console (more on it below). Nor do we know whether this check is enabled permanently: we have only two days of observation. So we do not claim that Google sees an empty page. We claim only one thing: external audits, price monitoring services and any other client without JavaScript received a script instead of the store on those two days.
What we managed to measure
| Metric (15.09.2026) | Prom, 9 | OpenCart, 12 | Horoshop, 22 |
|---|---|---|---|
| Median first response, GET | 713.8 ms | 326.0 ms | not measured |
| Fastest / slowest | 569.6 / 864.3 ms | 97.0 / 1,304.6 ms | not measured |
| Canonical on homepage | 9 of 9 | 2 of 12 | not measured |
| hreflang on homepage | 9 of 9 | 10 of 12 | not measured |
| Product on product page | 7 of 8 | 5 of 9 | not measured |
| robots.txt | 9 of 9 | 12 of 12 | 22 of 22 |
| Median URLs in sitemap | 1,604 (across 8) | 9,298 (across 11) | 1,472 (across 22) |
| Unsupported PHP in headers | not visible | 1 of 12 | not visible |
In this sample Prom is roughly twice as slow as OpenCart by median, but consistent. None exceeded a second by median, but three of the nine have a median above 800 ms. Canonical and hreflang are present everywhere, product markup on seven of the eight product pages opened. On a rented platform, the server is configured by the platform, not by the store owner. One more detail: all 9 homepages carry the same Google Analytics 4 ID, separate from the store’s own ID. So this tag is added by the platform, not by the owner. We did not investigate what data it collects.
OpenCart shows the widest spread in both directions: from 97 ms to 1.3 s, canonical on only two homepages of twelve. On one store the sitemap responds with code 200 and an empty body, and it was so on 15 and 16 September. Another shows PHP 7.3 in its headers. Eight of the twelve OpenCart stores are taken from our August measurement, so we do not repeat the breakdown by niche here; it is in the technical baseline of the market across 39 stores.
Horoshop is measured only partially. robots.txt and a sitemap exist on all 22, and every one declares the sitemap in robots.txt. Everything read from HTML is unavailable from outside for 21 stores.
And one more observation: the median catalog on OpenCart in this sample is several times larger than on Prom, yet the server responded faster. So catalog size cannot explain the difference in time here.
How to check your store in 10 minutes
1. Is your tool measuring a refusal. Compare the response code for HEAD and for GET:
curl -s -I -o /dev/null -w 'HEAD: %{http_code} %{time_starttransfer} s\n' https://your-store.ua/
curl -s -o /dev/null -w 'GET: %{http_code} %{time_starttransfer} s\n' https://your-store.ua/
If HEAD gives 405 or 403 while GET gives 200, then services that measure via HEAD show you a false time. For GET, take five runs and use the median. What the figure itself means we covered in the article on website speed.
2. What a client without a browser sees.
curl -sL https://your-store.ua/ -o home.html
wc -c home.html
grep -c '<title' home.html
A few hundred bytes without <title> mean that a check or protection page is served instead of the store. Then every external audit of your site describes exactly that page.
3. What robots.txt says.
curl -s https://your-store.ua/robots.txt | head -20
See whether it contains Content-signal and which signals it declares.
4. What Google receives. In Search Console, open URL inspection, run a test of the live URL and view the HTML the crawler received. If the store is there, search sees the store, whatever curl shows. Only the property owner can take this step, and it is the most direct way to find the answer.
What we changed and what it did not fix
In the measurement summary we replaced the time to first response for Prom and OpenCart with GET measurements. We marked the script’s figures for Prom as invalid. For 21 Horoshop stores we marked as invalid all fields read from HTML: response time, canonical, counters, hreflang and markup. The rule we applied: a response of a few hundred bytes without a page title is “not measured,” not zero.
This did not close the main gap. We still cannot compare Horoshop’s HTML with the two other platforms from outside, and we will not bypass the check. The samples are small and not random. Response time was taken from one network location in one evening and only for the homepage, meaning it is server time, not the speed a shopper feels.
If you are thinking about moving, the first step is your own measurements, not our table. For stores on Horoshop, we described where we start on the page about migrating from Horoshop. A full check of all pages, not just the homepage, is what we do in a technical audit.
