Home / Free tools / Fetch and render
Fetch and render
Put in a page and pick a crawler. We fetch the HTML the way that crawler would, then open the page in a real browser so the scripts and styles run, and show you what the crawler is left with. Each run opens a browser, one page at a time, so give it a few seconds.
You can paste the address with or without https. We only check pages that are live on the public web.
What rendering actually means
Your server sends Google a file of HTML. That file is the source. Google reads it, then puts the page in a queue to be opened in a headless copy of Chrome, where the scripts run, the styles load and the finished page gets built. That second step is rendering, and it decides what Google indexes.
Two passes, in other words. The first is cheap and happens quickly. The second costs real computing time, so it can arrive minutes or days later. Anything that only exists once the scripts have run is waiting on that second pass, and if rendering fails for any reason, the first pass is all Google has to go on.
This tool does the same two steps. It fetches the HTML, opens the page in a real browser with the crawler's user agent, and shows you what changed.
The /wp-content/ problem
Here is the one we find most often on WordPress and Elementor sites. Somewhere along the way, usually in a security plugin or an old speed guide, a line like Disallow: /wp-content/ ends up in robots.txt.
Google obeys it. The HTML still comes through, so the page looks fine in Search Console. But the stylesheet and the JavaScript live under /wp-content/, and Google is not allowed to fetch them. Chrome opens the page with no CSS and no scripts. Elementor sections that need JavaScript never appear. The layout falls apart. Your page passes a human eye test and fails Google's.
The resources table above shows which files were refused and which rule did it. If you see anything blocked under /wp-content/uploads/, /wp-includes/ or a theme folder, that is your fix, and it is a one line change.
Reading the two word counts
The ratio tells you how much of your text sits in the HTML before anything runs. Near 100% means the page reads fine on the first pass and you have nothing to worry about.
Drop to half and your content is being written by JavaScript. That still gets indexed most of the time, but it indexes later and it breaks more easily. Under about a fifth, treat it as a problem worth fixing, and look at server rendering or static output for the text that matters.
The list of text found only after rendering is the useful bit. Read it properly. If your main heading or your service copy shows up in there, that text is not in the file Google reads first.
Why you only get a few goes an hour
Every run opens a real browser, loads your page with every script and image, takes two screenshots, then shuts the browser down again. That is slow and it costs us money, so we allow a handful of runs an hour per person and we queue them one at a time.
If you hit the limit, wait a while and come back. For checking pages all day long, the URL inspection tool in Search Console is the right place, and it tells you what Google has actually stored rather than what a fresh render looks like.
Want to know if the fix worked?
Partner Rank Tools tracks your Google positions town by town and turns your Search Console data into a ranked list of what to fix next. Seven days free.