598 Ostrava business websites: availability and performance findings

How do business websites in Ostrava hold up? On 14 September 2026 I checked 598 websites of local shops, restaurants, offices and services listed in OpenStreetMap. I recorded availability, transport security and selected elements in fetched HTML, plus mobile laboratory performance where Google PageSpeed could measure it. This was not a security audit or a visual mobile test of every site. The methodology and aggregated data are below.

Quick answer: what the measurement showed

• 93 of 598 websites (15.6%) were unreachable during measurement: the listed address did not exist, the server did not respond or returned an error.
• 10.9% of fetched HTML lacked meta viewport (52 of 477). This alone does not establish an unusable mobile layout.
• 14.8% did not redirect http to https in the test (70 of 474) and 6.9% do not run on HTTPS at all (33 of 477).
• 29.6% of fetched HTML lacked meta description (141 of 477). H1 was absent in 28.1% after excluding HTML smaller than 15 kB (118 of 420); this filter does not reliably identify JavaScript-rendered pages.
• 71.3% lacked a tracked business JSON-LD type in fetched HTML (340 of 477). This does not measure whether Google or AI recognise the company.
• Only 4.2% scored 90 or more in the mobile PageSpeed lab test (19 of 453); the median was 57 out of 100.

Method and public data

• Where the business list comes from: the open map OpenStreetMap (ODbL licence), all businesses within the city of Ostrava that list a website. This is businesses recorded in the map, not a random or representative sample of all Ostrava companies.
• What I excluded: schools, kindergartens, public offices, banks, pharmacies, hospitals and other institutions (252 records), links to aggregators, social networks and government sites (144), chains, meaning domains listed at three or more places in Ostrava (365 records), and duplicate domains (45). The chain rule also removed a few local businesses with several branches; it is the more cautious option. 598 unique domains remained.
• When and how: 14 September 2026, one request to the homepage (HTTPS, falling back to HTTP) and one to check the http to https redirect. An identifiable User-Agent LeArtistStudie/1.0 with a contact link.
• Respect for the sites: I fetched robots.txt first. Domains that disallow crawling the whole site were not measured. I publish only aggregated figures, no company names and no result tied to a specific website.
• What I measured in the HTML: HTTPS and redirects, the HSTS header, mixed content (images, scripts and styles loaded over http), the mobile viewport, title, meta description, the H1 heading, JSON-LD structured data, a share image, a clickable phone number, a form, the footer year, server response time and HTML size.
• Speed: Google PageSpeed Insights API, mobile strategy, lab measurement (Lighthouse), plus real-user data from the Chrome UX Report for sites with enough traffic.
• Limitations: HTML was read without executing JavaScript. Headings or structured data may appear after rendering. Excluding HTML under 15 kB is only a heuristic, not proof of absence in the browser. Responsiveness and search-engine understanding were not directly tested. Server response is a single measurement from one location. Websites returning 403 or unavailable websites are excluded from the content percentages.

Download the anonymised aggregated dataset as CSV. The file contains metrics with numerator, denominator and a method note, without company names.

Finding 1: nearly one in six websites could not be fetched in this check

Of 598 websites, the homepage loaded for 477 (79.8%). 93 websites (15.6%) were unreachable: the address did not exist, the server did not respond within 15 seconds or returned an error. Another 22 sites refused the automated request with bot protection, 4 addresses did not lead to a web page and 2 sites disallowed measurement in robots.txt, which I respected.

Some addresses may belong to closed businesses or be outdated map entries. A single automated request does not establish permanent downtime for all visitors. Failure is a reason to verify the address, server status and access in a normal browser.

Finding 2: HTTPS and related transport settings

• 93.1% of measured websites run on HTTPS (444 of 477). Browsers mark the remaining 33 sites as not secure.
• 14.8% did not redirect http to https in the test (70 of 474). A particular browser may also apply its own HTTPS mode or stored HSTS policy.
• Only 30.8% sent an HSTS header (147 of 477). This instructs the browser to use HTTPS for the configured max-age, not forever. HSTS explained.
• 7.9% of HTTPS sites contained HTTP references to images, scripts or styles (35 of 444). A browser may upgrade or block such resources; this scan did not verify their actual browser loading.

Finding 3: 52 fetched pages lacked viewport metadata

10.9% of fetched HTML lacked meta viewport (52 of 477). Viewport settings affect mobile layout, and absence may lead to a wide default viewport with the page scaled down. Without rendering, the actual appearance and usability remain unverified. Check readability, overflow and controls on a phone; missing tags cannot be counted as proven mobile failures.

Finding 4: search basics are missing more often than they should be

