Should you ditch POST for crawlable APIs and switch everything to GET?

Why can’t Google cache POST requests?

POST requests are inherently non-idempotent. In other words, sending the same POST request twice could theoretically yield two different results or trigger two separate actions on the server side.

This is why browsers and caching systems — including Googlebot — cannot store responses to POST requests in the same way they do for GET requests. A POST could create a resource, change a state, or trigger a side effect. Caching it would mean ignoring the intention of the HTTP protocol.

What does it change for crawl budget?

Crawl budget refers to the number of requests Googlebot can allocate to your site within a given time frame. Each time a bot visits a page needing JavaScript rendering, it executes the code, triggers API requests, and waits for responses.

If these APIs operate in POST, Googlebot must repeat the call on every visit, even if the content hasn’t changed. On a site with thousands of dynamic pages, this represents a significant server load and a waste of crawl budget. With GET, the response can be cached (with proper HTTP headers), which avoids unnecessary server requests and speeds up rendering.

Can GraphQL work in GET mode?

Yes, and that’s precisely what Martin Splitt recommends. GraphQL is generally used with POST because queries can be lengthy and complex, which poses a problem with the URL size limit in GET.

However, technically, nothing prevents you from passing a GraphQL query as a URL parameter via GET, as long as it stays below the roughly 2000-character limit. For common and repetitive queries needed for rendering, this is entirely feasible. The advantages are twofold: reduction in the number of requests due to the flexibility of GraphQL, and possible caching thanks to GET.

• POST cannot be cached by Googlebot, resulting in unnecessary crawl budget consumption on every visit.
• GET allows for caching via standard HTTP headers (Cache-Control, ETag, etc.).
• GraphQL in GET combines the benefits of query flexibility and caching.
• Each POST endpoint requested during rendering generates a systematic server request, even if the content is identical.
• On a site with a high volume of dynamic pages, switching from POST to GET can drastically reduce server load and free up crawl budget.

Is this statement consistent with real-world observations?

Yes, and it’s even one of Martin Splitt's clearest recommendations. It’s regularly observed that JavaScript-heavy sites with POST APIs experience slow indexing problems, especially as page volume increases.

Server logs show that Googlebot consistently re-issues POST calls during every crawl, even on stable content. Conversely, when these same endpoints are switched to GET with appropriate cache headers (max-age, ETag), there’s a significant drop in server hits and faster indexing progress. This is not surprising; it’s basic HTTP, but many modern developers overlook it.

What are the practical limits of this recommendation?

The main limitation is the URL size. GET requests pass their parameters in the URL, and most servers accept up to 2000-8000 characters depending on the configuration. For GraphQL, this can quickly become problematic if your queries are complex with many nested fields.

Another point is that sensitive data should never be transmitted via GET, because the complete URL appears in server logs, referrer headers, and browser history. If your API handles tokens, user IDs, or any data that should not be logged in plain text, POST remains the better choice — but then that content should probably not be exposed to Googlebot anyway.

[To verify] Martin Splitt does not specify whether Googlebot respects cache directives for GET during rendering. It’s assumed that it does, but no official documentation details Googlebot's exact internal cache behavior during JavaScript rendering. Field tests suggest it respects Cache-Control, but further validations across different types of content would be necessary.

In what cases does this rule not apply?

If the content returned by the API is not necessary for indexing (member areas, admin interfaces, content behind login), then it doesn’t matter whether it’s POST or GET. Googlebot will not log in or attempt to crawl those areas.

Similarly, if your site primarily operates in server-side rendering (SSR) and APIs are only called client-side for post-load interactions, it doesn’t impact crawling. The bot retrieves the already rendered HTML without needing to execute API calls. This is, in fact, one of the reasons SSR remains the most robust solution for SEO.

What should you concretely do to migrate from POST to GET?

First, identify which APIs are called during the rendering of indexable pages. Use Chrome DevTools in "Disable cache" mode and inspect the Network tab during loading. Filter by XHR/Fetch and note all POST requests that occur before the main content is visible.

Next, for each identified POST endpoint, assess whether it can be converted to GET. Most classic REST APIs (listing products, retrieving an article, loading metadata) can easily switch to GET. For GraphQL, transform your POST queries into GET with the query as a URL parameter, provided it stays under 2000 characters.

On the server side, set up the appropriate HTTP cache headers: Cache-Control with a reasonable max-age (300-3600 seconds depending on update frequency), ETag for conditional validation, and Vary if content changes based on certain headers (Accept-Language, etc.). Without these headers, even with GET, caching won’t be effective.

What mistakes to avoid during the migration?

Do not convert endpoints that modify data (creation, updating, deletion) into GET. This violates HTTP standards and can create serious security issues. GET must remain idempotent and safe.

Also, avoid caching content that changes frequently with a max-age that is too long. If you cache a product stock API for 1 hour while stock changes every 5 minutes, Googlebot (and your users) will see stale data. Adjust the cache duration based on the actual volatility of your data.

Finally, beware of too lengthy GraphQL queries. If you exceed the server's URL limit, the request will fail silently or return a 414 (URI Too Long). Systematically test your GET endpoints across various environments (dev, staging, prod) before deployment.

How to ensure that the optimization is effective?

Compare the server logs before/after migration. You should notice a decrease in hits for endpoints converted to GET, especially for repeated Googlebot visits. Also, use Search Console to monitor crawl budget evolution: if indexing speeds up or the number of crawled pages per day increases, that's a good sign.

Test with the URL Inspection tool in Search Console and compare rendering before/after. The content should appear identical, but rendering time may decrease if caching works well. You can also use tools like Screaming Frog in JavaScript rendering mode to simulate Googlebot behavior.

• Audit API calls triggered during the JavaScript rendering of indexable pages.
• Convert POST endpoints to GET for any API needed for displaying crawlable content.
• Configure Cache-Control, ETag, and Vary on the server side to enable caching.
• Test the length of GraphQL URLs in GET and ensure they remain under 2000 characters.
• Validate that GET endpoints never modify data (compliance with HTTP standards).
• Compare server logs and crawl metrics before/after migration to measure impact.