> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# Google’s new search redirects make links harder to check before you click
- URL: https://f4n6.co.uk/security-feed/googles-new-search-redirects-make-links-harder-to-check-before-you-click/
- Published: 2026-09-14T16:05:08.000Z
- Updated: 2026-09-14T16:05:08.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

Google has begun routing some search-result links through opaque `google.com/goto?url=...` redirects, where the `url` parameter uses a Google-specific encoding rather than a readable destination. Google confirmed the rollout but did not state what abuse it is intended to counter; the widely assumed motive — making bulk extraction of destination URLs more expensive — is inference, not confirmed fact. The security consequence is that the standard "hover before you click" check no longer reveals the true destination, because the final target is only observable in the `Location` header of the redirect response. For EMEA financial services this degrades a user-facing control that underpins phishing and social-engineering awareness training, and it also affects legitimate tooling (rank tracking, SEO auditing, archival, accessibility, alternate-index services) that now faces the same rate limits and costs as abusive scrapers. There is no CVE, no exploitation in the wild, no malware and no attribution associated with this item; it is a platform behaviour change with a defensive-awareness impact, and the entire item rests on a single source.

## 2\. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item. This is a vendor product change with no ICT incident, no operational disruption, no third-party contractual event and no reportable cyber threat. Mapping it to DORA Art. 17/18/19 or NIS2 Art. 23 would be compliance-checkbox padding: nothing here triggers a classification, notification or testing obligation. The only tangential relevance is that any client whose resilience testing or threat-intelligence tooling depends on scraping search-result destinations should note the change as a tooling assumption, not a regulatory event.

## 3\. Technical analysis & attack chain

This item is not an attack. There is no exploited component, no payload, no persistence and no command-and-control. What follows is the mechanism as described by the source, plus the defensive consequence.

### Confirmed mechanism

1. Google routes some links in its search results through `google.com/goto?url=...` instead of linking directly to the destination.
2. The `url` parameter does not contain a readable version of the destination; it uses a custom, Google-specific encoding.
3. The final destination is viewable only through the redirect response's `Location` header — reported by search-results data provider Autom.
4. Consequently, any bulk collector must make an additional request per result to resolve where a link actually goes, which is the mechanism by which the change raises the cost of bulk URL extraction.
5. Google confirmed the rollout to Search Engine Roundtable, stating: *"We have a long history of deploying technical measures against evolving forms of abuse, and we regularly take steps to protect our services and users."*
6. Google has **not** stated precisely what abuse the change is intended to prevent. The bulk-extraction rationale is the source's assessment of the most likely reason, not a Google statement.

**Defensive consequence:** the long-standing user guidance to hover over a link and inspect the destination before clicking is materially weakened for affected results. Hovering now reveals an encoded Google redirect rather than the destination website. Google still displays the claimed destination as text above each search result, but that text is the publisher's/Google's assertion and is no longer independently verifiable by the user via link preview. The source explicitly raises the open question of whether users should now also be told to avoid `goto?url` links, alongside existing advice not to click Sponsored results — that question is posed, not answered.

**Collateral impact:** the source reports user complaints that rank tracking, SEO auditing, research, archival, accessibility and alternate-index services will face the same rate limits and costs as abusive scrapers. This is a functional/availability concern for legitimate tooling, not a security compromise.

**Caveats and confidence:** this is a **single-sourced** item — one Malwarebytes blog post, which itself relays a Google statement made to Search Engine Roundtable and a claim from the data provider Autom. The rollout is not universal: the author notes it had not reached their region at time of writing, and the accompanying image was taken from another source. Treat the geographic scope, the completeness of the rollout, and the stated motive as unverified. No technical detail beyond the redirect path and the `Location`\-header behaviour is provided; do not assume a specific encoding scheme, parameter set, or expiry behaviour for the redirect.

## 4\. Mitigation & containment

There is nothing to contain or patch here — the change is on Google's side and is not malicious. The actions below are awareness, tooling and process controls.

### P1 — within 24h

