Google Search Pagination Is Not results.length

Reserp, a search API provider, clarified that Google Search pagination is based on organic-result offsets, not the number of visible result blocks returned. The company's API separates the 'start' parameter, which controls Google's organic offset, from the 'results' array, which contains visible blocks, and returns a 'nextStart' value for pagination. Reserp's documentation demonstrates a client pattern that keeps these concepts distinct, avoiding common mistakes like using 'results.length' as the next page offset.

Disclosure: I work on Reserp. This article explains the public API contract and keeps application policy explicit. Suppose a search API returns 17 URLs on its first response. What should the next page offset be? With Google Search, the answer is not 17. A visible search page can contain organic listings, news blocks, sitelinks, carousels, discussion replies, videos, and nested results. An API that preserves those visible blocks may return many URLs without changing Google's organic-result pagination rule. Reserp https://reserp.ai/ makes that distinction explicit. Its start parameter is Google's organic-result offset, while the results array represents visible result blocks. This tutorial shows a direct client pattern that keeps those two concepts separate. Reserp accepts a complete Google Search URL in one JSON field: curl -X POST https://api.reserp.ai/v1/serp \ -H "Authorization: Bearer $RESERP API KEY" \ -H "Content-Type: application/json" \ -d '{"url":"https://www.google.com/search?q=photonic+computing&gl=us&hl=en"}' The URL can use normal Google parameters such as: | Parameter | Meaning | Example | |---|---|---| q | search query | photonic computing | gl | country | us | hl | language | en | start | organic-result offset | 10 | tbs | time or result filter | qdr:w | tbm | search type | nws | The Google num parameter is unsupported and should not be sent. A successful response contains pagination independent of results.length : { "pagination": { "start": 0, "nextStart": 10, "nextUrl": "https://www.google.com/search?q=photonic+computing&gl=us&hl=en&start=10" } } The rules are simple: start or use 0 for the first page; 10 for the second page; 20 for the third page;An invalid offset, such as start=17 , produces a non-billable 400 invalid request response. The transport function below makes exactly one request. It does not retry or fetch another page: python import json import os from urllib.request import Request, urlopen def search once google url: str - dict: request = Request "https://api.reserp.ai/v1/serp", data=json.dumps {"url": google url} .encode "utf-8" , headers={ "Authorization": f"Bearer {os.environ 'RESERP API KEY' }", "Content-Type": "application/json", }, method="POST", with urlopen request as response: return json.load response Call it for the first page: first = search once "https://www.google.com/search" "?q=photonic+computing" "&gl=us" "&hl=en" print first "pagination" If—and only if—the application decides it needs another page, pass the returned URL into another explicit invocation: second url = first "pagination" "nextUrl" second = search once second url The important part is what the code does not say: Wrong: visible block count is not Google's organic offset. next start = len first "results" It also avoids burying a loop inside search once . The calling job may have its own page limit, request budget, cancellation signal, or queue. Those are application policies, not transport behavior. Each result block may include text , url , and children , but not every block has every field. In particular, text is optional in the public contract: for block in first.get "results", : text = block.get "text" url = block.get "url" if text is not None: print text if url is not None: print url Do not flatten children unless your application has a reason to discard their URL boundaries. Reserp retains nesting precisely when flattening would lose descendant content or structure. Every error body has four public fields: { "ok": false, "error": "service unavailable", "retryable": true, "billed": false } retryable is authoritative for retry eligibility. billed reports whether billing settled; it does not decide whether an error is retryable. The one-request function above does not add a retry loop. A real application can inspect the HTTP error body and let its existing worker, queue, or scheduler decide what to do. That avoids a hidden retry colliding with a higher-level retry and turning one logical job into duplicate API calls. Keep the three layers separate: Google organic offset: start = 0, 10, 20, ... Visible page content: results = heterogeneous blocks Application policy: whether and when to request another page Once those layers are separate, pagination is predictable. Follow pagination.nextUrl , never infer an offset from the number of returned blocks, and keep each API invocation explicit. The complete contract, including supported Google parameters and stable error codes, is available in the Reserp API documentation https://reserp.ai/docs and OpenAPI JSON https://reserp.ai/openapi.json .