Google Crawler Simulator Free Tool

Enter a URL

About Google Crawler Simulator

What This Tool Actually Does

The Google Crawler Simulator on limitlessreferrals.info performs a single, plain server-side fetch of the URL you submit. It sends one HTTP request from a server in Helsinki, Finland, with no user agent header of its own. That means it doesn't identify itself as Googlebot, as Chrome, as Safari, or as anything else. It waits up to sixty seconds for a response, follows redirects, and then displays what came back in five distinct sections.

Those sections are the meta content table, the H1 to H4 tag lists, the indexable links table, the readable text dump, and the raw source code. Each section answers a different question about the page. The meta table tells you what title and description the author wrote. The heading lists show you the outline structure. The links table shows internal links that aren't marked nofollow. The text dump strips all formatting to leave plain words. The source code box shows the exact HTML bytes the server returned.

This tool does not run a browser. It executes no JavaScript. It stores no cookies. It reads no robots.txt file. It sends exactly one request per submission and shows you what a bare HTTP client would receive from that one URL. The entire process takes a few seconds for a normal site and finishes with a "Try New URL" button so you can run another check.

The live test run for this rewrite used example.com. The tool reported the meta title "Example Domain", no description, no keywords, one H1 that also read "Example Domain", an empty indexable links table because the only link on the page points to iana.org and is external, a readable text dump of 139 characters, and a source code view of 757 characters. Those numbers come from the actual run and give you a baseline for what a minimal page looks like through this lens.

You'll find the form right above this article. Type or paste a URL into the single input field, press Submit, and the results appear on a new page. The tool accepts http and https addresses, strips the protocol, forces http in front, and follows whatever redirects the server sends. Most modern sites will redirect you to their https version automatically, and the tool lands there without complaint.

How to Use This Tool

The workflow takes less than a minute from start to finish. You submit one URL, read five sections, and draw your own conclusions about how a server-only view of your page compares to what a real search engine crawler would process.

1. Open the tool page. Find the input box above this article and make sure you're on the Google Crawler Simulator page at limitlessreferrals.info.
2. Enter a full URL. Type or paste the address you want to check, including the domain name and any path, for example https://example.com/products/widget.
3. Submit the form. Press the Submit button. The tool sends one request from its server with no user agent and waits up to sixty seconds for a reply.
4. Read the Meta Content table. Check the title, description, and keywords rows. Missing values show as "No Title", "No Description", or "No Keywords".
5. Scan the headings and links. Look through the H1 to H4 tables for your outline structure, then review the Indexable Links table for internal links without nofollow.
6. Compare the text and source. Read the Readable Text Content box for the stripped words, then open the Source Code box to see the raw HTML exactly as received.

There's no login, no API key, no configuration panel, and no options for setting a custom user agent or choosing a geographic location. You get one fetch, five sections, and a clean result page. If you want to check another URL, click "Try New URL" at the bottom and start again.

What the Five Output Sections Show

The Meta Content table lists the page's meta title and description. It lists three rows labeled Meta Title, Meta Description, and Meta Keywords. The tool reads only the classic meta name="description" and meta name="keywords" tags. Open Graph tags like og:title or og:description are ignored entirely, as are Twitter card tags. If a tag is absent, the cell reads "No Title", "No Description", or "No Keywords". The example.com run showed a title of "Example Domain" and no description or keywords at all.

The H1 to H4 Tags section follows. The tool creates one small table for each heading level that exists on the page, listing the text of every H1, H2, H3, and H4 it finds. H5 and H6 tags are ignored completely. The headings appear grouped by level, so all H1s come first, then all H2s, then all H3s, then all H4s. The original nesting order across levels is lost. If your page has an H2 before an H1 in the HTML, the tool still lists the H1 first.

The Indexable Links table shows numbered rows for internal links only. Internal means the link points to the same host, with or without the www prefix, or uses a root-relative path like /about. External links are not listed at all. The example.com page has one link to iana.org, which is external, so its links table is completely empty. The URL appears in a row only when the link has no rel="nofollow" attribute. An internal nofollow link produces a numbered row with an empty cell where the URL should be.

