---
title: "Warum URLs sensible Daten preisgeben und was dagegen hilft"
url: https://uselinkpilot.com/de/blog/why-urls-leak-sensitive-information
description: "Browserverlauf, Server-Logs, CDNs und Referer-Header speichern ganze URLs, auch bei HTTPS. Wo Links durchsickern und wie URLs ein Leck schadlos überstehen."
lang: de
---
Sicherheit (https://uselinkpilot.com/de/blog/category/security)
# Warum URLs sensible Daten preisgeben und was dagegen hilft
Browserverlauf, Server-Logs, CDNs und Referer-Header speichern ganze URLs, auch bei HTTPS. Wo Links durchsickern und wie URLs ein Leck schadlos überstehen.
W. Miller (https://uselinkpilot.com/de/author/w-miller)26. Mai 2026 · Aktualisiert am 22. Oktober 2026 · Über LinkPilot (https://uselinkpilot.com/de/about)
Eine URL wirkt privat, weil nur die Personen sie haben sollten, denen Sie sie schicken. Tatsächlich gehört eine URL zu den am häufigsten protokollierten Daten im Web: Systeme, die Sie nie um Erlaubnis gefragt haben und die Sie nicht prüfen können, schreiben sie auf, kopieren sie und leiten sie weiter. Hier steht genau, wo sie durchsickert und wie Sie Links so gestalten, dass das nichts ausmacht. Aus demselben Grund legt ein Generator für Einmal-Links (https://uselinkpilot.com/de/tools/free-secret-link-generator) den Schlüssel zum Entschlüsseln in den Teil des Links nach dem #: Dieser Teil erreicht nie ein Server-Log.
## Wo URLs durchsickern
- **Browserverlauf.** Jede besuchte URL wird lokal gespeichert und kann auf andere Geräte synchronisiert werden, auch an den Sync-Dienst des Browserherstellers.
- **Zugriffslogs von HTTP-Servern.** Die meisten Server protokollieren standardmäßig den vollständigen Pfad und Query-String der Anfrage. Wer Zugriff auf die Logs hat, hat die URL.
- **Reverse Proxies und CDNs.** Cloudflare, Fastly, Ihr Load Balancer: Sie alle protokollieren die URL, jeder mit einer eigenen Aufbewahrungsrichtlinie.
- **Pipelines zur Log-Aggregation.** Zugriffslogs bleiben selten auf einem Rechner. Sie werden an zentrale Logging- und Monitoring-Dienste weitergeleitet, und mit jedem davon wächst die Zahl der Systeme, auf denen die URL liegt.
- **Referer-Header.** Wenn die Seite eine Ressource eines Drittanbieters einbindet, kann der Browser die URL der Seite im `Referer`-Header mitsenden. Analytics-Skripte, eingebettete Videos und Werbepixel erhalten sie alle.
- **Browsererweiterungen.** Erweiterungen mit der Berechtigung, den Browserverlauf zu lesen, sehen jede URL, auch Fragmente.
- **Synchronisierte Lesezeichen.** URLs in Lesezeichen werden auf alle Geräte der Person und auf die Server des Browserherstellers synchronisiert.
- **Vorschau-Bots.** Slack, Teams, iMessage, LinkedIn und E-Mail-Programme rufen URLs ab, um Linkvorschauen anzuzeigen, unbemerkt und in dem Moment, in dem die Nachricht gesendet wird.
- **Unternehmensproxys und E-Mail-Gateways.** Viele Organisationen prüfen, überschreiben und protokollieren jede URL, die ihre Netzgrenze passiert.
## Hält HTTPS die URL privat?
Nein. HTTPS verschlüsselt die URL auf dem Transportweg und sonst nichts; beide Endpunkte speichern sie weiterhin. Hier lohnt sich Genauigkeit, denn „die Verbindung ist verschlüsselt“ wird oft als „die URL ist privat“ missverstanden.
TLS verschlüsselt Pfad und Query-String auf dem Transportweg: Wer das Netz zwischen Browser und Server beobachtet, kann `/reset?token=...` nicht lesen. Was TLS _nicht_ verbirgt: den Hostnamen des Ziels (sichtbar über die DNS-Auflösung und heute bei den meisten Verbindungen über das SNI-Feld von TLS) und alles an den Endpunkten. Der Browser speichert die vollständige URL weiterhin im Verlauf, und der Server schreibt sie weiterhin in sein Zugriffslog. Verschlüsselung auf dem Transportweg schützt die Leitung, nicht die beiden Enden, und genau an den Enden sickern URLs durch.
## Ein konkretes Beispiel: das Leben einer URL
Verfolgen wir eine einzige sensible URL, etwa einen Link zum Zurücksetzen des Passworts, `https://example.com/reset?token=8f3a91...`, vom Versand bis zum Klick:
1. **Der E-Mail-Anbieter** speichert die Nachricht (samt URL) unbegrenzt, und sein Sicherheitsscanner ruft die URL bei der Zustellung möglicherweise ab.
2. **Das E-Mail-Gateway des Empfängers** schreibt die URL um, protokolliert sie und ruft sie beim Klick erneut ab.
3. **DNS** löst `example.com` auf. Der Hostname (nicht der Pfad) steht damit in den Logs des Resolvers.
4. **Der Webserver** schreibt die vollständige Anfragezeile in sein Zugriffslog. Ein Eintrag im Standardformat „combined“ von nginx oder Apache sieht so aus:
```text
203.0.113.7 - - [14/Jul/2026:09:12:45 +0000]
"GET /reset?token=8f3a91... HTTP/1.1" 200 5123 "-" "Mozilla/5.0 ..."
```
5. **Das vorgeschaltete CDN** protokolliert dieselbe URL mit eigener Aufbewahrungsdauer.
6. **Das Analytics-Skript der Seite** speichert die URL der Seite samt Query-String in einem System eines Drittanbieters, sofern es nicht ausdrücklich so konfiguriert ist, dass es ihn entfernt.
7. **Der Browser** speichert die URL im Verlauf und synchronisiert sie.
Ein Versand, sieben Kopien, verteilt auf mindestens fünf Organisationen. Dafür war kein Angreifer nötig. Das Web funktioniert hier genau so, wie es gedacht ist.
## Der Referer-Header in der Praxis
Wenn Ihre Seite zum Anzeigen eines Geheimnisses irgendeine externe Ressource einbindet (eine Schrift von einem CDN, ein Analytics-Skript, ein eingebettetes Bild), sendet der Browser die URL der Seite möglicherweise im `Referer`-Header an diesen Origin.
Moderne Browser verwenden standardmäßig `strict-origin-when-cross-origin` (MDN: Referrer-Policy (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy)). Damit wird der Referrer bei Anfragen an andere Origins auf den Origin gekürzt (`https://example.com/` statt des vollständigen Pfads). Das ist ein echter Fortschritt, aber nichts, worauf Sie sich verlassen sollten: Anfragen an denselben Origin enthalten weiterhin die vollständige URL, eine Richtlinie auf Seitenebene kann den Standard lockern, und ältere Clients und eingebettete WebViews verhalten sich unterschiedlich.
Zwei praktische Gegenmaßnahmen:
```html
```
```http
Referrer-Policy: no-referrer
```
Der Header gilt für die ganze Website, das Meta-Tag nur für die jeweilige Seite. Verwenden Sie beides, damit eine Schutzschicht die andere absichert. Noch besser: Liefern Sie sensible Seiten **ganz ohne Ressourcen von Drittanbietern** aus, dann gibt es niemanden, an den ein Referrer gehen könnte.
## Ist ein Token im Pfad, im Query-String oder im Fragment sicherer?
Nur das Fragment bleibt außerhalb der Anfrage, also bleibt auch nur das Fragment außerhalb der Server-Logs. Pfad und Query-String sind gleichwertig. Wo Sie ein Token in der URL unterbringen, entscheidet darüber, wer es sieht:
| Ort | An den Server gesendet? | In Server-Logs? | Im Referer? | Im Browserverlauf? |
| --- | --- | --- | --- | --- |
| Pfad (`/s/abc123`) | Ja | Ja | Abhängig von der Richtlinie | Ja |
| Query (`?token=abc123`) | Ja | Ja | Abhängig von der Richtlinie | Ja |
| Fragment (`#abc123`) | Nein | Nein | Nein | Ja |
Das Fragment ist tatsächlich anders: Laut RFC 3986, Abschnitt 3.5 (https://www.rfc-editor.org/rfc/rfc3986#section-3.5) wird es im Client verarbeitet und nie in die HTTP-Anfrage aufgenommen. Deshalb legen Ende-zu-Ende-verschlüsselte Paste-Tools den Schlüssel zum Entschlüsseln dort ab: Der Server erhält ihn buchstäblich nie. Unsichtbar ist es trotzdem nicht. Browserverlauf, Erweiterungen und jedes JavaScript, das auf der Seite läuft, können es lesen. Ob Pfad oder Query, macht für den Datenschutz dagegen keinen Unterschied: Beide landen in denselben Logs.
## Das Problem mit Tokens zum Zurücksetzen von Passwörtern
Sensible Tokens in URLs sind eine anerkannte Klasse von Schwachstellen. CWE-598 von MITRE („Use of GET Request Method With Sensitive Query Strings“) beschreibt genau das: Sensible Daten im Query-String landen in Logs, Verläufen und Referrern, unabhängig von der Verschlüsselung auf dem Transportweg. Deshalb verlassen sich gut gebaute Abläufe zum Zurücksetzen von Passwörtern nie allein darauf, dass die URL geheim bleibt. Sie machen das Token **einmal verwendbar**, **kurzlebig** und **an eine folgende Aktion gebunden** (das Setzen eines neuen Passworts). Ein Token, das jemand drei Wochen später aus einem Log fischt, ist dann wertlos.
Das ist die allgemeine Lehre: Meist können Sie eine URL nicht aus den Logs heraushalten, aber Sie können dafür sorgen, dass die protokollierte URL wertlos ist, wenn jemand sie liest.
## URLs so gestalten, dass ein Leck nichts ausmacht
Gehen Sie davon aus, dass jede URL, die Sie erzeugen, irgendwann an einer unbeabsichtigten Stelle auftaucht, und gestalten Sie sie so, dass das keine Rolle spielt:
- **Einmalige Nutzung.** Löschen Sie das Geheimnis nach dem ersten erfolgreichen Abruf. Eine durchgesickerte URL funktioniert dann schon nicht mehr, wenn sie in irgendeinem Verlauf auftaucht.
- **Kurzer Ablauf.** Begrenzen Sie das Zeitfenster für ein Leck. Eine URL, die fünf Minuten lang funktioniert hat, ist weit weniger wert als eine, die eine Woche lang funktioniert hat.
- **Passphrase über einen anderen Kanal.** Verlangen Sie ein Geheimnis, das nie in der URL stand. Dann reicht die URL allein nicht mehr aus, und nur sie steht in den Logs.
- **Abruf und Anzeige trennen.** Liefern Sie bei `GET` nur Metadaten aus und geben Sie den Inhalt erst bei einem ausdrücklichen `POST` frei. So können Vorschau-Bots und Scanner das Geheimnis nicht verbrauchen.
- **Keine Ressourcen von Drittanbietern auf sensiblen Seiten**, dazu `Referrer-Policy: no-referrer` und ``.
- **Schwärzen Sie geheime Routen in Ihren eigenen Logs.** In nginx bilden Sie die Anfrage-URI vor dem Protokollieren um (siehe die Referenz zu ngx_http_log_module (https://nginx.org/en/docs/http/ngx_http_log_module.html) für `log_format`):
```nginx
map $request_uri $loggable_uri {
~^/s/ "/s/[redacted]";
default $request_uri;
}
log_format redacted '$remote_addr - $remote_user [$time_local] '
'"$request_method $loggable_uri" $status';
access_log /var/log/nginx/access.log redacted;
```
Sie kontrollieren nur Ihre eigenen Logs. Die Kopien bei CDN, Proxy und Browser bleiben, und genau deshalb tragen die ersten drei Punkte dieser Liste das meiste Gewicht.
## Was das für Secret-Links bedeutet
Aus diesem Bedrohungsmodell ergibt sich, wie die Secret-Links von LinkPilot funktionieren: Wir behandeln die URL so, als würde sie zwangsläufig durchsickern, deshalb reicht die URL allein nie aus. Ein `GET` liefert nur Metadaten. Für den Inhalt ist ein ausdrückliches `POST` zum Anzeigen nötig, optional geschützt durch eine Passphrase, die im Client mit SHA-256 gehasht wird. Gelöschte, abgelaufene oder widerrufene Geheimnisse liefern HTTP 410, und der Inhalt ist unwiderruflich überschrieben. Antworten beim Anzeigen tragen `Cache-Control: no-store`, und Aufrufe protokollieren statt der IP-Adresse einen Hash der IP mit einem täglich wechselnden Salt. Eine Grenze nennen wir offen, auch auf der Seite zur Sicherheitsarchitektur (https://uselinkpilot.com/de/security-architecture): Der Schlüssel zum Entschlüsseln steht im Fragment der URL, also muss der ganze Link als Geheimnis gelten. Genau um diese Gefahr geht es in diesem Artikel. Ein kurzer Ablauf, Löschen nach dem Lesen und eine Passphrase über einen anderen Kanal begrenzen den Schaden, wenn ein Link durchsickert.
_Aktualisierung vom 29. September 2026: Dieser Absatz besagte ursprünglich, dass LinkPilot keine Ende-zu-Ende-Verschlüsselung anbietet. Inzwischen verschlüsselt LinkPilot Textinhalte samt Anhängen im Browser._
Kostenlos testen, ohne Anmeldung
### Selbstlöschende Nachricht
Senden Sie eine Notiz, die nach einmaligem Lesen verschwindet.
Tool öffnen (https://uselinkpilot.com/de/tools/burn-after-read-secret)
## Grenzen
Die Gestaltung von URLs löst nicht alles. Sie bestimmt nicht, was der Empfänger nach einem legitimen Abruf tut, sie kann keine Kopien löschen, die Dritte bereits haben, und sie rettet keine URL, die personenbezogene Daten offen enthält. Steht die E-Mail-Adresse einer Person im Query-String, holt kein Ablauf sie wieder aus den Logs heraus. Die Regel, die bleibt: Schreiben Sie nie Daten in eine URL, die Sie später löschen müssten, denn eine URL überall dort zu löschen, wohin sie kopiert wurde, ist praktisch unmöglich. Gestalten Sie URLs stattdessen so, dass sie wertlos sind, wenn sie durchsickern.
## Weiterlesen
- So funktionieren Einmal-Links für Geheimnisse: https://uselinkpilot.com/de/blog/how-one-time-secret-links-work
- Link-Scanner und Einmal-Geheimnisse: https://uselinkpilot.com/de/blog/link-scanners-and-one-time-secrets
- Passwörter sicher teilen: 5 Methoden im Vergleich: https://uselinkpilot.com/de/secure-password-sharing
## Quellen
- IETF, RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, section 3.5 Fragment (https://www.rfc-editor.org/rfc/rfc3986#section-3.5).
- MDN Web Docs, Referrer-Policy header (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy).
- nginx, Module ngx_http_log_module (https://nginx.org/en/docs/http/ngx_http_log_module.html).
## Tools zu diesem Artikel
Selbstlöschende Nachricht
Senden Sie eine Notiz, die nach einmaligem Lesen verschwindet.
https://uselinkpilot.com/de/tools/burn-after-read-secret
One-Time-Secret-Link-Generator
Teilen Sie ein Passwort oder eine Notiz über einen Link, der sich nur einmal öffnen lässt.
https://uselinkpilot.com/de/tools/free-secret-link-generator
Generator für ablaufende Links
Erstellen Sie Links, die zu einem festgelegten Zeitpunkt nicht mehr funktionieren.
https://uselinkpilot.com/de/tools/temporary-link
## Häufige Fragen
### Reicht HTTPS, um URL-Parameter privat zu halten?
### Was ist mit Fragment-Bezeichnern (#)?
### Gehört ein Token in den Pfad oder in den Query-String?
### Senden moderne Browser im Referer-Header noch die vollständige URL?
### Wie lange bleiben URLs in Server-Logs?
## LinkPilot verschickt einen Secret-Link, der nach dem Öffnen verschwunden ist.
In Ihrem Browser verschlüsselt, einmal angezeigt, dann gelöscht. Ohne Konto.
Secret-Link erstellen (https://uselinkpilot.com/de/tools/free-secret-link-generator)
## Weiterlesen
Sicherheit
### Sicheres Teilen von Links für Entwickler
Ein Praxisleitfaden für Entwicklungsteams: wann Einmal-Links passen, wie Sie sie per Skript erzeugen und wie Sie sie in Onboarding und CI einbinden.
https://uselinkpilot.com/de/blog/secure-link-sharing-for-developers
Sicherheit
### Secret-Links oder Passwortmanager?
Ein Passwortmanager speichert Zugangsdaten fürs Team; ein Einmal-Link übergibt sie einmal an eine Person. Die meisten Teams brauchen beides.
https://uselinkpilot.com/de/blog/secret-links-vs-password-managers
Sicherheit
### Link-Scanner und Einmal-Geheimnisse
Ein Einmal-Link, der bei einfachem GET gelöscht wird, stirbt bei der Vorschau in Slack oder im Gateway. Auf GET nur Metadaten, löschen erst beim Anzeigen.
https://uselinkpilot.com/de/blog/link-scanners-and-one-time-secrets
## Structured data
```json
[
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Startseite",
"item": "https://uselinkpilot.com/de"
},
{
"@type": "ListItem",
"position": 2,
"name": "Blog",
"item": "https://uselinkpilot.com/de/blog"
},
{
"@type": "ListItem",
"position": 3,
"name": "Warum URLs sensible Daten preisgeben und was dagegen hilft",
"item": "https://uselinkpilot.com/de/blog/why-urls-leak-sensitive-information"
}
]
},
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"@id": "https://uselinkpilot.com/de/blog/why-urls-leak-sensitive-information#article",
"headline": "Warum URLs sensible Daten preisgeben und was dagegen hilft",
"description": "Browserverlauf, Server-Logs, CDNs und Referer-Header speichern ganze URLs, auch bei HTTPS. Wo Links durchsickern und wie URLs ein Leck schadlos überstehen.",
"inLanguage": "de",
"datePublished": "2026-05-26",
"dateModified": "2026-10-22",
"image": "https://uselinkpilot.com/logo-512.png",
"author": {
"@type": "Person",
"@id": "https://uselinkpilot.com/author/w-miller#person",
"name": "W. Miller",
"url": "https://uselinkpilot.com/de/author/w-miller",
"worksFor": {
"@type": "Organization",
"name": "LinkPilot",
"url": "https://uselinkpilot.com"
}
},
"publisher": {
"@type": "Organization",
"name": "LinkPilot",
"url": "https://uselinkpilot.com",
"logo": {
"@type": "ImageObject",
"url": "https://uselinkpilot.com/logo-512.png",
"width": 512,
"height": 512
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://uselinkpilot.com/de/blog/why-urls-leak-sensitive-information"
}
},
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Reicht HTTPS, um URL-Parameter privat zu halten?",
"acceptedAnswer": {
"@type": "Answer",
"text": "HTTPS verschlüsselt die URL auf dem Transportweg. Trotzdem landet die URL im Browserverlauf und in den Zugriffslogs des Servers und wird über den Referer-Header weitergegeben, wenn die Seite nach außen verlinkt. Verschlüsselung auf dem Transportweg macht eine URL nicht geheim."
}
},
{
"@type": "Question",
"name": "Was ist mit Fragment-Bezeichnern (#)?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Fragmente werden nicht an den Server gesendet. Deshalb legen manche Ende-zu-Ende-verschlüsselte Tools den Schlüssel in das Fragment. Browsererweiterungen und jedes JavaScript auf der Seite können sie trotzdem sehen."
}
},
{
"@type": "Question",
"name": "Gehört ein Token in den Pfad oder in den Query-String?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Keine der beiden Stellen ist nennenswert privater. Beide landen in denselben Logs und Statistiken. Wenn das Token in der URL stehen muss, behandeln Sie die ganze URL als Geheimnis und sorgen Sie dafür, dass sie nur einmal funktioniert."
}
},
{
"@type": "Question",
"name": "Senden moderne Browser im Referer-Header noch die vollständige URL?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Bei Anfragen an andere Origins verwenden moderne Browser standardmäßig strict-origin-when-cross-origin und kürzen den Referrer auf den Origin. Anfragen an denselben Origin enthalten aber weiterhin die vollständige URL, eine Seite kann die Richtlinie lockern, und eingebettete WebViews verhalten sich unterschiedlich. Setzen Sie auf sensiblen Seiten deshalb ausdrücklich Referrer-Policy: no-referrer, statt sich auf die Standardwerte zu verlassen."
}
},
{
"@type": "Question",
"name": "Wie lange bleiben URLs in Server-Logs?",
"acceptedAnswer": {
"@type": "Answer",
"text": "So lange, wie es die Aufbewahrungsrichtlinie vorsieht, oft Wochen bis Monate. Zugriffslogs werden außerdem routinemäßig an Dienste zur Log-Aggregation weitergeleitet. Kopien liegen also auch auf Systemen, die der Betreiber der Website nicht selbst betreibt. Gehen Sie davon aus, dass jede URL, die einen Server erreicht hat, an mehreren Orten gespeichert ist, die Sie nicht vollständig aufzählen können."
}
}
],
"inLanguage": "de"
},
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"@id": "https://uselinkpilot.com/#software",
"name": "LinkPilot",
"applicationCategory": "BusinessApplication",
"operatingSystem": "Web",
"description": "LinkPilot is a secure link management platform for creating branded short links, tracking engagement, and sharing secrets with expiring, protected, self-destructing links.",
"url": "https://uselinkpilot.com",
"offers": [
{
"@type": "Offer",
"name": "Free",
"price": "0",
"priceCurrency": "USD",
"url": "https://uselinkpilot.com/pricing"
},
{
"@type": "Offer",
"name": "Pro",
"price": "29",
"priceCurrency": "USD",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"price": "29",
"priceCurrency": "USD",
"billingDuration": "P1M"
},
"url": "https://uselinkpilot.com/pricing"
},
{
"@type": "Offer",
"name": "Agency",
"price": "299",
"priceCurrency": "USD",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"price": "299",
"priceCurrency": "USD",
"billingDuration": "P1M"
},
"url": "https://uselinkpilot.com/pricing"
},
{
"@type": "Offer",
"name": "Agency Plus",
"price": "799",
"priceCurrency": "USD",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"price": "799",
"priceCurrency": "USD",
"billingDuration": "P1M"
},
"url": "https://uselinkpilot.com/pricing"
},
{
"@type": "Offer",
"name": "Pro (yearly)",
"price": "288",
"priceCurrency": "USD",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"price": "288",
"priceCurrency": "USD",
"billingDuration": "P1Y"
},
"url": "https://uselinkpilot.com/pricing"
},
{
"@type": "Offer",
"name": "Agency (yearly)",
"price": "2988",
"priceCurrency": "USD",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"price": "2988",
"priceCurrency": "USD",
"billingDuration": "P1Y"
},
"url": "https://uselinkpilot.com/pricing"
},
{
"@type": "Offer",
"name": "Agency Plus (yearly)",
"price": "7980",
"priceCurrency": "USD",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"price": "7980",
"priceCurrency": "USD",
"billingDuration": "P1Y"
},
"url": "https://uselinkpilot.com/pricing"
},
{
"@type": "Offer",
"name": "Enterprise",
"priceSpecification": {
"@type": "PriceSpecification",
"priceCurrency": "USD"
},
"url": "https://uselinkpilot.com/pricing"
}
]
},
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://uselinkpilot.com/#organization",
"name": "LinkPilot",
"alternateName": "LinkPilot by TetraCore",
"url": "https://uselinkpilot.com",
"contactPoint": {
"@type": "ContactPoint",
"contactType": "customer support",
"email": "support@uselinkpilot.com",
"url": "https://uselinkpilot.com/support"
},
"parentOrganization": {
"@type": "Organization",
"@id": "https://tetracorehq.com/#organization",
"name": "TetraCore",
"url": "https://tetracorehq.com/"
},
"logo": {
"@type": "ImageObject",
"url": "https://uselinkpilot.com/logo-512.png",
"width": 512,
"height": 512
},
"description": "LinkPilot is a secure link management platform for creating branded short links, tracking engagement, and sharing secrets with expiring, protected, self-destructing links.",
"sameAs": [
"https://x.com/uselinkpilot",
"https://www.linkedin.com/company/uselinkpilot",
"https://facebook.com/uselinkpilot",
"https://github.com/TetraCoreHQ/linkpilot-cli",
"https://github.com/TetraCoreHQ/linkpilot-mcp",
"https://www.npmjs.com/package/linkpilot",
"https://www.npmjs.com/package/@uselinkpilot/sdk",
"https://www.npmjs.com/package/@uselinkpilot/mcp",
"https://chromewebstore.google.com/detail/linkpilot-short-links-and/mnmppadihpcncicldpkmgknhnjkondad",
"https://addons.mozilla.org/en-US/firefox/addon/uselinkpilot/"
]
},
{
"@context": "https://schema.org",
"@type": "WebSite",
"name": "LinkPilot",
"url": "https://uselinkpilot.com",
"potentialAction": {
"@type": "SearchAction",
"target": "https://uselinkpilot.com/blog?q={search_term_string}",
"query-input": "required name=search_term_string"
}
}
]
```