A bad website is not defined by an unpopular colour scheme or a designer’s personal taste. It is defined by measurable failures that stop search engines from fetching, rendering, understanding,...
A bad website is not defined by an unpopular colour scheme or a designer’s personal taste. It is defined by measurable failures that stop search engines from fetching, rendering, understanding, or efficiently navigating its pages.
The practical question is therefore not whether a site “feels SEO-friendly”. It is whether its code, links, responses, and rendered content meet observable thresholds. The tests below turn common technical complaints into evidence a marketing lead can use to prioritise fixes.
Assess a website in three states: the raw HTTP response, the rendered page after JavaScript execution, and the crawl graph formed by internal links. A page can pass one state and fail another. For example, the browser may display a complete product description while the initial HTML contains only an empty application shell.
Use a fixed sample rather than testing only the homepage. A sensible minimum is the homepage, one representative template for each important page type, the five highest-value landing pages, and any pages already showing organic impressions. Repeat tests from a mobile user agent and, where possible, from more than one crawl location.
The following thresholds are operating limits for diagnosis, not claims that every search engine uses the same cut-off. Google’s published Core Web Vitals guidance defines good Largest Contentful Paint as 2.5 seconds or less, Interaction to Next Paint as 200 milliseconds or less, and Cumulative Layout Shift as 0.1 or less at the 75th percentile. Those are useful performance targets, but they do not by themselves prove that a page is crawlable or indexable.
| Fault | Metric that exposes it | Threshold |
|---|---|---|
| Render-blocking resources | Lighthouse render-blocking audit; estimated delay before first contentful paint | Investigate when blocking resources add more than 200 ms; treat more than 1 second as a priority defect |
| Client-side-only content | Text and links in raw HTML compared with the rendered DOM | Priority content missing from raw HTML, or more than 10% of important copy added only after JavaScript |
| Broken internal linking | Internal link status-code report and crawl-depth analysis | Any important page returning 4xx or 5xx; more than 1% broken internal links across the sample needs remediation |
| Intrusive interstitials | Mobile viewport screenshot, overlay dimensions, and time or interaction required to dismiss | Any overlay covering primary content on entry, or a dismissal control that is not available within 1 second |
| No crawlable navigation | Count of ordinary anchor links in raw HTML and reachable-page crawl coverage | Fewer than one crawlable path to an important page, or more than 5% of priority pages unreachable without a sitemap |
Browsers generally need to process some CSS and JavaScript before they can paint meaningful content. The SEO risk appears when a page loads large or poorly prioritised files before showing the content a user and crawler need.
Run Lighthouse in a mobile configuration and record the “render-blocking resources” audit, the estimated savings, First Contentful Paint, and Largest Contentful Paint. Then inspect the page waterfall in browser developer tools. A stylesheet that delays first contentful paint by 80 milliseconds is not equivalent to a chain of scripts that delays it by 1.4 seconds.
Use 200 milliseconds of estimated blocking time as a triage threshold and 1 second as a high-priority threshold. These are practical investigation limits, not search-engine rules. Also record the 75th-percentile field data where available. Google’s Core Web Vitals guidance uses the 75th percentile for its pass/fail assessment, so an isolated fast test should not overrule consistently slow real-user data.
Measure whether the blocked content is commercially important. A page can have poor laboratory performance but still expose its title, headings, copy, and links immediately in the HTML. Conversely, a visually simple page can be an SEO problem if its largest heading and product information appear only after a long JavaScript chain.
What not to do: do not remove every script simply because an audit labels it blocking. Analytics, consent, personalisation, and application functionality may have legitimate requirements. Identify the resource, quantify its delay, and test whether it can be deferred, split, inlined, or loaded only on templates that need it.
A search crawler may render JavaScript, but relying on rendering is still a measurable dependency. Rendering can require additional processing, can fail when scripts error, and can leave the crawler with a different page from the one a browser user sees.
Fetch a URL without executing JavaScript and save the response body. Then render the same URL in a browser or crawling tool and export the final DOM. Compare the page title, canonical, main heading, body copy, product data, navigation links, and structured content. A difference is not automatically a defect; the question is whether priority content exists only after execution.
Use a clear threshold: if an important page’s primary copy, key heading, price, or internal links are absent from raw HTML, treat it as a priority issue. For bulk templates, flag pages where more than 10% of the important text identified in the rendered DOM is added only by JavaScript. The percentage must be calculated from a defined content set, not from every whitespace character or tracking label.
Also record JavaScript errors, response status, and render time. A failed request for the main application bundle can turn hundreds of apparently valid URLs into empty shells. Test with JavaScript disabled as a diagnostic, not as a claim about how every crawler behaves.
Popular advice is sometimes wrong here: “Google can render JavaScript” is not a reason to put all SEO content in JavaScript. Rendering capability does not guarantee identical execution, immediate processing, or reliable discovery of every link. Server-rendered or statically generated critical content reduces that dependency and makes the HTML testable.
Internal linking is measurable as a graph. Each URL is a node, each crawlable internal anchor is an edge, and HTTP responses determine whether an edge leads somewhere valid. This removes subjective arguments about whether a page has “enough” links.
Crawl the site with a controlled user agent and export every internal source URL, destination URL, anchor element, and response status. Separate navigational links from canonical tags, XML sitemap entries, redirects, and manually supplied URL lists. A 404 destination linked from a high-value page is a direct defect. A 301 may be acceptable temporarily, but a site-wide pattern of chained redirects creates avoidable latency and weakens maintenance.
Set these operational limits:
Do not treat a sitemap as a substitute for broken internal links. A sitemap can provide discovery input, but it does not demonstrate that users or crawlers can navigate from one relevant page to another. Likewise, adding hundreds of footer links is not a reliable fix; measure whether those links are valid, relevant to the template, and present in crawlable HTML.
An interstitial becomes an SEO concern when it obstructs access to the page’s primary content, particularly on mobile. Measure it rather than debating whether a pop-up looks aggressive.
Test a clean session at a 360-pixel-wide mobile viewport and record whether an overlay appears before the page content, how much of the viewport it covers, whether the underlying heading and copy remain readable, and how long dismissal takes. Capture screenshots at 0, 1, 3, and 5 seconds. Repeat for an organic landing URL, not just the homepage.
Use a strict operational threshold: an overlay that covers primary content on entry is a defect requiring review. A dismissal control should be visible and usable within 1 second of the overlay appearing. Record the overlay’s viewport coverage as a percentage: overlay pixels divided by viewport pixels. Do not hide the close button outside the viewport or require a form submission before access to the page.
Consent notices and legally required disclosures may need special treatment. Measure their behaviour separately from promotional interstitials. A banner that occupies 15% of the viewport and leaves the main heading readable is not the same as a full-screen promotion that blocks the page, even if both are technically “pop-ups”.
What not to do: do not assume a two-second delay makes an interstitial safe. Timing is only one variable. A delayed overlay can still interrupt the visit, obscure content, and create poor mobile interaction. Test the page at entry, after scrolling, and after returning via the browser back button.
A site has a crawlable navigation problem when important URLs are available only through search forms, click handlers, filters, or an XML sitemap. The decisive test is whether an ordinary HTML anchor provides a path from a crawlable page.
In the raw HTML, count links whose destinations are valid HTTP or HTTPS URLs in standard href attributes. Exclude JavaScript click handlers, buttons that mutate the URL, links hidden behind a search submission, and anchors that require a user gesture to create their destination. Then crawl from the homepage and key hub pages with JavaScript disabled.
Set the reachability threshold at one valid crawlable path to every priority page. For a larger audit, flag more than 5% of priority URLs that are present in a supplied inventory or sitemap but unreachable through ordinary internal links. Record click depth as well: a page that requires 12 clicks is technically reachable but operationally weak.
Faceted navigation needs separate measurement. Count the number of crawlable filter combinations generated, the percentage returning unique indexable content, and the percentage returning duplicate or empty results. If 90% of generated combinations lead to no unique landing page, do not expose all of them as crawlable links. Use controlled linking, canonicalisation, or blocked crawl paths based on the intended indexing strategy.
Do not “fix” navigation by adding a giant list of every URL to every page. That inflates HTML, creates irrelevant edges in the crawl graph, and makes the important paths harder to identify. Build measurable hubs: category pages link to relevant subcategories and products, editorial pages link to the related commercial pages, and every priority destination has a short, valid path.
Run the checks in this order so that one failure does not conceal another:
Prioritise failures that affect many URLs, remove access to high-value pages, or hide core content from the raw response. A one-template navigation defect affecting 20,000 product pages is usually more urgent than an isolated 300-millisecond script on a low-value article. Keep the evidence: URL, timestamp, device condition, metric, threshold, owner, and retest result.
That is how to identify a bad website without relying on design preference. The diagnosis is defensible when another analyst can reproduce the crawl, see the same missing links or content, and compare the result with an explicit threshold.
Want the measurement, not the pitch?
Send us your domain. We run the baseline on your category prompts and send back the raw answers alongside the score — you can check our working.
Đội ngũ chuyên gia Vidco Group sẵn sàng đồng hành cùng bạn
Bước 1 / 4
Chúng tôi sẽ liên hệ trong vòng 2 giờ làm việc.