The Readable Text Content box is a read-only text area containing the page's words with all HTML tags removed. The tool strips script blocks, style blocks, line breaks, tabs, and collapses runs of spaces into single spaces. It does not insert a space where two block elements meet, so words from adjacent elements run together. The example.com text dump began with "Example DomainExample DomainThis domain is for use in documentation examples" because the title text, the H1 text, and the paragraph text were concatenated without separators.

The Source Code box is the final section. It shows the raw HTML exactly as the server sent it, character for character, with no reformatting and no syntax highlighting. This is the ground truth of what your server delivered. If the readable text looks wrong, compare it against this source to see whether the problem is in your HTML structure or in the tool's tag stripping.

How This Differs From What Googlebot Really Does

Googlebot in 2026 is a rendering crawler. Since 2019, Google has used an evergreen Chromium instance to render pages and execute JavaScript before indexing the results. When Googlebot visits your site, it sends a specific user agent string that identifies it as Googlebot, it fetches from Google's own IP ranges, and it obeys the rules in your robots.txt file. It renders the full page, waits for JavaScript to execute, and then processes the resulting DOM.

This tool does none of those things. It sends no user agent at all, which is a meaningful difference. Many servers treat requests without a user agent differently from requests with one. Some sites block them outright. The live Wikipedia test demonstrated this clearly. When the tool fetched www.wikipedia.org, Wikipedia refused the request because it came without a user agent, and the tool responded with the bare text "Input Site is not valid!".

Googlebot also reads and respects robots.txt. This tool never checks for a robots.txt file. If you block Googlebot in your robots.txt, Googlebot won't fetch the page. This tool will fetch it anyway, assuming the server accepts a user-agent-less request. The two tools answer different questions. Googlebot tells you what Google will index. This tool tells you what a bare HTTP client receives from your server when no one identifies itself.

Rendering is the other major difference. Googlebot executes JavaScript and indexes the rendered DOM, which means content added by client-side scripts is visible to Google. Nothing on the page is executed; the raw HTML is shown as received. It fetches the raw HTML and shows you exactly that. If your page builds its content with JavaScript, this tool will show you an empty shell where Googlebot would show a fully populated page.

The tool returns the page's title and meta description. This tool gives you a server view, the view a very basic client would get. Googlebot gives you a rendering view. For pages that are fully server-rendered, the two views will be close. For pages that depend on JavaScript, they will diverge sharply. Use this tool to check your server output and use Google Search Console or the URL Inspection tool to see what Google actually renders.

Correcting the Old Description of This Tool

The previous version of this page made several claims that the actual code does not support. Those claims need correction because they misled readers about what the tool can and cannot do. The old copy described the tool as fetching pages "as Googlebot" or with a Googlebot user agent. The code sends no user agent header whatsoever. The request is anonymous in the sense that it carries no identifying browser or crawler string.

The old description also claimed the tool reports HTTP status codes, canonical tags, robots directives, images, alt text, external links, word counts, and link counts. None of these appear in the output. The tool shows five sections only, and none of them include status codes or response headers. The meta table covers title, description, and keywords only. The links table covers internal links without nofollow. There is no canonical row, no robots row, no image list, and no alt text anywhere in the results.

Another old claim was that the tool renders JavaScript or shows the rendered DOM. It does not. The Source Code box shows raw HTML as received, and the Readable Text Content box is built from that same raw HTML before any tag replacement. Nothing is executed, nothing is rendered, and nothing is interpreted by a browser engine.

The old copy said the tool lists nofollow links and anchor text. The Indexable Links table does neither. A nofollow internal link produces a numbered row with an empty cell, and the anchor text of any link is never displayed. The old description said the tool checks robots.txt. It does not. The fetch happens with no robots.txt lookup and no meta robots parsing.

