I Reverse-Engineered Google’s New Redirect Mechanism → /goto?url=

I like digging into things, and my experience researching Google tells me this is something structural. I can’t walk past something like this without checking it out, so here’s what I found.

Here’s a walkthrough of what it looks like to reverse-engineer an unknown binary format from scratch, plus an honest answer to the question: „how much of this actually matters to someone working in SEO.” Spoiler: less than I thought 😀 but what I found along the way, I think, is still worth writing up.

Ahrefs first picked up „goto” back on December 5, 2025

Ahrefs shows the first mentions of „/goto?url=” as early as December 5, 2025. Looking at the chart below, I have doubts about whether „limited” is really the right word for this rollout.

It’s also worth noting the range of entities whose content Google has funneled through „goto.” Everything from Pinterest and YouTube, to the Italian news outlet Tgcom24, to the Denver Broncos (a page about the American football team), to a betting site.

Starting point: two layers of redirects stacked on top of each other

I started by collecting samples. As of the publication date, Google’s site: operator showed 380 unique links, 4 of which led to the same pages.

The first thing that caught my eye: the new mechanism didn’t replace the old one. The full link looks like this:

https://www.google.com/url?sa=t&source=web&...&url=https://www.google.com/goto%3Furl%3D<TOKEN>&ved=<VED>&usg=<USG>

The new /goto?url= token is nested inside the old /url? mechanism. Google is adding a new layer without replacing the old one (for now?). That’s a fairly typical pattern for a cautious rollout – if something goes wrong, you can roll it back without rebuilding the entire redirect infrastructure. I noted this down as the first concrete fact and turned my attention to the token itself.

The token itself looked like this:

CAESdAE7q4ylCqz3hVmL8SHjZ68DuX1yk6TB5-xaiSDrayUfemhRYI6oGZqvLTbcdjZJgb_bKVrFRLKzcZhj_6k8eZJ8B3HoVE4a0ZvaOqs_hgH3wx88TYEJumNjsqnOVWiEsOhgoMiohetnWt2aPdpk4iz4HSNQ

Discovery 1: this is Protocol Buffers (protobuf)

I decoded the base64 into raw bytes and started reading it according to the Protocol Buffers spec – the binary data serialization format Google uses internally practically everywhere. The first few bytes of a sample token:

08 01 12 9C 01 [...]

I broke this down manually:

• 08 is a tag meaning „field number 1, varint type”
• 01 is the value of that field – the number 1
• 12 is the tag for „field number 2, variable-length data”
• 9C 01 is the length of that data, encoded as a varint – once decoded, it comes out to 156

Based on my samples, every token consists of exactly two fields:

1. The first field – always the value true, with no exceptions across the entire sample
2. The second field – a variable-length data block. Ranging from 54 to 299 bytes in my dataset

Discovery 2: Tink

I looked at the first byte of the second field’s content across all 380 samples. Always 0x01. Zero exceptions, zero variation.

A constant byte on its own doesn’t tell you much. But combined with the next 4 bytes, it looks exactly like the standard output header of Tink – Google’s open-source cryptography framework, used internally for authenticated encryption (AEAD, for short). Tink’s key-identified format looks like this:

• one marker byte
• four bytes of key identifier
• then the encrypted data

I don’t have confirmation that this is actually Tink, but I do have a binary format that matches this library’s known, publicly documented specification. On top of that, Tink is Google’s go-to library for exactly this kind of task internally. So I’d call this a high probability rather than a confirmed fact. I counted how many distinct four-byte key identifiers show up across the 380 samples:

• ee47aa4d – 235 occurrences (61.8%)
• 3bab8ca5 – 92 occurrences (24.2%)
• 5826ba61 – 48 occurrences (12.6%)
• 4a8bf25e – 5 occurrences (1.3%)

For truly random four-byte data, this kind of concentration around just four values in a sample of 380 would be inexplicable. That’s why I believe these are identifiers for encryption keys used on rotation – one dominant key (probably the current „primary” one), with the rest likely being older keys that haven’t been retired yet, or assigned to other infrastructure variants. I haven’t pinned down exactly which scenario it is – that would require systematically collecting samples over a longer period, which I didn’t do.

Discovery 3: the same link always produces an identical token

This is the moment I started suspecting I’d stumbled onto something more concrete than „some kind of encryption.”

