{"id":25204,"date":"2026-08-14T01:06:55","date_gmt":"2026-08-14T01:06:55","guid":{"rendered":"https:\/\/capskip.com\/?p=25204"},"modified":"2026-08-14T22:02:59","modified_gmt":"2026-08-14T22:02:59","slug":"error-googlekey-pageurl","status":"publish","type":"post","link":"https:\/\/capskip.com\/zh\/error-googlekey-pageurl\/","title":{"rendered":"\u5982\u4f55\u4fee\u590d\u63d0\u4ea4\u65f6\u7684 ERROR_GOOGLEKEY \u4e0e ERROR_PAGEURL"},"content":{"rendered":"

Short answer: ERROR_GOOGLEKEY<\/code> means the googlekey<\/code> value you sent was rejected, and ERROR_PAGEURL<\/code> means the pageurl<\/code> value was. Both come back from \/in.php<\/code> at submit time, so no task was created and there is no captcha ID to poll. Nine times out of ten the cause is a parameter name: reCAPTCHA wants googlekey<\/code>, Turnstile wants sitekey<\/code>, and sending the wrong one produces exactly this. Here is how to tell them apart and fix each.<\/p>\n

What the two codes actually check<\/h2>\n\n\n\n\n\n\n
Code<\/th>\nDocumented meaning<\/th>\nWhich parameter<\/th>\n<\/tr>\n<\/thead>\n
ERROR_GOOGLEKEY<\/code><\/td>\nInvalid googlekey<\/code> parameter<\/td>\nThe sitekey you read off the page<\/td>\n<\/tr>\n
ERROR_PAGEURL<\/code><\/td>\nInvalid pageurl<\/code> parameter<\/td>\nThe URL of the page the widget sits on<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

They are validation failures, not solve failures. Nothing has been attempted yet, and nothing is queued.<\/p>\n

Submit-time, not poll-time<\/h2>\n

This distinction saves a lot of debugging. The API has two stages, and each one produces its own family of errors.<\/p>\n

\n
# Stage 1: submit. These codes appear HERE.\ncurl -X POST http:\/\/127.0.0.1:8080\/in.php \\\n  -d "key=YOUR_API_KEY" -d "method=userrecaptcha" \\\n  -d "sitekey=YOUR_SITEKEY" \\\n  -d "pageurl=https:\/\/example.com\/page-with-recaptcha"\n\nERROR_GOOGLEKEY   # no ID came back, so there is nothing to poll<\/pre>\n<\/div>\n
Compare that with a healthy submit, which returns OK|2122988149<\/code> and then fails, if it fails at all, on \/res.php<\/code>. A poll-time failure means your parameters were accepted and the solve itself did not work, which is a completely different investigation. See ERROR_CAPTCHA_UNSOLVABLE<\/a> for that one, and ERROR_KEY_DOES_NOT_EXIST<\/a> if the key itself is being rejected before either check runs.<\/p>\n
Why the value gets rejected<\/h2>\n
Three causes account for nearly all of these, in this order.<\/p>\n
Cause one: googlekey against sitekey<\/h3>\n
The 2captcha-compatible API uses a different parameter name per method, and they are not interchangeable.<\/p>\n\n\n\n\n\n\n\n
Method<\/th>\nKey parameter<\/th>\nWrong name gives you<\/th>\n<\/tr>\n<\/thead>\n
userrecaptcha<\/code><\/td>\ngooglekey<\/code><\/td>\nERROR_GOOGLEKEY<\/code><\/td>\n<\/tr>\n
turnstile<\/code><\/td>\nsitekey<\/code><\/td>\nERROR_BAD_PARAMETERS<\/code><\/td>\n<\/tr>\n
geetest<\/code><\/td>\ngt<\/code> plus challenge<\/code><\/td>\nERROR_BAD_PARAMETERS<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The trap is that everybody calls the value a sitekey in conversation, and the HTML attribute is literally data-sitekey<\/code> for both reCAPTCHA and Turnstile. Only the reCAPTCHA submit parameter is named after Google. If you copied a working Turnstile call and changed method<\/code> to userrecaptcha<\/code>, this is your bug.<\/p>\n
The SDKs hide the difference entirely. solver.recaptcha(sitekey, url)<\/code> and solver.turnstile(sitekey, url)<\/code> take the same first argument and map it to the right wire name for you, which is a good reason to use one.<\/p>\n
Cause two: the key is stale, cropped or empty<\/h3>\n
Assuming the parameter name is right, the value itself is the next suspect.<\/p>\n