These corrections matter because the tool's actual value is different from what the old copy promised. The real value is a clean, server-side view of your page's HTML structure. That view is useful for checking whether your title tag is present, whether your heading hierarchy makes sense, whether your internal links use nofollow correctly, and whether your text content survives a tag-stripped read. Those are real diagnostics, and they don't require pretending the tool is something it isn't.

Reading the Meta Content Table Correctly

The meta table is the first thing you see after submission, and it's the section most people check first. The title row shows the contents of your title tag. The description row shows the contents of your meta name="description" tag. The keywords row shows the contents of your meta name="keywords" tag. That's the complete scope. No other meta tags are read.

The keywords row deserves special attention because Google hasn't used the keywords meta tag for ranking in many years. The tag persists in old templates and in some content management systems, but its absence means nothing for search performance. If the tool shows "No Keywords", your page is in the company of example.com and most modern sites. If it shows keywords, those words are likely leftovers from an older era of SEO practice.

The description tag matters more. Google sometimes uses the meta description as the snippet text in search results, though it also generates snippets from page content when the description is weak or missing. A missing description doesn't prevent indexing, but a well-written description gives Google a clear option for your snippet. The tool's "No Description" message is a signal to write one if you care about how your page appears in search results.

The title tag is the most important row in this table. Titles appear in search results as the clickable headline, in browser tabs, and in social media shares. A missing title means Google must generate its own headline from page content, which often produces awkward truncation. The tool's "No Title" message is a clear signal that your page lacks a fundamental piece of on-page metadata.

One quirk of this table involves lowercase replacement. The tool lowercases the words Title, Description, Keywords, Content, Meta, and Name throughout the fetched HTML before parsing. This is a workaround for uppercase tag names in vendor-generated code. The side effect is that those words appear lowercased inside displayed title and heading text. A page titled "Product Description Page" would show as "Product description Page" in the results. The sibling Meta Tags Analyzer showed Wikipedia's "Name" article as "name - Wikipedia" for the same reason.

Reading the H1 to H4 Tables

The heading section creates one table per heading level that exists on the page. If your page has H1s, you'll see an H1 table. If it has H2s, you'll see an H2 table. The same applies to H3 and H4. H5 and H6 are ignored entirely, so a page that only uses H5 tags will show no heading tables at all.

Each table lists the text content of every heading at that level. The text is extracted from the HTML, so it includes any inline elements like spans or strong tags. The tool does not show the heading hierarchy across levels. All H1s are grouped together, then all H2s, and so on. If your page structure interleaves levels, like an H2 followed by an H3 followed by another H2, the tool will show all H2s in one table and all H3s in another, losing the original order.

This grouping makes the heading section useful for a specific diagnostic. You can check whether your page has exactly one H1, which is a common recommendation for content pages. You can see whether your H2s represent the major sections of your article. You can verify that your H3s and H4s are used consistently as sub-sections. What you cannot see is whether the nesting order in the HTML matches the visual hierarchy on the rendered page.

The heading text is also subject to the lowercase replacement quirk. The words Title, Description, Keywords, Content, Meta, and Name appear lowercased even when they appear inside heading text. A heading that reads "Product Description" will display as "Product description" because the tool lowercases the word Description before it extracts the heading text. The readable text box is built before that replacement, so it shows the original capitalization.

The heading tables tell you about structure, not about quality. A page with one H1 and well-organized H2s passes the structural test even if the writing is poor. A page with no H1 at all fails the structural test even if the content is excellent. Use this section as a quick outline check, then read the text dump to judge the actual content.

Reading the Indexable Links Table

The links table shows internal links that the tool considers indexable, which means links without a rel="nofollow" attribute. The table numbers each row and displays the URL of the linked page. Internal links are defined as links to the same host, with or without the www prefix, or root-relative paths like /contact. External links to other domains are not listed at all.

The example.com run produced an empty links table because the page's only link points to iana.org. That link is external, so the tool skips it entirely. A page with internal links will show numbered rows with the full URLs. A page with internal nofollow links will show numbered rows with empty cells, because the tool creates a row for every internal link but only prints the URL when the link has no nofollow attribute.