I had 380 samples in my dataset, and among them, four pairs of identical strings in the second field – byte-for-byte the same. I checked the context of each pair by decoding the accompanying ved parameter in parallel (more on that in a moment – though it’s really a topic for its own article), and it turned out each pair came from different instances of the same link – different timestamps (on the order of tens of seconds apart), different position on the page, different pagination depth – and yet the token was identical down to the byte.

This matters because standard authenticated encryption relies on a random element for each operation – encrypting the same plaintext twice in a row will normally produce a different result each time. That’s not happening here. This points to the use of a deterministic (non-randomized) variant of authenticated encryption. As it happens, Tink offers exactly this kind of mechanism, designed specifically for cases where the same input value must always produce the same encrypted output. One use case: caching a generated token instead of re-encrypting it on every render of the results page. That, of course, is a conclusion drawn from observation.

Discovery 4: modifying the token doesn’t work

I took a working token and changed a single character to see what would happen. What happened was exactly what I suspected – an error 🙂

Google’s server responded with HTTP 400, a bad request error. That’s it, and it’s a good sign, because any modification to the ciphertext is detected during decryption attempts, before the server ever tries to interpret the content. In practice, this means you can’t independently construct a working token pointing to any URL of your choosing – not without knowing the secret key, which only Google has. If you could forge your own token, that would make for one beautiful cloaking technique ❤️

The mistake that almost derailed the whole analysis 🙂

I want to write about this because I think owning up to mistakes in this kind of analysis matters just as much as the discoveries themselves. Specifically, I wanted to check whether the length of the encrypted token had any relationship to the length of the actual URL it pointed to.

I collected 20 pairs: token + the URL it led to. I calculated the statistical correlation between token length and text length, and got ZERO. Literally – a correlation coefficient close to 0, even slightly negative. I also tried comparing against a version of the text run through standard compression, hoping maybe Google compresses the URL before encrypting it. No luck there either 🙂

  cipher_len vs plain_len (raw URL):           r = -0.0843
  cipher_len vs gzip(url).length:              r = -0.1275
  cipher_len vs deflate(url).length:           r = -0.1275

Based on this, I drew a conclusion: maybe the token doesn’t contain an encrypted URL at all, but rather some internal identifier pointing to a record in a Google database, with the actual redirect happening via a server-side lookup. That sounded reasonable, but it turned out my input data was flawed. I threw out the entire set of 20 pairs that this earlier conclusion was based on and started the analysis over from scratch 😀 Double-check everything, always!

Data verified with direct requests

I took the token by itself and sent a direct curl request to https://www.google.com/goto?url=<token> with automatic redirect-following disabled, then read the Location header from the response. The token and the actual URL came from the exact same request.

This way, I collected 16 fully reliable token→real-URL pairs. For each one, I calculated the difference in bytes between the length of the encrypted token and the length of the actual URL.

Discovery 5: two clean clusters

For the dominant key (ee47aa4d), the difference between token length and actual URL length in my sample landed on exactly 2 values: 35 bytes or 56 bytes. No values in between. The gap between clusters: exactly 21 bytes.

• The 35-byte-overhead cluster included short URLs, plus one of the longest in the entire sample;
• The 56-byte-overhead cluster – something other than plain link length decides which variant a given token falls into. Honestly, I don’t know what. I checked page type, protocol, domain length, and none of them produced a clean split across the 16 samples I tested

For the second confirmed key (5826ba61), I only had two samples, and they produced identical overhead – 60 bytes – despite different URL lengths.

The most likely explanation for having 2 clusters within a single key: what’s being encrypted is some small structure containing the URL plus an additional, optional field of about 21 bytes, present in some cases but not all. What that field actually is – I don’t know. So this is a hypothesis, not a confirmed fact.

Discovery 6: a one-byte difference that confirmed something important

Among the 16 samples, one broke from the pattern described above – a Facebook link, with a URL length of 135 characters, produced an overhead of 36 bytes instead of the 35 expected for its cluster.

In Protobuf, a text field has its length prepended as a varint – and this format encodes values up to 127 in a single byte, needing two bytes for anything from 128 upward. The Facebook URL crosses that threshold, and the observed overhead increased by exactly one byte.

I conclude that this is a direct consequence of how field length is encoded in Protobuf. Whatever is being encrypted is itself structured as a Protocol Buffers message, in which the URL is one of the text fields, rather than a raw, unstructured string. If it were otherwise, crossing this specific threshold (128) would have no reason to affect the result’s length any differently than simply adding however many bytes the URL grew by.

What the ved parameter does in parallel, and why that’s good news

