Search Console "An error occurred" on Test Live URL

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.
2. 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.
3. Start with our free 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. We wanted Google to test them and then index them, so we did what Google documents:

1. Open Google Search Console, then Pages.
2. Use URL inspection on any URL of the domain.
3. The result says "URL is not on Google".
4. Press "Test live URL".
5. 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). 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:

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. If you would rather have someone fix what it finds, that is what our SEO services are for.