This behavior is a quirk worth understanding. The empty cell doesn't mean the link is broken or missing. It means the link exists and carries a nofollow attribute. The tool deliberately withholds the URL in that case, which limits the diagnostic value. You can see that a nofollow internal link exists, but you cannot see where it points. If you need to audit which internal links carry nofollow, this table will frustrate you.

The table also omits anchor text entirely. You cannot see what words were linked, only the destination URL for non-nofollow links. This makes the table useful for counting internal links and checking their destinations, but useless for anchor text analysis. The Links Counter tool on this site counts a page's internal and external links.

The absence of external links from this table is by design. The tool focuses on internal linking because that's the part of your link graph you control directly. External links matter for other reasons, but they don't contribute to your internal site structure. If you need to audit your outbound links, use a different tool that lists them explicitly.

Reading the Readable Text Content Box

The text dump is the closest thing this tool offers to a search engine spider view of your page's words. The tool removes all HTML tags, strips script and style blocks, deletes line breaks and tabs, and collapses runs of spaces into single spaces. What remains is the text content of your page in the order it appears in the HTML.

The tool does not insert spaces where block elements meet. When one element ends and another begins, the tool simply concatenates their text. The example.com dump began with "Example DomainExample DomainThis domain is for use in documentation examples" because the title text, the H1 text, and the paragraph text were joined without separators. This makes the dump hard to read for pages with many block elements.

The run-together text is a known artifact of the tag-stripping method. A more sophisticated text extractor would insert spaces at block boundaries, producing readable sentences. This tool does not do that. You should read the dump knowing that words from adjacent elements will run together and that this is a limitation of the implementation.

The dump is still useful for two purposes. First, it shows you the order of text as it appears in the HTML source, which may differ from the visual order on the rendered page. Second, it gives you a rough sense of the text-to-HTML ratio. A page with a large text dump has substantial content. A page with a tiny dump despite a large source code box likely has most of its content hidden in scripts, styles, or images.

The text dump is built from the HTML before the lowercase replacement, so it preserves the original capitalization. The example.com dump showed "Example Domain" with capital letters, matching the source. This means the dump is the most faithful text representation in the entire tool output. If you want to see your page's words without any transformation artifacts, read this box.

Reading the Source Code Box

The source code section shows the raw HTML exactly as the server sent it. There is no reformatting, no syntax highlighting, no line numbering, and no pretty-printing. The bytes in the box are the bytes your server delivered in response to the tool's request. This is the ground truth of your server's output.

The example.com source was 757 characters, which is a very small page. A typical content page will be much larger, sometimes hundreds of kilobytes. The source box displays the entire response, so large pages will produce a very long text area that requires scrolling. The full HTML is there for you to inspect.

Reading raw HTML is a skill that takes practice, but certain patterns are easy to spot. You can check whether your title tag is properly formed. You can verify that your meta description is present and correctly quoted. You can see whether your heading tags are closed properly. You can scan for script tags and see how much of your page depends on JavaScript for content.

The source code view also reveals what the tool actually received, which is valuable for debugging. If the readable text looks wrong, compare it against the source to see whether the problem is in your HTML or in the tool's parsing. If the meta table shows "No Title" but the source clearly contains a title tag, the issue may be malformed HTML or an unusual tag structure that the tool's parser doesn't recognize.

The source code is also where you can spot the difference between what you think you're serving and what your server actually delivers. Content management systems, caching plugins, and CDNs can modify HTML before it reaches the client. This tool shows you the final output after all those transformations. If your CMS adds scripts, modifies headings, or strips meta tags, you'll see it here.

Limitations

The user agent limits the tool. This tool sends no user agent header at all, which means some servers will treat the request as suspicious or block it outright. The Wikipedia test demonstrated this clearly. Wikipedia refuses requests without a user agent, so the tool received an empty response and displayed the bare text "Input Site is not valid!" instead of its normal output layout. Many Cloudflare-protected sites behave similarly.