Separately from this whole investigation, every Google search result has long carried a ved parameter too. I decoded it and confirmed that, among other things, it contains a precise timestamp down to the microsecond. The value matched the exact date and time I was collecting samples. ved also encodes the link type, result position, and pagination page.

NOTE! ved hasn’t changed and isn’t part of this experiment. The new, encrypted /goto token is responsible for securely redirecting to the destination URL. All the rest of the telemetry – position, timestamp, result type – remains plaintext and decodable, same as before.

This separation makes sense, because Google isn’t rebuilding its entire click-tracking infrastructure – it’s just adding another layer to the URL.

What I’m confident about

I’m putting this together in one list so it’s clear what’s a hard fact versus just an impression:

1. Google is testing a /goto?url= redirect mechanism on a limited group of users
2. The token is a valid Protocol Buffers (Protobuf) structure with 2 fields – a constant boolean flag and a variable-length data block. That block’s format matches the output of the Tink cryptography library, with 4 key identifiers used on rotation
3. The encryption is completely deterministic – the same target always produces an identical token, regardless of the display context
4. The token is tamper-protected – changing a single character produces an error instead of a broken redirect
5. Token length relative to actual URL length falls into discrete clusters, differing by fixed values, with an additional, mathematically justified jump once the URL crosses 128 characters
6. The ved parameter remains unchanged and is independent of this mechanism

What I’m not confident about

1. I don’t know for certain whether this really is the Tink library, or just something with an identical header format.
2. What exact encryption algorithm is behind the observed lack of randomness
3. What specifically distinguishes links that fall into the 35-byte overhead cluster from those falling into the 56-byte cluster – I checked several obvious hypotheses and none held up across my small sample
4. Whether the 4 identified keys rotate over time, or operate in parallel across different infrastructure segments.
5. Whether this mechanism extends beyond plain organic results – my entire sample consisted exclusively of that result type. I don’t know whether, or when (if ever), this will reach full rollout

What does this mean for someone doing SEO day-to-day?

I want to be honest here, because it would be easy at this point to tack on a section titled „5 things you need to do today” just to make this piece look more actionable than it actually is 😀

The one concrete, practical piece of advice I can honestly give is this: if you’re managing paid campaigns, it’s worth keeping an eye on whether this mechanism starts showing up in your ad links. Ahrefs data shows a parallel increase in paid traffic for /goto, up to 5.5 million.

I think this signal is concrete enough that it’s no longer worth just waiting around for confirmation – it’s time to start checking this actively.

So why write this analysis at all

Not many practical takeaways, but I wrote it because:

1. If the „goto” mechanism ever does reach a wider rollout, there will be a wave of hastily written articles about it. I’d rather there already be a piece out there that actually broke this down properly before that happens
2. I think this is interesting in its own right, regardless of how (un)useful it turns out to be. Reverse-engineering an unknown format, catching my own methodological mistakes along the way, and finally landing on something as concrete as a mathematical threshold at 128 bytes – that’s reason enough for me to write it up, even if nobody else finds any practical value in it
3. The topic caught my interest, and hey, maybe I’d stumble onto something along the way 🙂

Speaking of digging into things and making discoveries, I’d recommend checking out my other articles, which involve in-depth research and offer practical takeaways for SEO specialists

• unicornClicks – the children’s click signal – Documentation analysis and mobile app decompilation
• Google indexed over half a million URLs with the /gtm_latency=1 parameter, and it shouldn’t have!
• The multidimensional role of clicks in evaluation and ranking – an in-depth analysis of user interaction signals in Google
• AI crawlers ignore LLMS.txt but keep crawling the web at full force

Google vs. Scrapers: A Timeline of Google’s Anti-Scraping Policy

What follows is my own interpretation of events, not a confirmed fact. I compiled a chronological list of publicly available information about Google’s actions targeting scraping, and concluded that /goto?url= isn’t an isolated case, but another piece in a longer chain.

Google has never officially announced any „anti-scraping campaign.” I’m the one connecting these dots by looking at the timeline. Judge for yourself whether you see the same pattern I do.

Chronological table

1. Google added disallow to robots.txt file after 19/07/2026 – old robots.txt file without this change on WebArchive.org ↩︎
2. TechCrunch article mentioning Google [source] ↩︎
3. The system began triggering so-called „JavaScript challenges” for queries originating from unrecognized sources [source] ↩︎
4. Google’s lawsuit against SerpApi [source] ↩︎