# Search Console "An error occurred" on Test Live URL Source: [Home](https://www.nfw.run/en)[Blog](https://www.nfw.run/blog) // article Published: October 27, 2026Written by [Enrico Pasetto](https://www.linkedin.com/in/enrico-pasetto) () - [The studio](https://www.nfw.run/blog/tag/studio) - [State of the web](https://www.nfw.run/blog/tag/state-of-the-web) ![Google Search Console: An error occurred, try again in a few hours.](https://www.nfw.run/blog/google-search-console-heavy-page/cover-en.webp) ## In short: what it means for your business Google Search Console has a button that asks Google to load one of your pages right now and show what it sees. Inspecting our city reports said "URL is not on Google", and the live test failed with "An error occurred, try again in a few hours". It failed again when we retried hours later. The error message is generic: it gives no reason. But on the same site, our lighter pages passed the live test and could be indexed, while the heavy report pages failed. Same server, same Search Console property: the clear difference between the pages that passed and the ones that failed was weight. After we made the report pages much lighter, the test completed. Google does not state the cause, so we cannot quote it, but the evidence points one way. What changed: the JavaScript a visitor's browser has to download for one of our report pages fell from 2.81 MB to 1.04 MB, and the total weight transferred (HTML plus JavaScript, compressed) went from 947 KB to 461 KB. Visitors see the same pages. The charts and maps are simply drawn in a lighter way. What to take from it, if you run a website: 1. **A page can look fine to a visitor and still be too heavy for Google to test.** A fast laptop on good wifi hides the problem. 1. **Run the live test on your heaviest pages, not only on the homepage.** If it fails, ask your developer what is loaded before the page can show anything. 1. **Start with our [free SEO audit](https://www.nfw.run/seo-audit).** It is the first check we run on any site, ours included. Read on for the exact steps, the numbers and what we changed. ## The symptom The pages involved are the city reports of our State of the Web, for example the [Verona report](https://www.nfw.run/state-of-the-web/verona-city). We wanted Google to test them and then index them, so we did what Google documents: 1. Open Google Search Console, then Pages. 1. Use URL inspection on any URL of the domain. 1. The result says "URL is not on Google". 1. Press "Test live URL". 1. The test fails with "An error occurred, try again in a few hours". We waited, as the message says, and tried again hours later: same error. (The Search Console interface may show these strings in your language: we quote the English ones.) ## What we think was going on We want to be careful here, because Google does not document what makes the live test fail, and the error message gives no reason. What we have is a comparison inside one site. The lighter pages passed the live test and could be indexed. The heavy report pages failed it. Same site, same server, same Search Console property: the only difference we found was page weight. The error also went away on the report pages after we reduced their weight. What is publicly known is that Google renders a page with JavaScript before it judges it, and that it does so within a limited time and resource budget. A page that needs megabytes of script before it can show its content is a plausible way to run out of that budget. Google has not confirmed it, but weight is the one difference between the pages that passed and the ones that failed. The other obvious suspect was the HTML itself. Googlebot has a limit on how much of a file it reads, 15 MB at the time of writing ([Google's documentation](https://developers.google.com/search/docs/crawling-indexing/googlebot)). Our HTML was 857 KB uncompressed, far below it. So the issue was not the HTML, but the scripts that came with it. ## What we measured We measured the Verona report on 27 October 2026, before and after the change: | | Before | After | | ------------------------ | ------- | ------- | | HTML, uncompressed | 857 KB | 852 KB | | HTML, gzip | 107 KB | 126 KB | | Script files loaded | 30 | 25 | | JavaScript, uncompressed | 2.81 MB | 1.04 MB | | JavaScript, gzip | 840 KB | 335 KB | | HTML + JavaScript, gzip | 947 KB | 461 KB | ![Bar chart comparing the weight of the Verona report page before and after: JavaScript uncompressed 2.81 MB then 1.04 MB, JavaScript gzip 840 KB then 335 KB, HTML plus JavaScript gzip 947 KB then 461 KB](https://www.nfw.run/blog/google-search-console-heavy-page/figure-en.webp) The Verona report page, before and after the change JavaScript fell by 63% (2.81 MB to 1.04 MB uncompressed), and the total transferred weight roughly halved. The HTML stayed about the same size, and compressed it even grew a little, from 107 KB to 126 KB. That is expected: the charts and maps are now drawn in the HTML itself as SVG instead of by scripts, so the page has 212 SVG elements instead of 122. We moved the weight from scripts, which have to be downloaded and run before anything shows, to markup, which the browser can display as it arrives. ## Where the weight came from Two libraries were loaded up front on every report page: - **MapLibre GL**, the interactive map library: a single script of 1.08 MB by itself. - **Recharts**, the chart library: 476 KB. Both are good tools, and both are what you reach for when you want a map you can drag or a chart that reacts to the mouse. But a report page is mostly something to read. Most visitors never drag the map, and Google certainly does not. ## What we changed The commit is called "rewritten heavy pages to have less html and js", and it does two things: - **The charts are drawn on the server as plain SVG.** SVG is a picture made of text, so the chart is part of the page when it arrives and needs no library to appear. - **The maps are static pictures generated at build time**, instead of an interactive map the browser has to assemble. Neither MapLibre nor Recharts is downloaded on report pages anymore. What we gave up is the dragging and the hover effects on those pages. For a report, we think it was a fair trade. After the change, the live test in Search Console completes. ## What to do on your own site - **Run the live test on your heaviest pages.** In Search Console, inspect the URL, then "Test live URL". A page that works for visitors can still fail here. - **Look at what loads before the page can show anything.** Browser developer tools, the Network tab, will list the scripts and their size. A map library, a chart library or a page builder you only use on one section is the usual culprit. - **Do not load a heavy library on every page for one widget.** Load it where it is needed, or replace it with something simpler where a picture is enough. - **Keep content in the HTML.** If what you want Google to read arrives only after scripts run, you are asking for trouble. If you want a first look at your site, run our [free SEO audit](https://www.nfw.run/seo-audit). If you would rather have someone fix what it finds, that is what our [SEO services](https://www.nfw.run/seo-services) are for. ## Related services If you want to go from reading to doing: - [SEO services](https://www.nfw.run/seo-services) ## More to read [All articles](https://www.nfw.run/blog) ![Title card of the video: PHP2Shell, two PHP flaws, NFW Web Studio](https://www.nfw.run/blog/php2shell-php-vulnerability/video-poster-en.webp)Video October 22, 2026SecurityState of the web ### [PHP2Shell: two PHP flaws on half the sites we scan](https://www.nfw.run/blog/php2shell-php-vulnerability) Two serious PHP flaws can let a stranger take over a site without a password. What to ask your host, which versions are affected, what our scans show. Watch the video ![Milan businesses: speed, Google and AI readiness, measured in October 2026, with the outline of the city](https://www.nfw.run/blog/milan-websites-state-of-the-web/cover-en.webp) October 20, 2026State of the webWeb presence ### [Milan business websites: what we found in 27,460 sites](https://www.nfw.run/blog/milan-websites-state-of-the-web) We scanned 27,460 websites of Milan businesses: the same slow mobile pages as Verona, a gap in AI readability, thin structured data and old image formats. Read the article ![Verona businesses: speed, Google and AI readiness, measured in October 2026, with the outline of the city](https://www.nfw.run/blog/verona-websites-state-of-the-web/cover-en.webp) October 14, 2026State of the webWeb presence ### [Verona business websites: what we found in 5,000 sites](https://www.nfw.run/blog/verona-websites-state-of-the-web) We scanned almost 5,000 websites of Verona businesses: slow mobile pages, little structured data, old image formats and sites without HTTPS. Read the article ## Got a project in mind? Let's talk. [All articles](https://www.nfw.run/blog) [Book a call](https://www.nfw.run/contact-us)