The second limitation is the lack of rendering. The tool executes no JavaScript, so any content that depends on client-side scripts will be invisible. A single-page application that builds its entire DOM with JavaScript will appear as an empty shell. Googlebot, by contrast, renders pages with an evergreen Chromium and indexes the rendered DOM. This tool cannot tell you what Google sees on a JavaScript-heavy page.

The third limitation is the absence of status codes and headers. The tool follows redirects silently and shows you the final response body, but it never displays the HTTP status code or response headers. You cannot see whether the page returned a 200, a 301, a 404, or a 503. You cannot check the X-Robots-Tag header or the canonical link header. This information is simply not part of the output.

The fourth limitation is the scope of the fetch. The tool fetches exactly one page per submission. It does not crawl the site, follow internal links, or build a picture of your site structure. It does not check robots.txt, meta robots, canonical tags, hreflang attributes, or structured data. It does not analyze images or alt text. Each submission is an isolated single-page check.

The fifth limitation is the heading and link processing. Heading text is shown without the original nesting order across levels. The internal link table omits anchor text and hides nofollow URLs behind empty cells. These restrictions mean the tool gives you a partial view of your page's structure, not a complete link or heading audit.

The sixth limitation is the lowercase replacement quirk. This workaround for uppercase tag names has the side effect of altering displayed text that contains those words. The readable text box is unaffected, but the meta table and heading tables may show altered capitalization.

The rate limit deserves mention. This tool has no CAPTCHA and no tool-specific request cap. A shared site-wide throttle applies to every page of this site. More than fifteen requests within a single second from one visitor address blocks that address for the rest of the day. For normal use, checking a handful of pages, you will never hit this limit. For automated bulk checking, you might.

Practical Use Cases for SEO Work

You can check whether your title and meta description tags are present and correctly formed. Run your homepage through the tool and look at the Meta Content table. If you see "No Title" or "No Description", you have a fundamental on-page SEO problem that needs fixing. The tool gives you a fast, server-side confirmation of what your CMS is actually outputting.

The heading tables are useful for content audits. Run a blog post through the tool and check whether it has exactly one H1. Look at the H2s and see whether they represent the major sections of your article. Verify that H3s and H4s are used for sub-sections rather than being skipped or misused. This structural check takes seconds and catches common content organization problems.

The links table helps you verify that your internal linking uses nofollow correctly. If you have a login page or a privacy policy that you don't want indexed, you might mark those internal links as nofollow. The tool will show empty cells for those rows, confirming that the nofollow attribute is present. For normal internal links, the tool shows the destination URLs, letting you spot broken paths or accidental links to the wrong pages.

The text dump gives you a rough content-length check. A page with a substantial text dump has real content for search engines to index. A page with a tiny dump despite a large source code box probably has most of its visible content delivered by JavaScript or embedded in images. That's a signal to consider server-side rendering or progressive enhancement if you want that content indexed reliably.

The source code view is the debugging tool. When your page looks wrong in the meta table or heading tables, open the source and inspect the actual HTML. You might find malformed tags, duplicate titles, or unexpected CMS modifications. The source view shows you exactly what your server sent, which is the first step in diagnosing any discrepancy between intention and reality.

For comparing different pages, run the tool on several URLs from the same site and compare the heading structures and text dumps. Consistent heading patterns across your content pages suggest a well-maintained template. Inconsistent patterns suggest that individual authors are overriding the template structure. The tool makes these comparisons fast because each run takes only seconds.

When to Use a Real Googlebot Tool Instead

This tool answers the question "What does my server send to a bare HTTP client?" That is a different question from "What does Google index?" If you need the second answer, you should use Google's own tools. Google Search Console's URL Inspection tool shows you the rendered page as Googlebot sees it, including the effect of JavaScript execution. That tool is the authoritative source for how Google views your pages.

For checking robots.txt compliance, you need a tool that reads and respects robots.txt. This tool does not. Google Search Console will show you whether Googlebot is blocked from a page. Third-party crawler simulators that send a real Googlebot user agent and respect robots.txt exist for this purpose, though you should use them carefully because impersonating Googlebot can violate some terms of service.