- Update user-facing phishing/social-engineering guidance: state explicitly that hovering over a Google search result may now show an encoded `google.com/goto?url=...` link rather than the destination, and that the hover check is therefore no longer an independent verification for affected results. Keep the existing advice not to click Sponsored results.
- Brief the SOC and service desk that `google.com/goto?url=` appearing in proxy logs is expected Google behaviour, not an indicator of compromise — prevent false-positive escalation.

### P2 — within 72h

- Review any URL-preview, link-detonation or safe-click tooling used by the organisation or its mail/web gateway: confirm it follows redirects and evaluates the final `Location` target rather than the first-hop URL. Tooling that only inspects the initial URL will now report a Google-owned destination for links that actually resolve elsewhere.
- Where web proxy or DNS logging is retained, consider a low-severity alert (not a block) on outbound requests to `google.com/goto?url=` so that user click-through to search-result redirects is visible for retrospective investigation. Blocking is not recommended: this is a legitimate Google path and blocking will break normal search usage.

### P3 — within 7 days

- Audit internal or contracted tooling that scrapes Google search results (rank tracking, SEO, brand monitoring, archival, accessibility, alternate-index services) for rate-limit, cost and terms-of-service impact, and for whether it can still resolve destinations via the `Location` header.
- Re-test user-awareness material against the new behaviour; ensure the "check the displayed destination text" guidance is framed as an unverified claim rather than a verified destination.

No vendor fix or version pin applies — there is no vulnerable product in this item.

## 5\. Indicators of compromise

No indicators of compromise available in the source material. This item describes a legitimate platform behaviour change; there is no malicious artefact, hash, domain or infrastructure to publish.

The source does describe observable behaviours. These are not atomic indicators and are not suitable for the copyable block.

### Behavioural indicators

| behaviour                                                                                                              | where to observe                                                                      | confidence                                                      |
| ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| Search-result links resolving to google.com/goto?url=... with a non-readable, Google-specific encoded url parameter    | Web proxy / HTTP logs; browser address bar on click                                   | High — confirmed by Google's statement and the source           |
| Redirect response where the true destination appears only in the Location header, not in the visible URL               | HTTP response inspection; proxy logs with redirect-chain capture                      | Medium — single-sourced to data provider Autom via Malwarebytes |
| Elevated per-result request volume from search-scraping tooling (one extra request per result to resolve destinations) | Egress logs from SEO/rank-tracking/archival tooling; Google-side rate-limit responses | Medium — single-sourced; inference from the described mechanism |

## 6\. Detection

Insufficient indicators to author detection rules.

The only strings available (`google.com/goto?url=`, `Location`) are artefacts of legitimate Google infrastructure, not of a threat. A rule built on them would detect normal search traffic and generate false positives at scale. No malicious file, command line, registry key, mutex or network indicator is present in the source material.

## 7\. Sources

- Malwarebytes, "Google's new search redirects make links harder to check before you click", https://www.malwarebytes.com/blog/news/2026/09/googles-new-search-redirects-make-links-harder-to-check-before-you-click, 2026-09-14

## 8\. Adverse Trace position

We assess this as **informational, low severity** — there is no vulnerability, no exploitation, no malware and no threat actor, and no CVSS or CISA-KEV state applies. The risk is a degradation of a user-facing verification habit, not a compromise vector in itself; the practical exposure is that users who rely on hover-preview to sanity-check search results lose that check, which marginally improves the odds of a successful social-engineering click on a poisoned or malicious search result. The entire item is **single-sourced** (Malwarebytes, relaying a Google statement to Search Engine Roundtable and a claim from Autom) and the stated motive for the change is inference, not confirmed — verify the rollout's scope in your own environment before amending published user guidance. Clients should treat this as an awareness and tooling-assumption update, not an incident. We will monitor for corroborating reporting on the redirect mechanism, any confirmed encoding or resolution behaviour, and any observed abuse of `goto?url` links in phishing campaigns, and will reissue if the picture changes.

---

[Read the original source →](https://www.malwarebytes.com/blog/news/2026/09/googles-new-search-redirects-make-links-harder-to-check-before-you-click?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*