• 97.7% of websites have a page title (466 of 477), which is fine.
• 29.6% of fetched HTML lacked meta description (141 of 477). Google primarily creates snippets from page content and may use the description when more suitable. An absent tag does not itself establish an unsuitable snippet.
• 32.5% of fetched HTML lacked an H1 (155 of 477). After excluding HTML smaller than 15 kB, the figure was 28.1% (118 of 420). The filter does not guarantee exclusion of every JavaScript-rendered page.
• 48.6% of HTML contained exactly one H1 (232 of 477). The count alone does not determine heading clarity or SEO quality.

For a specific site, I verify these findings against visible content and indexing. In SEO for Ostrava businesses, they are prompts for investigation, not an automatic list of cheap fixes or a ranking forecast.

Finding 5: 71.3% of fetched HTML lacked tracked business JSON-LD

• 28.7% contained a tracked business JSON-LD type, such as LocalBusiness, Restaurant or Store (137 of 477). It was not found in the fetched HTML of the remaining 71.3%. Structured data helps Google interpret content, but its absence does not mean a company cannot be identified from text or other sources. This study tested neither AI answers nor correct business recognition.
• 42.8% of fetched HTML contained a social share image (og:image) (204 of 477). Without it, a platform may select its own preview; actual sharing results were not tested.
• 38.8% of websites have a clickable phone number on the homepage (185 of 477). For a business contacted from mobile, test whether a phone link helps; implementation determines the cost.

Finding 6: a third of displayed footer years were older than 2025

226 websites displayed a copyright year. For 31%, it was older than 2025 (70 of 226). This records footer text, not proof of a closed business, neglected maintenance or an outdated offer.

Finding 7: server response, HTML size and detected platform

• Median server response is 201 ms, 13.4% of websites respond slower than 800 ms (64 of 477).
• Median HTML size is 84 kB uncompressed.
• 27.9% of fetched HTML had a detected WordPress signature (133 of 477). Wix, Webnode and Shoptet signatures were each below 4%. These are HTML-based detections, not complete technology verification.

Finding 8: mobile laboratory performance and visitor data

• Median mobile performance is 57 out of 100 according to Google PageSpeed (453 measured websites).
• Only 4.2% of websites score 90 or more on mobile (19 of 453), which Google rates as good. A third of websites (33.3%) score below 50 (151 of 453).
• 87.9% of websites had laboratory LCP above 4 seconds (398 of 453). The median was 9.5 seconds. LCP records rendering of the largest eligible content element in that test. Simulated conditions do not measure every actual phone.
• 11.7% had laboratory CLS over 0.25 (53 of 453). Shifts can make controls harder to use, but this study did not measure actual accidental taps.
• CrUX data containing LCP was available for 62.9% of measured sites (285 of 453). Within this subset, the API overall category rated 41.4% as fast (118), 35.1% as average (100) and 23.5% as slow (67).

The 201 ms median response comes from a different measurement than mobile PageSpeed. Their difference cannot identify the cause of slow LCP. That requires profiling a specific URL and breaking down its loading process.

What this means for a business owner

The study does not establish repair time or cost. These depend on cause, access and platform. Start with important tasks on your own website:

1. Open the address listed in maps and directories. Recheck failures; an automated test may encounter temporary issues or bot protection.
2. Verify HTTPS and redirects. Have the maintainer check the certificate, server settings and dependent resources.
3. Complete a typical task on a phone. Check viewport settings and the actual layout, readability and forms. A tag alone does not create responsiveness.
4. Review titles, descriptions and heading structure. Assess content and current search results, not just tag counts.
5. State the service, address and contact clearly. Appropriate JSON-LD can supplement accurate information; it guarantees neither Maps positions nor AI citations.
6. Test contacts and check the offer is current. The footer year is weaker evidence than a working phone link and accurate information.

I help with specific repairs through website care. An audit of scope and cost should guide repair versus replacement, not a scan finding count. See website development in Ostrava for the new-project process.

Frequently asked questions

How do I find out how my own website is doing?

The free website check provides indicative automated findings. It is not a complete security audit or a visual mobile usability test. Verify suspicious findings on the specific page in a browser and with its maintainer.

Is the sample representative of all businesses in Ostrava?

No. It describes businesses recorded in OpenStreetMap with a listed website. Shops and hospitality are recorded more often than offices or tradespeople, and companies without a website are not in the sample at all. Read the figures as a picture of this group, not the whole city.

Why are results missing for some sites?

HTML results are missing for 121 of 598 websites: 93 were unreachable or returned a server error, 22 refused the automated request with bot protection, 4 addresses did not lead to a web page and 2 sites disallowed measurement in robots.txt. In addition, Google PageSpeed could not measure speed for 24 websites because they refused the Lighthouse test or did not respond in time.

Will you publish which sites did badly?

No. The study is not meant to shame specific companies. Per-site results stay private and the published dataset contains aggregated figures only.

Sources and links

• Business list: © OpenStreetMap contributors, ODbL licence
• Speed: Google PageSpeed Insights API v5
• Related: AI crawlers and 30 Czech e-shops: what the study found