For checking HTTP status codes and response headers, you need a tool that displays them. This tool follows redirects silently and never shows the status. A simple command-line tool like curl -I will show you the headers, including the status code, the canonical link header, and the X-Robots-Tag header if present. Browser developer tools also show this information in the Network tab.

For checking JavaScript rendering, you need a headless browser. Chrome DevTools, Puppeteer, and Playwright all render pages with a real Chromium engine and let you inspect the resulting DOM. These tools are the closest approximation to what Googlebot does since 2019, when Google moved to evergreen Chromium rendering. This tool cannot substitute for that capability.

For a comprehensive SEO audit, you need a crawler that follows links across your entire site. Tools like Screaming Frog SEO Spider, Sitebulb, and Ahrefs crawl hundreds or thousands of pages and report on titles, meta descriptions, headings, links, images, and structured data across the whole site. This tool checks one page at a time and reports on a narrow set of features.

The relationship between this tool and those tools is complementary. Use this tool for a quick single-page check when you want a fast answer. Use Google Search Console when you need to know what Google actually indexes. Use a full crawler when you need a site-wide audit. Each tool has its place, and none of them fully replaces the others.

Related Tools

The Website Source Code tool shows you the raw HTML of a page with more formatting options, which helps when you need to inspect markup structure more closely than the single source box here provides.

The Meta Tags Analyzer goes deeper into title, description, Open Graph, and Twitter card tags, so use it when you need a fuller picture of your social sharing metadata.

The Links Counter counts and categorizes links on a page, including external links and anchor text, which fills the gap left by this tool's internal-only links table.

Comparing the Live Example.com Run

The live test run for this rewrite provides a concrete reference point for understanding the tool's output. The submission was https://example.com, a domain maintained by the Internet Assigned Numbers Authority for documentation and testing purposes. The page is minimal and shows how the tool handles a basic HTML document.

The Meta Content table showed "Example Domain" as the title, "No Description" for the description row, and "No Keywords" for the keywords row. The example.com page has no meta description and no meta keywords tags, so the tool's fallback messages appeared. The single H1 table listed one heading with the text "Example Domain", matching the title tag.

The Indexable Links table was empty. The example.com page contains one link to iana.org, which is an external domain. Since the tool only lists internal links, that external link was skipped entirely. The Readable Text Content box contained 139 characters of text beginning with "Example DomainExample DomainThis domain is for use in documentation examples without needing permission..." The run-together words at the start demonstrate the block-boundary concatenation quirk.

The Source Code box contained roughly seven hundred and fifty characters of HTML. The actual markup is simple, with a head section containing the title and a body section containing the H1 and one paragraph. The small character count reflects the page's minimal design. This run gives you a baseline for what a tiny, well-formed page looks like through the tool.

Example.com's HTML is simple. It has a title, one H1, one paragraph, and one external link. The tool handled it without errors, and every section behaved as designed. A more complex page will produce more rows in the heading and link tables, but the fundamental behavior remains the same.

Understanding the Wikipedia Blocked Response

The Wikipedia test is the other live reference point from the facts pack. When the tool submitted www.wikipedia.org, the response was not the normal output layout. Instead, the page stopped with the bare text "Input Site is not valid!" This message is the same one that appears for invalid URL input, but in this case the URL was valid. The message appeared because Wikipedia refused the request.

Wikipedia's server policy rejects HTTP requests that do not include a user agent header. The tool sends no user agent, so Wikipedia's server returned an empty response or an error. The tool's fetch received an empty body, and the code treats an empty response body as a failed fetch. The result is the generic "not valid" message, which is misleading because the URL was perfectly valid.

This behavior is a known limitation of the tool's design. The single error message covers multiple failure modes. A blocked request, a 403 bot challenge, a timeout, a DNS failure, and an invalid URL all produce the same bare text. All of these failure modes produce the same bare text, with no explanation of why the fetch failed. You are left with a message that suggests your input was wrong when the actual problem was the target server's policy.

