Australian Business Websites 2026: First Results, from Canberra
Published · Updated
This is the first city in our study of Australian business websites. On 26 September 2026 we drew a random sample of 200 websites from the 804 Canberra business websites mapped in OpenStreetMap, and checked each homepage for the platform it runs on, how it handles HTTPS and whether it is set up for phones. On 4 October 2026 we added speed: Core Web Vitals from real Chrome visits where Google has data, and a Lighthouse lab score for the other sites we could reach. Every figure below gives its count and its base, and the CSV files give the 95 per cent interval, definition and date for each one.
Read it as a pilot. OpenStreetMap is mapped by volunteers and leans towards shopfronts, so the sample describes mapped businesses, not every business in Canberra. Google's Chrome UX Report only includes sites with enough Chrome traffic: 63 of the 200 had phone data, so the Core Web Vitals figures describe those busier sites, not all Canberra business websites. The study is planned to cover more Australian cities on this page, each with the same method.
Key findings
- On phones, 25 of 60 Canberra business websites that Google could assess (41.7%) passed Core Web Vitals, measured on real Chrome visits from 5 September to 2 October 2026 (Chrome UX Report). Only 63 of the 200 sampled sites (31.5%) were in Google's phone data, which needs enough Chrome traffic, so this describes the busier sites.
- Responsiveness was rarely the problem on phones: 46 of 53 sites (86.8%) had a good Interaction to Next Paint, against 34 of 60 (56.7%) with a good Largest Contentful Paint, the loading measure. 41 of 62 (66.1%) had a good Cumulative Layout Shift.
- Sites without phone field data whose homepage we could read got one Lighthouse lab run on a simulated phone instead (PageSpeed Insights, 4 October 2026). Of the 105 that returned a score, the median was 60 out of 100; 7 of 105 (6.7%) scored 90 or more and 26 of 105 (24.8%) scored below 50. These are lab scores, not Core Web Vitals.
- WordPress ran 65 of the 162 Canberra homepages we could read (40.1%). Shopify ran 18 (11.1%), Wix 15 (9.3%) and Squarespace 14 (8.6%).
- Among the 58 retail homepages we could read, Shopify (16) and WordPress (17) were almost level. Outside retail, Shopify ran 2 of 104 measured homepages.
- 150 of the 170 sites whose result we could determine (88.2%) passed our HTTPS test. 17 sites with a valid certificate still served their homepage over plain HTTP instead of redirecting.
- 39 of 162 homepages (24.1%) ask phones to block or limit pinch zoom, which the axe accessibility rule for WCAG success criterion 1.4.4 flags. 161 of 162 set a mobile viewport.
- 12 of the 200 sampled website addresses (6.0%) no longer resolved and 3 were parked domains: the OpenStreetMap entries were out of date.
Results by city
Canberra, ACT
Frame: 1,988 OpenStreetMap features with a website inside the bounding box. Removing 119 outside the ACT boundary, 649 that are not businesses (schools, parks, places of worship and the like), 18 whose website is a profile on another platform and 12 on government or education hosts left 1,190 business features. Counting each website once and dropping the 175 websites used by national or international chains left 804 business websites, and we sampled 200 of them at random.
Retail made up 68 of the 200 sampled websites and food and drink 62, so shopfront businesses dominate the sample. 162 homepages could be read; the other 38 are counted as outcomes, not replaced.
Homepage crawl, 26 September 2026
Our own crawl of the 200 sampled homepages: server HTML and headers, no JavaScript run.
- Websites sampled
- 200 of 804
- Simple random sample of the frame, without replacement
- Homepages measured
- 162 of 200 (81.0%)
- 95% interval 75.0 to 85.8%. Not measured: 12 domains no longer resolve, 11 blocked by a firewall or bot check, 6 no response, 4 robots.txt disallows, 3 parked, 1 HTTP error, 1 TLS error
- WordPress
- 65 of 162 (40.1%)
- 95% interval 32.9 to 47.8%
- Shopify
- 18 of 162 (11.1%)
- 95% interval 7.1 to 16.9%
- Wix
- 15 of 162 (9.3%)
- 95% interval 5.7 to 14.7%
- Squarespace
- 14 of 162 (8.6%)
- 95% interval 5.2 to 14.0%
- Other hosted website builders
- 22 of 162 (13.6%)
- Square Online or Weebly 6, Duda 5, CloudWaitress 3, GoDaddy 3, Webflow 3, TapTouch 1, Hostinger 1
- Custom builds on a framework
- 8 of 162 (4.9%)
- Next.js 3, ASP.NET 2, SvelteKit 1, Gatsby 1, Nuxt 1
- Other e-commerce platforms and CMSs
- 6 of 162 (3.7%)
- BigCommerce 2, Pronto Avenue 1, Craft CMS 1, Joomla 1, Silverstripe 1
- Platform not identified
- 14 of 162 (8.6%)
- No fingerprint matched
- Retail homepages on Shopify
- 16 of 58 (27.6%)
- 95% interval 17.8 to 40.2%. WordPress: 17 of 58 (29.3%)
- HTTPS pass
- 150 of 170 (88.2%)
- 95% interval 82.5 to 92.3%. Valid certificate and plain HTTP redirected (or not served)
- Valid certificate
- 176 of 179 (98.3%)
- Sites whose HTTPS result could be determined
- HSTS header
- 94 of 176 (53.4%)
- Among sites with valid HTTPS
- Mobile viewport set
- 161 of 162 (99.4%)
- Lighthouse 12 viewport rule; negatives confirmed in a browser
- Pinch zoom blocked or limited
- 39 of 162 (24.1%)
- 95% interval 18.1 to 31.2%. user-scalable=no, or maximum-scale below 2
Core Web Vitals on phones: field data
Chrome UX Report (Google), origin level: real Chrome visits on phones from 5 September to 2 October 2026, queried on 4 October 2026. Only sites with enough Chrome traffic are in it, so these figures describe the busier sites in the sample. Good means the site's 75th percentile meets Google's threshold.
- Sites with CrUX phone data
- 63 of 200 (31.5%)
- 95% interval 25.5 to 38.2%. The rest are not in CrUX for phones: too little Chrome traffic, or not publicly discoverable
- Passed Core Web Vitals on phones
- 25 of 60 (41.7%)
- 95% interval 30.1 to 54.3%. Base: sites with both LCP and CLS reported
- Good Largest Contentful Paint (LCP)
- 34 of 60 (56.7%)
- 95% interval 44.1 to 68.4%. Good: 2,500 ms or less. Median 75th percentile across sites: 2,252.5 ms
- Good Interaction to Next Paint (INP)
- 46 of 53 (86.8%)
- 95% interval 75.2 to 93.5%. Good: 200 ms or less. Median 75th percentile across sites: 122 ms
- Good Cumulative Layout Shift (CLS)
- 41 of 62 (66.1%)
- 95% interval 53.7 to 76.7%. Good: 0.1 or less. Median 75th percentile across sites: 0.03
Core Web Vitals on all devices: field data
The same source and period, with phone, desktop and tablet visits combined. More sites have enough traffic this way, so the base is wider than for phones alone.
- Sites with CrUX data, all devices
- 115 of 200 (57.5%)
- 95% interval 50.6 to 64.1%
- Passed Core Web Vitals, all devices
- 59 of 110 (53.6%)
- 95% interval 44.4 to 62.7%. Base: sites with both LCP and CLS reported
- Good LCP, all devices
- 71 of 110 (64.5%)
- 95% interval 55.3 to 72.9%. Median 75th percentile across sites: 1,999.5 ms
- Good INP, all devices
- 88 of 92 (95.7%)
- 95% interval 89.3 to 98.3%. Median 75th percentile across sites: 86 ms
- Good CLS, all devices
- 86 of 114 (75.4%)
- 95% interval 66.8 to 82.4%. Median 75th percentile across sites: 0.01
Lighthouse lab scores on mobile: not Core Web Vitals
One PageSpeed Insights run per site on 4 October 2026 (Lighthouse 13.5.0, performance only), on a simulated mid-range phone on a mobile network. Run for the sites without CrUX phone data whose homepage our crawl could read. A lab score is one simulated page load, not real visits, so it is never added to the field figures above.
- Sites with a lab score
- 105
- Sites without CrUX phone data whose Lighthouse run returned a performance score
- Median performance score
- 60 out of 100
- Across the 105 sites with a lab score
- Lab score 90 or more (good)
- 7 of 105 (6.7%)
- 95% interval 3.3 to 13.1%
- Lab score 50 to 89 (needs improvement)
- 72 of 105 (68.6%)
- 95% interval 59.2 to 76.7%
- Lab score below 50 (poor)
- 26 of 105 (24.8%)
- 95% interval 17.5 to 33.8%
Field data coverage (CrUX)
Field Core Web Vitals come from the Chrome UX Report (CrUX), Google's public dataset of real Chrome users' visits. It only includes sites that are publicly discoverable (not marked noindex, for example) and have enough Chrome traffic, and Google does not publish the traffic threshold. We queried it on 4 October 2026 for all 200 sampled Canberra websites, for phones and for all devices combined; each answer covers 5 September to 2 October 2026. 63 of the 200 sites (31.5%) had phone data, so the field figures describe those sites, not every Canberra business website.
The sites without phone data have no phone field figures, though some of them have enough traffic across all devices to appear in the all-devices figures. Each of them whose homepage our crawl could read also got one Lighthouse lab run, and 105 returned a score. Those lab scores are reported on their own, never pooled with the field data.
| City | Sites sampled | With CrUX phone data | With CrUX data, all devices |
|---|---|---|---|
| Canberra | 200 | 63 (31.5%) | 115 (57.5%) |
How the data was collected
Population: websites of businesses mapped in OpenStreetMap inside the city boundary. For Canberra the boundary is the Australian Capital Territory, area 8ACTE in the ABS Australian Statistical Geography Standard, Edition 3 (2021). We took every OpenStreetMap node, way and relation tagged with a website inside it, from the snapshot of 26 September 2026 at 13:55 UTC.
A feature counts as a business when its tags put it in retail, food and drink, health, professional services, trades and crafts, accommodation, leisure and fitness, or a short list of other services. We then removed websites that are a profile on someone else's platform (Facebook, Instagram, booking and directory sites), government and education hosts, and every website used by a feature tagged as a national or international chain. Each website enters the frame once, however many branches it has.
Sample: 200 websites drawn at random without replacement, in a fixed order seeded from the study name and the city, so the same frame always gives the same sample. A site that fails is a finding, not a gap to refill.
Crawl: robots.txt first, then the homepage over HTTPS and over plain HTTP, once each, with redirects followed and no JavaScript run. A site with no answer for a passing reason was tried once more after the first pass. Firewalls and bot checks were never bypassed; they are counted as blocked. The crawl ran from 13:57 to 14:03 UTC on 26 September 2026.
Platform comes from the homepage's HTML and response headers: a generator tag, the platform's own asset host or a header only it sets. Tracking code alone never decides it. These rules have not been checked against a list of known platforms, so treat single-platform shares as estimates within their intervals.
Field data: on 4 October 2026 we asked the Chrome UX Report API about each sampled website's origin (the address its homepage finally landed on, or the address with and without www when the homepage could not be read), once for phones and once for all devices. Every answer covered the 28 days from 5 September to 2 October 2026. Querying CrUX reads Google's dataset and sends no request to the site.
Lab data: on 4 October 2026, each site without CrUX phone data whose homepage our crawl could read got one mobile Lighthouse run through the PageSpeed Insights API, which runs it on Google's servers on a simulated mid-range phone. We kept the performance score only.
Limits: the crawler runs from Pakistan, so we report no response times of our own, and a site that blocks traffic from outside Australia shows as blocked or not responding. CrUX covers only sites with enough Chrome traffic, so the field figures lean towards the busier sites. The lab scores come from the sites CrUX had no phone data for, so they cover different sites from the phone field figures and should not be compared with them as if they were one group. Each lab score comes from a single run. Every share is printed with its count and base, and with a Wilson 95 per cent interval in the CSV files. With 200 sites, a share near half has an interval of about seven points either side, so small differences should not be read as real.
- HTTPS pass
- The HTTPS homepage loads with a certificate that validates (Node.js trust store, incomplete chains re-checked in Chromium), and the plain-HTTP homepage redirects to HTTPS or is not served. Base: sites whose result could be determined.
- HSTS
- A Strict-Transport-Security header on the HTTPS homepage response, among sites with valid HTTPS.
- Mobile viewport
- The first meta viewport tag sets width or a non-zero initial-scale, and initial-scale is not below 1 (Lighthouse 12 viewport audit). Pages that failed in the server HTML were loaded in headless Chromium at 390 by 844 before counting as a fail.
- Zoom blocked or limited
- The viewport sets user-scalable=no or 0, or maximum-scale below 2 (axe rule meta-viewport, WCAG 2 success criterion 1.4.4). This records what the page asks for; whether each browser obeys it was not tested.
- CrUX coverage
- Sampled websites whose origin has CrUX data, out of the sampled websites whose query was answered (all 200 for Canberra). Phones are the headline; all devices are reported beside them.
- Core Web Vitals (field)
- On each origin's 75th percentile over CrUX's 28 days: Largest Contentful Paint good at 2,500 ms or less, Interaction to Next Paint at 200 ms or less, Cumulative Layout Shift at 0.1 or less. A site passes when all three are good, or when LCP and CLS are good and CrUX has too little INP data, the rule PageSpeed Insights uses. A site without an LCP or CLS figure is not assessed.
- Lighthouse lab score
- One mobile run per site through the PageSpeed Insights API v5, performance category only. Bands as Lighthouse defines them: good 90 to 100, needs improvement 50 to 89, poor below 50. Reported as its own distribution, never as Core Web Vitals.
- Crawl outcomes
- In order of precedence: robots.txt disallows, domain does not resolve, TLS error, no response (timeouts after the retry), blocked (bot check, firewall, HTTP 401, 403 or 429), other HTTP error, not HTML, parked domain, measured.
- Timeouts and limits
- 90 seconds per request, at most 10 redirects, 6 MiB per homepage, 4 sites at a time and one request at a time per site.
- Business locations and website addresses: © OpenStreetMap contributors, available under the Open Database License. OpenStreetMap copyright and licence
- The licence for the OpenStreetMap data used here: Open Data Commons Open Database License (ODbL)
- City boundary: Australian Statistical Geography Standard, Edition 3 (2021), Australian Bureau of Statistics, Creative Commons Attribution 4.0. ABS copyright and Creative Commons licence
- Field data: Chrome UX Report (CrUX) dataset by Google, Creative Commons Attribution 4.0 International. CrUX methodology and licence
Download the data
Questions about the study
Why does the study only cover Canberra so far?
Canberra was the first city we crawled, as a pilot of the method. More cities are planned for this page, each crawled the same way and listed with its own crawl date.
Can I see which businesses were sampled?
No. We do not name any sampled business, and the published files hold counts only, with no website address, business name or location.
Where do the Core Web Vitals figures come from, and why do so few sites have them?
They come from Google's Chrome UX Report, which records how real Chrome users experienced each site over 28 days; ours cover 5 September to 2 October 2026. Google only includes sites with enough Chrome traffic, so 63 of our 200 Canberra sites had phone data and 115 had data across all devices. A site missing from the report is neither slow nor fast: it had too little Chrome traffic, or was not publicly discoverable to Google. We report no response times from our own crawler, because it runs from Pakistan and its timings would not reflect what Australian visitors see.
Why are the Lighthouse scores kept apart from Core Web Vitals?
Because they measure different things. Core Web Vitals here are real visits over four weeks to sites with enough Chrome traffic. A Lighthouse score is one simulated page load on Google's servers, which we ran only for the sites without phone field data. Adding the two together would mix real and simulated results, so each is reported with its own base.
How reliable is the platform detection?
It reads the signals each platform leaves in a homepage's HTML and headers, and it has not been tested against a list of known platforms. 14 of the 162 homepages matched no rule and are reported as not identified rather than guessed.
Does a site that blocks zoom fail accessibility law?
This study does not say so. It records that a homepage asks phones to block or limit zoom, which the axe accessibility rule for WCAG success criterion 1.4.4 flags. Some phone browsers ignore that request, and we did not test which.
Saad Ali, Founder / CEO, Digitalis Global
Drafted with AI assistance; researched and reviewed by Saad Ali.