Does Google really ignore POST requests during JavaScript rendering?

Why does Google differentiate between GET and POST in its caching mechanism?

The behavior of Googlebot during JavaScript rendering is based on a logic of performance and consistency. GET requests, by nature idempotent, can be replayed without risk: retrieving the same resource twice produces the same result. Thus, Google can cache these responses and reuse them during successive renders, saving processing time and server resources.

POST requests, on the other hand, are designed to change a server-side state — submitting a form, creating a resource, triggering an action. Caching them would be a technical aberration: each POST should theoretically produce a unique result. Google cannot assume that a POST response will be identical during a second render.

What is the real difference between the initial render and subsequent renders?

During the first render of a page, Googlebot executes JavaScript and performs all requests — both GET and POST. The browser receives the responses, the DOM is constructed, and the content is displayed. If a critical part of the page (text blocks, products, reviews) is loaded via POST, it will be visible during this initial render.

However, during a later render — for example, if Google re-evaluates the page a few days later — POST requests will not be replayed. Google will reuse cached GET resources, but the content loaded via POST will be absent. The result: two different versions of the same URL in the index, with a risk of inconsistency between the indexed content and the actual content.

What impact does this have on indexing and the performance perceived by Googlebot?

If your architecture relies on POST calls to load critical content, you create a dependency on the freshness of the render. Googlebot might index an incomplete state of the page if the last render did not replay the POSTs. Worse still: rendering performance can vary depending on whether POSTs are executed or not, skewing the evaluation of Core Web Vitals and response times.

Specifically, an e-commerce site that loads prices or inventory via POST risks having Googlebot index product pages without prices. A blog that loads comments or related articles via POST may end up with pages considered lacking in content during subsequent renders.

• GET requests are cached by Googlebot during JavaScript rendering, ensuring consistency between successive renders.
• POST requests are never cached, which can create indexing discrepancies if critical content relies on them.
• An initial render may display complete content via POST, but subsequent renders will ignore this data.
• The impact on rendering performance varies based on the presence or absence of cached POST responses.
• SPA or headless sites that abuse POST to retrieve content expose themselves to partial or inconsistent indexing.

Is this statement consistent with field observations?

Yes, and it clarifies a commonly misunderstood point. Many SEOs believe that all HTTP requests made during rendering will be systematically replayed. This is false. Google optimizes its process by reusing what it can — namely GET requests. POST requests, however, are treated as one-time actions.

In practice, we indeed observe cases where JavaScript-rendered pages display variable content depending on the timing of the render. A site that loads its FAQs via POST may see Google index sometimes the complete version, sometimes a version without answers. [To be verified]: Google rarely communicates about the frequency of JavaScript re-execution for a given URL, making it difficult to predict when a POST will be replayed or not.

What nuances should be applied to this rule?

The cache of Googlebot is not eternal. GET resources remain cached for a limited duration — likely tied to Cache-Control headers and the crawl frequency of the URL. If a GET resource expires, it will be replayed. But for POSTs, there is no caching mechanism: every initial render executes them, and each subsequent render ignores them.

Another nuance: this rule applies to JavaScript rendering, not static HTML crawling. If your page serves complete HTML server-side and then JavaScript subsequently adds content via POST, the static content will always be indexed. The issue only concerns sites that rely on JavaScript to display critical content.

In what cases does this rule become a real problem?

Let’s be honest: most well-designed sites do not use POST to load indexable content. Modern REST APIs favor GET for data retrieval. However, certain frameworks or legacy architectures, especially headless CMS or poorly configured React/Vue applications, may send POSTs by default.

The real risk concerns sites that load critical SEO elements via POST: titles, descriptions, body text, structured data. If these elements are only visible during the first render, Google may index a stripped-down version of the page during subsequent renders. And that’s where it gets problematic: indexing inconsistency harms rankings.

What concrete steps should be taken to avoid this trap?

The first step: audit the network calls made during the rendering of your critical pages. Open the developer console, load a page, and filter requests by POST method. If you see POSTs loading indexable content — text blocks, products, articles — it’s an immediate red flag.

The second step: migrate these calls to GET. If your API or framework is sending POSTs by default, reconfigure them to use GET when retrieving data. It’s a good HTTP practice anyway: GET for reading, POST for writing. Most modern frameworks allow specifying the HTTP method in the API call configuration.

What errors should be avoided during migration?

Don't just replace POST with GET without checking the Cache-Control headers. If your GET responses are marked as non-cacheable (Cache-Control: no-store), Google won't cache them either, and you'll lose the benefits of the migration. Ensure your GET responses include appropriate caching directives.

Another common mistake: sending complex payloads in the URL via GET. Technically possible, but overly long URLs can cause issues — server limits, truncation in logs, poor UX. If your POST was sending a 2kb JSON, reconsidering the API architecture is probably necessary instead of passing everything through the query string.

How can I verify that my site is compliant after the fix?

Use Google Search Console and the URL inspection tool. Request a live render, then compare the rendered version with what you see in production. If critical content appears in both cases, that’s a good sign. Otherwise, dig into the network tab to identify missing requests.

Also, test with tools like Screaming Frog in JavaScript rendering mode or Oncrawl. These tools simulate Googlebot’s behavior and can reveal inconsistencies between static HTML and rendered content. If you find discrepancies, it’s likely related to un-replayed POSTs.

• Audit all POST calls made during the JavaScript rendering of critical pages.
• Migrate to GET any calls that load indexable content (text, products, structured data).
• Ensure that GET responses include appropriate Cache-Control directives to be cacheable.
• Test rendering through Google Search Console and compare it with the production version.
• Monitor server logs for any POSTs still present after migration.
• Document API calls and their HTTP methods to prevent regressions during future updates.