The Wikipedia case illustrates why this tool is not a general-purpose crawler simulator. A real Googlebot request includes a user agent, so Wikipedia would serve the page to Googlebot. This tool's anonymous request is refused. If you need to see how Wikipedia or other user-agent-filtering sites appear to crawlers, you need a tool that sends an appropriate user agent string. This tool cannot help with those sites.

The takeaway is that the "Input Site is not valid!" message is a catch-all error indicator, not a precise diagnostic. When you see it, the problem could be on your end or on the target server's end. Try the URL in a regular browser first to confirm the site is up, then consider whether the site blocks anonymous requests.

The Lowercase Replacement Quirk Explained

The tool performs a text transformation before parsing that has visible side effects. It lowercases the words Title, Description, Keywords, Content, Meta, and Name everywhere in the fetched HTML. This is a vendor workaround for uppercase tag names, which some content management systems produce. The replacement happens across the entire HTML document, not just within tags.

The side effect is that those words appear lowercased inside the displayed title and heading text. A page titled "Product Description Page" would show as "Product description Page" in the Meta Content table. The word Description gets lowercased even though it's part of the title text, not part of a tag name.

The Readable Text Content box is built from the HTML before this replacement, so it is unaffected. The text dump preserves the original capitalization. This means the readable text and the meta table can show different capitalization for the same words. The text dump shows "Product Description Page" while the meta table shows "Product description Page".

This quirk matters for two reasons. First, if you're checking whether your title tag uses correct capitalization, you should look at the source code or the readable text, not the meta table. Second, if you see unexpected lowercase letters in the meta table or heading tables, you should understand that the tool caused it, not your CMS or your content.

The quirk is a trade-off. The vendor needed to handle uppercase tag names, and the lowercase replacement solved that problem at the cost of altering displayed text. The tool's authors chose this approach over a more precise parser that would only normalize tag names. The result is a minor display artifact that you can work around by checking the source code when capitalization matters.

Frequently Asked Questions

Does this tool actually simulate Googlebot?

No. The tool sends a plain HTTP request with no user agent header at all. It does not identify itself as Googlebot, does not use Google's IP ranges, and does not render JavaScript. Googlebot has used an evergreen Chromium rendering engine since the year two thousand nineteen, while this tool executes nothing. The name describes a server-side text view, not a faithful Googlebot reproduction.

Why did Wikipedia show "Input Site is not valid!"?

Wikipedia's servers refuse HTTP requests that do not include a user agent header. This tool sends no user agent, so Wikipedia returned an empty response, and the tool treated that empty body as a failed fetch. The bare "Input Site is not valid!" message is the tool's catch-all error for blocked requests, timeouts, DNS failures, and other fetch problems.

Why do words run together in the readable text box?

The tool removes all HTML tags and collapses whitespace, but it does not insert a space where two block elements meet. When one element's text ends and another begins, the words are concatenated without a separator. The example.com dump showed "Example DomainExample Domain" because the title and H1 text were joined directly.

Does the tool check robots.txt or meta robots tags?

No. The tool sends a single HTTP request with no robots.txt lookup and no meta robots parsing. It will fetch a page even if your robots.txt disallows crawling, as long as the server accepts a user-agent-less request. For robots.txt compliance checking, use Google Search Console or a tool that respects robots directives.

Why are some links missing from the Indexable Links table?

The table lists internal links only, so external links to other domains are skipped entirely. Internal links with a nofollow attribute produce a numbered row with an empty cell, hiding the URL. Anchor text is never displayed. The table shows destinations for non-nofollow internal links and nothing else.

What does the "No Title" or "No Description" message mean?

The tool reads only the title tag and the meta name="description" and meta name="keywords" tags. If those tags are absent from the HTML, the corresponding row shows the "No" message. Open Graph tags, Twitter card tags, and other meta tags are ignored. The message means the specific classic tag is missing from the server response.