Abstract:
Recently, there has been a strange risk control problem in Google search. When users click on a search result entry, they may automatically enter the "Verifying your request" page. This page may need to wait for several seconds or even ten seconds to complete. After the verification is completed, it can jump to the final page. There are other users who have encountered such problems in the official Google community.
Since Google has begun to encrypt the search result address and change it to /goto/ jump page, users can only wait before Google completes the verification. Previously, because Google did not encrypt the link, clicking would jump without any waiting.
Clicking on the search results needs to be verified by the Google server first:
Judging from user feedback, the current risk control implemented by Google will take different measures based on user behavior. For example, when a user uses Chrome and is not logged in to a Google account, they frequently encounter a verification page when clicking on the search results. The verification page is the /goto/ middle page. The verification is sometimes fast but sometimes requires a long wait.
Other users reported that risk control would not be triggered when clicking on a small number of search results, but risk control began to appear when multiple search results were quickly clicked, and the verification intermediate page finally completed verification after waiting for 12 seconds. If the user uses a proxy IP, does not log in to a Google account, and uses a different brand of browser, the risk control situation encountered is also different.
The analysis shows that the verification is false, but it is actually waiting for the countdown:
Resoneo, a search technology company, tested this mechanism and found that the so-called verification intermediate page actually executes a countdown, and then releases and jumps after the countdown is over. Although the text on the page uses the word verification, the actual experience the user gets is closer to a forced wait.
The actual situation may be that Google has collected the user's access behavior through the /goto/ intermediate page, and then submitted it to the server. The server instantly returns the waiting time according to the risk control requirements and sends it to the /goto/ page. The page will automatically jump after the waiting time is over.
At present, Google has not issued an official response on this matter, so the risk control situation encountered by different users, whether the intermediate page is truly verified or the mandatory waiting time is issued, may be different. However, users who log in to a Google account or do not frequently open a large number of pages in a short period of time usually have a lower probability of encountering risk control.
There is a high probability that it is for the purpose of anti-AI and anti-reptile:
Previously, the Google search results page did not use encrypted jump intermediate pages. That is, as long as the AI agent or crawler can solve the risk control during the Google search initiation stage, the search results page can be crawled down the entire page (but it needs to go through the risk control again when turning the page).
After the /goto/ middle page was launched, Google transcoded the actual address of the search results through Base64, and Google should have added certain parameters when transcoding. Therefore, the original address cannot be restored after directly decrypting the encoding, so the data still needs to be decrypted through the Google server during final access.
Google’s approach is most likely to counter AI and anti-crawlers, making it more difficult for AI tools to crawl content directly through Google search. Of course, it also becomes troublesome to crawl search results directly through Google search. What’s even more troublesome is that this mechanism also causes various SEO data analysis websites to be unable to capture data stably, so it still causes many problems.
Comments