LinkBreeze selbst hosten: Alternative zu Linktree

Was LinkBreeze ist

LinkBreeze ist eine selbst gehostete Linktree-Alternative: ein Docker-Container, der eine öffentliche Link-in-Bio-Seite und ein Admin-Dashboard bereitstellt. Der gesamte Zustand liegt in einer einzigen SQLite-Datei. Das Projekt steht unter der MIT-Lizenz, ist in TypeScript auf Basis von Next.js geschrieben und wird als ghcr.io/manak-hash/linkbreeze veröffentlicht. Für den Betrieb benötigen Sie einen VPS, eine Domain mit einem auf diesen VPS zeigenden A-Record, offene Ports 80 und 443 sowie Docker Engine mit dem Compose-Plugin.

Diese Anleitung behandelt die vom Repository tatsächlich unterstützte Bereitstellung: Docker Compose hinter einem Reverse Proxy, der seine Zertifikate selbst abruft. Sie behandelt außerdem Fehlerfälle. Ein Link in einer Bio ist eine öffentliche URL, die andere Personen anklicken. Wenn der Link nicht funktioniert, verlieren Sie diesen Klick.

Machen Sie sich vor allem anderen klar, wie neu dieses Projekt ist.

Ist LinkBreeze ausgereift genug für einen öffentlichen Profil-Link?

Im August 2026 hat das Repository 178 Sterne, 17 Forks und einen einzigen Maintainer. Das erste getaggte Release, v1.0.0, ist vom 1. Juli 2026. Dieses Projekt ist erst wenige Wochen alt, nicht mehrere Jahre.

[
  {
    "week": "2026-06-29",
    "releases": 3,
    "cumulative": 3
  },
  {
    "week": "2026-07-06",
    "releases": 3,
    "cumulative": 6
  },
  {
    "week": "2026-07-13",
    "releases": 1,
    "cumulative": 7
  },
  {
    "week": "2026-07-20",
    "releases": 2,
    "cumulative": 9
  },
  {
    "week": "2026-07-27",
    "releases": 3,
    "cumulative": 12
  },
  {
    "week": "2026-08-03",
    "releases": 2,
    "cumulative": 14
  },
  {
    "week": "2026-08-10",
    "releases": 3,
    "cumulative": 17
  }
]

Seit v1.0.0 hat das Projekt 17 getaggte Releases über 7 Kalenderwochen hinweg veröffentlicht. Die letzte Woche in diesem Diagramm lief zum Zeitpunkt der Erstellung dieser Anleitung noch und enthielt bereits 3 davon.

Betrachten Sie das als zwei getrennte Fakten. Der Maintainer ist aktiv, und Fehler werden innerhalb weniger Tage behoben. Das Schema und die Standardwerte ändern sich jedoch weiterhin. Eine Instanz, die Sie bereitstellen und danach nicht mehr beachten, wird sich daher deutlich vom aktuellen Entwicklungsstand entfernen.

Die Lizenz schützt Sie vor dem schlimmsten Fall. MIT sowie ein Container-Image und eine SQLite-Datei auf Ihrem eigenen Datenträger bedeuten: Wenn die Entwicklung eingestellt wird, läuft das Vorhandene weiter. Sie schützt Sie jedoch nicht vor einer öffentlich erreichbaren Webanwendung, die keine Sicherheitsupdates mehr erhält und mit der Zeit zu einer Haftung wird. Betreiben Sie diese Anwendung daher nur, wenn Sie sie dauerhaft aktualisieren, und halten Sie die folgende Backup-Routine ab dem ersten Tag funktionsfähig.

Tag festlegen und nicht latest verwenden

Der Release-Workflow veröffentlicht pro Version genau zwei Tags: latest und die Versionsnummer ohne das führende v. Der festgelegte Tag für Release v1.2.7 ist daher ghcr.io/manak-hash/linkbreeze:1.2.7. :v1.2.7 ruft kein Image ab und Docker meldet manifest unknown, weil dieser Tag nie veröffentlicht wurde.

Legen Sie den Tag fest, weil sich latest ändert. Bei der im obigen Diagramm dargestellten Frequenz ist ein docker compose pull für latest ein nicht überprüftes Upgrade einer Seite, die Ihr Publikum verwendet. Mit einem festgelegten Tag erfolgt ein Upgrade erst, wenn Sie die Datei bearbeiten.

Noch ein Hinweis zum Image: Der Release-Workflow erstellt es ohne die Einstellung platforms:. Das veröffentlichte Image ist daher ausschließlich linux/amd64. Auf einem arm64-Host schlägt der Pull mit no matching manifest for linux/arm64/v8 in the manifest list entries fehl. Wenn Sie einen ARM-VPS statt x86 betreiben, erstellen Sie das Image stattdessen direkt auf dem Host:

git clone --branch v1.2.7 --depth 1 https://github.com/Manak-hash/LinkBreeze.git
cd LinkBreeze
docker build -t linkbreeze:1.2.7 .

Verwenden Sie anschließend linkbreeze:1.2.7 als Image-Namen in der folgenden Compose-Datei.

LinkBreeze mit automatischem TLS hinter Caddy bereitstellen

Caddy fordert Zertifikate bei Let's Encrypt selbstständig an und erneuert sie. Daher ist für TLS (Transport Layer Security) kein separater Zertifikatsschritt erforderlich. Die gesamte Bereitstellung besteht aus drei Dateien in einem Verzeichnis.

Erzeugen Sie zuerst das Secret:

mkdir -p ~/linkbreeze && cd ~/linkbreeze
printf 'SECRET_KEY=%s\n' "$(openssl rand -hex 32)" > .env
chmod 600 .env

SECRET_KEY signiert das Admin-Sitzungs-Cookie und versieht den Besucher-Hash für die Analytics mit einem Salt. Die im Repository veröffentlichte Compose-Datei verwendet standardmäßig ${SECRET_KEY:-changeme-in-production}. Wenn Sie diesen Schritt überspringen, läuft die Instanz daher mit einem Sitzungsschlüssel, der öffentlich auf GitHub angezeigt wird. Setzen Sie den Wert vor dem ersten Start. Wenn Sie ihn später ändern, werden Sie abgemeldet und das Salt für die Analytics wird zurückgesetzt.

Schreiben Sie docker-compose.yml:

services:
  linkbreeze:
    image: ghcr.io/manak-hash/linkbreeze:1.2.7
    restart: unless-stopped
    volumes:
      - linkbreeze-data:/app/data
    environment:
      - DATABASE_PATH=/app/data/linkbreeze.db
      - SECRET_KEY=${SECRET_KEY}
      - BASE_URL=https://links.example.com
    networks:
      - linkbreeze-net

  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy-data:/data
      - caddy-config:/config
    networks:
      - linkbreeze-net

networks:
  linkbreeze-net:

volumes:
  linkbreeze-data:
  caddy-data:
  caddy-config:

BASE_URL ist optional, aber sinnvoll. Damit teilen Sie der Anwendung ihre tatsächliche öffentliche Adresse mit. So kann ein eingehender Request mit einem gefälschten Host-Header nicht dazu führen, dass die Anwendung Links für die Domain einer anderen Person erzeugt.

Schreiben Sie als Nächstes Caddyfile daneben, und verwenden Sie Ihre eigene Domain:

links.example.com {
    encode zstd gzip
    reverse_proxy linkbreeze:3000
}

Caddy setzt X-Forwarded-For und X-Forwarded-Proto standardmäßig bei weitergeleiteten Requests. Die Analytics benötigen diese Header. Starten Sie die Container:

docker compose up -d
docker compose ps
docker compose logs -f caddy

docker compose ps sollte den LinkBreeze-Container mit dem Status healthy anzeigen. Das Image enthält bereits einen eigenen Healthcheck: wget --spider -q http://127.0.0.1:3000/api/health. Sie müssen daher keinen zusätzlichen Healthcheck hinzufügen. Übernehmen Sie den Healthcheck aus dem Caddy-Beispiel des Repositorys nicht. Er ruft curl auf. Das Image basiert auf node:22-alpine, das busybox wget und kein curl enthält. Der Container meldet daher unhealthy, obwohl er Seiten problemlos bereitstellt.

Öffnen Sie https://links.example.com in einem Browser. Beim ersten Aufruf wird unter /setup der Einrichtungsassistent geöffnet. Er erstellt das einzige Administratorkonto. Danach ist das Dashboard unter /dashboard und das Anmeldeformular unter /login erreichbar. Dieses Konto gilt nur für diese Instanz. Die Anwendung bietet keine Anbindung für Single Sign-on. Wenn das Dashboard dieselbe Anmeldung wie alle anderen von Ihnen gehosteten Dienste verwenden soll, benötigen Sie davor einen Forward-Auth-Proxy, beispielsweise einen selbst gehosteten Authentik.

Beachten Sie, was die Compose-Datei nicht tut: Sie veröffentlicht Port 3000 nie. Nur Caddy lauscht auf der öffentlichen Schnittstelle. Wenn die Syntax von Compose-Dateien neu für Sie ist, erläutert die Docker-Compose-Grundlagen für einen VPS die von dieser Datei vorausgesetzten Bestandteile. Wenn bereits ein anderer Proxy vorgeschaltet ist, erklärt der Vergleich von Nginx, Caddy und Traefik, welche Änderungen erforderlich sind. Das Repository enthält funktionierende Beispiele für Nginx mit Certbot, Traefik und einen Cloudflare-Tunnel.

Wo Ihre Daten liegen und was ein Backup enthalten muss

DATABASE_PATH verweist auf /app/data/linkbreeze.db. Hochgeladene Avatare und Link-Vorschaubilder werden daneben in /app/data/uploads gespeichert. Beide befinden sich im benannten Volume linkbreeze-data. Daher ist das Volume die Einheit für das Backup und nicht allein die Datenbankdatei. Stellen Sie die Datei ohne das Uploads-Verzeichnis wieder her, liefert jedes Bild auf der Seite einen 404-Fehler.

Alles andere befindet sich tatsächlich in dieser einen Datenbank: Seiten, Links, Einstellungen, Theme, E-Mail-Abonnenten und Analytics-Datensätze.

Erstellen Sie die Kopie bei gestopptem Container:

docker compose stop linkbreeze
docker compose cp linkbreeze:/app/data ./backup-$(date +%F)
docker compose start linkbreeze

Stoppen Sie den Container zuerst. Wenn ein Prozess in eine SQLite-Datenbank schreibt, kann das Kopieren eine unvollständige Transaktion erfassen. Die Kopie lässt sich dann als beschädigte Datei nicht öffnen. Die Seite ist während des Kopiervorgangs nicht verfügbar. Die Wiederherstellung erfolgt umgekehrt:

docker compose stop linkbreeze
docker compose cp ./backup-2026-08-14/. linkbreeze:/app/data
docker compose start linkbreeze
docker compose logs -f linkbreeze

Das Dashboard bietet außerdem einen JSON-Export. Dieser wird unter /api/backup als linkbreeze-backup-YYYY-MM-DD.json bereitgestellt. Er enthält das Profil, die Links, die Einstellungen und die gespeicherten Themes. Analytics-Verlauf, E-Mail-Abonnenten und hochgeladene Bilder sind nicht enthalten. Bei der Wiederherstellung werden die aktuellen Datensätze in diesen vier Tabellen gelöscht, bevor die Datensätze aus der Datei eingefügt werden. Betrachten Sie den Export als Snapshot der Konfiguration, wenn Sie den Host wechseln oder einen Bearbeitungsfehler rückgängig machen möchten. Die Kopie des Volumes ist das Backup.

Hier gelten dieselben beiden Regeln für die Speicherung wie überall sonst beim produktiven Betrieb von SQLite auf einem VPS. Speichern Sie die Datenbank auf einer lokalen Festplatte. Die Sperrmechanismen von SQLite sind auf einem Netzwerkdateisystem unzuverlässig, und eine beschädigte Seite wird dadurch möglicherweise erst sichtbar. Wenn Sie das benannte Volume durch einen Host-Bind-Mount ersetzen, führen Sie zuerst chown für das Host-Verzeichnis aus: Der Container läuft als Benutzer node ohne Root-Rechte, mit der UID 1000 in node:22-alpine. Ein von root erstelltes Verzeichnis ist für diesen Benutzer nicht beschreibbar. Die Anwendung kann die Datenbank daher nicht öffnen, und der Container wird beim Start beendet. Bind-Mounts und benannte Volumes in Compose erläutert diesen Zielkonflikt vollständig.

Die Analytics und das Einwilligungsbanner, das Sie nicht benötigen

Das ist die Funktion, die das Self-Hosting einer Seite rechtfertigt, die Sie andernorts kostenlos erhalten könnten.

Die Analytics arbeiten ohne Cookies. Für Besucher wird kein Cookie gesetzt, und auf der öffentlichen Seite wird kein Skript eines Drittanbieters geladen. Ein Besucher wird durch einen SHA-256-Hash aus der IP-Adresse, der User-Agent-Zeichenfolge und einem Salt identifiziert. Dieser Hash wird auf 16 hexadezimale Zeichen gekürzt. Das Salt selbst ist ein Hash aus dem aktuellen UTC-Datum und Ihrer SECRET_KEY. Es ändert sich daher um Mitternacht UTC, und die Hashes des Vortags können nicht mit denen des aktuellen Tages abgeglichen werden. Die ursprüngliche IP-Adresse wird niemals in der Datenbank gespeichert.

Klicks werden auf dem Server gezählt. Jeder http-Link auf der öffentlichen Seite verweist auf /go/<id> auf Ihrer eigenen Domain. Dort wird der Klick erfasst und anschließend mit einer 302-Weiterleitung auf das eigentliche Ziel geantwortet. Die Zählung funktioniert daher auch für Leser mit deaktiviertem JavaScript sowie in In-App-Browsern, die Hintergrundanfragen blockieren. Seitenaufrufe werden über /api/track erfasst.

Zwei Ausnahmen sollten Sie kennen. Eine Anfrage mit einer gültigen Admin-Sitzung wird übersprungen. Das verhindert, dass das Bearbeiten Ihrer eigenen Seite die Zahlen erhöht. Bekannte User-Agents von Crawlern werden ebenfalls übersprungen.

Zur Einwilligung: Auf dem Gerät des Lesers wird nichts gespeichert. Ein auf dem Gerät des Lesers gespeichertes Cookie ist genau der Grund, aus dem ein Cookie-Banner nach einer Einwilligung fragt. Ihre Pflichten hängen weiterhin davon ab, wo Ihre Leser leben. Prüfen Sie diese daher. Hier gibt es jedoch kein Tracking-Cookie, über das Sie informieren müssten, und keinen Drittanbieter, der die Daten erhält.

Ein Hinweis, der viele überrascht: Wenn Sie SECRET_KEY rotieren, ändert sich auch das tägliche Salt. Ab diesem Zeitpunkt wird daher jeder wiederkehrende Besucher als neuer Besucher gezählt.

Warum ist die Länderspalte in den Analytics leer?

Weil in Ihrem Stack kein Header für das Land gesetzt wird. LinkBreeze ermittelt das Land aus Proxy-Headern wie cf-ipcountry und x-vercel-ip-country. Auf einem VPS hinter Ihrem eigenen Caddy oder Nginx sind diese Header nicht vorhanden. Daher wird das Land als null gespeichert, und die Aufschlüsselung bleibt leer. Im Container ist keine GeoIP-Datenbank enthalten.

Dafür gibt es zwei Möglichkeiten. Schalten Sie Cloudflare vor die Domain. Cloudflare fügt jeder weitergeleiteten Anfrage cf-ipcountry hinzu. Oder setzen Sie einen dieser Header in Ihrem eigenen Reverse Proxy anhand einer lokalen GeoIP-Abfrage.

Das damit verbundene Problem ist schwerwiegender. Prüfen Sie es daher ebenfalls. Die Handler für Klicks und Aufrufe lesen die Client-Adresse zuerst aus X-Forwarded-For, dann aus X-Real-IP und verwenden 0.0.0.0 als Fallback, wenn keiner der beiden Header vorhanden ist. Wenn Sie Port 3000 ohne vorgeschalteten Proxy direkt im Internet veröffentlichen, wird jeder Besucher auf denselben Wert gehasht. Dadurch bleibt die Zahl der eindeutigen Besucher dauerhaft bei 1, und das Ratenlimit von 60 Ereignissen pro Minute pro IP gilt gleichzeitig für Ihre gesamte Zielgruppe. Hinter der oben genannten reverse_proxy-Direktive setzt Caddy den Header automatisch. Damit verschwinden beide Probleme.

Import aus Linktree und Inhalte, die nicht übernommen werden

Der Migrationsassistent im Dashboard akzeptiert eine öffentliche Profil-URL oder eine exportierte Datei. Er erkennt Seiten von linktr.ee, bento.me, lnk.bio, tap.link, hopp.bio, beacons.ai, solo.to, linkfly, mssg.me und LittleLink sowie generische HTML- und JSON-Exporte. Bei einer Linktree- oder Bento-URL liest er die eingebetteten __NEXT_DATA__-JSON-Daten dieser Seiten. Bei einer statischen Seite liest er die Anker-Tags aus.

Übernommen werden der Titel, die URL, die Beschreibung und das Bild jedes Links, außerdem, ob der Link auf ein Social-Media-Profil verweist, sowie Ihr Anzeigename, Ihre Biografie und Ihr Avatar. Sie wählen aus den gefundenen Links aus, welche behalten werden, bevor etwas in die Datenbank geschrieben wird.

Nicht übernommen werden der Verlauf der Analytics-Daten, das Theme und Layout, E-Mail-Abonnenten, geplante Veröffentlichungszeitpunkte und alles, was die alte Plattform hinter ihrer eigenen Anmeldung zurückhält. Planen Sie ein, das Erscheinungsbild manuell neu aufzubauen. Der alte Klickverlauf bleibt auf dem alten Dienst.

Der Importer ruft die URL von Ihrem Server und nicht von Ihrem Browser ab. Deshalb lehnt er Adressen ab, die nicht öffentlich erreichbar sind. Private/local URLs are not allowed bedeutet, dass Sie eine Adresse innerhalb Ihres eigenen Netzwerks angegeben haben. Die Ablehnung ist beabsichtigt: Ohne diese Prüfung könnte jeder Benutzer mit Dashboard-Zugriff Ihren Server verwenden, um Computer zu prüfen, die nur Ihr Server erreichen kann. Die anderen Meldungen, die Sie sehen können, sind Only http and https URLs are allowed, Request timed out und Response too large.

Das Scraping hängt vom Markup eines anderen Anbieters ab. Wenn der Assistent auf einer Seite mit eindeutig vorhandenen Links nichts findet, hat die Plattform ihr HTML geändert, seit der Parser geschrieben wurde. Fügen Sie die Links manuell hinzu, statt auf eine Korrektur zu warten. Wenn Sie tatsächlich messbare Kurzlinks und keine Profilseite benötigen, erledigt ein selbst gehosteter URL-Shortener wie Shlink diese Aufgabe und läuft problemlos auf demselben Server.

Aktualisieren eines fest angepinnten Deployments

# edit the image tag in docker-compose.yml, then
docker compose pull
docker compose up -d
docker compose logs -f linkbreeze

Schema-Migrationen werden automatisch gestartet, wenn der Container startet. Es gibt keine dokumentierte Möglichkeit, sie rückgängig zu machen. Erstellen Sie daher zuerst eine Kopie des Volumes. Ein Upgrade, das Sie nicht rückgängig machen können, ist nur dann sicher, wenn Sie den vorherigen Zustand wiederherstellen können.

Das Dashboard zeigt ein Banner an, wenn eine neuere Version verfügbar ist. Es ruft alle 24 Stunden eine kleine Versionsdatei aus dem GitHub-Repository des Projekts ab. Dabei werden keine Informationen über Ihre Instanz übertragen. Lesen Sie die Release-Hinweise, bevor Sie den Tag ändern. In dieser Projektphase kann bereits eine Minor-Version von Ihnen verwendete Standardwerte ändern.

Fehlerfälle und die dabei angezeigten Meldungen

manifest unknown beim Abruf. Das Tag wurde als :v1.2.7 geschrieben. Registry-Tags enthalten keine v. Verwenden Sie daher :1.2.7.

no matching manifest for linux/arm64/v8 in the manifest list entries. Das veröffentlichte Image ist nur für amd64 verfügbar. Erstellen Sie es auf dem ARM-Host aus dem getaggten Quellcode.

Der Container meldet unhealthy, obwohl die Seite problemlos geladen wird. Ein Healthcheck in Ihrer Compose-Datei ruft curl auf. Dieser Befehl ist im Image nicht enthalten. Entfernen Sie den Healthcheck und lassen Sie den eigenen wget-Healthcheck des Images ausführen.

Caddy liefert einen Zertifikatsfehler oder überhaupt keine Antwort. Prüfen Sie docker compose logs caddy. Häufig zeigt der A-Record noch nicht auf diesen VPS oder Port 80 ist in der Firewall geschlossen. Dadurch wird die HTTP-Challenge von ACME (automatische Zertifikatsverwaltung) blockiert, mit der Caddy nachweist, dass es die Kontrolle über die Domain besitzt.

Die Anzahl der eindeutigen Besucher bleibt bei 1. Kein Proxy setzt X-Forwarded-For. Daher wird für jeden Besucher derselbe Hash erzeugt.

Der Container wird direkt nach dem Start beendet, obwohl er gestern noch funktioniert hat. Wenn Sie von einem benannten Volume auf einen Host-Bind-Mount umgestellt haben, gehört das Datenverzeichnis root und die Anwendung läuft mit der uid 1000. Daher kann sie die Datenbankdatei nicht öffnen. Setzen Sie den Eigentümer des Host-Verzeichnisses mit sudo chown -R 1000:1000.

Tracking-Anfragen werden mit HTTP 429 beantwortet. Das Limit pro IP für /api/track und /go/<id> wurde erreicht. Besucher werden weiterhin zu ihrem Ziel weitergeleitet. Der Klick wird lediglich nicht gezählt.

FAQ

Ist LinkBreeze für einen öffentlichen Link-in-Bio-Einsatz bereit?

Das Projekt ist noch jung. Im August 2026 hatte das Repository 178 Sterne, 17 Forks und einen Maintainer. Der erste Release ist auf den 1. Juli 2026 datiert. Im Durchschnitt erscheinen mehr als zweimal pro Woche neue Releases. Dadurch werden Fehler schnell behoben, aber auch das Verhalten ändert sich schnell. Die MIT-Lizenz und die lokale SQLite-Datei sorgen dafür, dass Ihre Seite auch bei einem Entwicklungsstopp weiter funktioniert. Eine öffentliche Webanwendung ohne Sicherheitsupdates wird jedoch zum Haftungsrisiko. Behandeln Sie LinkBreeze daher als Software, die Sie regelmäßig aktualisieren, nicht als Anwendung, die Sie einmal installieren und dann unverändert betreiben.

Welchen LinkBreeze-Image-Tag sollte ich verwenden?

Verwenden Sie den Versions-Tag, zum Beispiel ghcr.io/manak-hash/linkbreeze:1.2.7, und ändern Sie ihn bewusst. Der Release-Workflow veröffentlicht nur latest und die reine Versionsnummer. Daher existiert :v1.2.7 mit dem v nicht, und Docker gibt manifest unknown zurück. Das Image wird nur für linux/amd64 erstellt. Auf einem arm64-VPS müssen Sie den Tag daher klonen und das Image lokal erstellen.

Warum bleibt die Länderaufteilung in der LinkBreeze-Analyse leer?

LinkBreeze liest das Besucherland aus Proxy-Headern wie cf-ipcountry oder x-vercel-ip-country. Eine eigene GeoIP-Datenbank enthält die Anwendung nicht. Ein VPS hinter Ihrem eigenen Caddy oder Nginx setzt keinen dieser Header. Deshalb wird das Land als null gespeichert. Schalten Sie Cloudflare vor die Domain, oder lassen Sie Ihren Reverse Proxy einen dieser Header anhand einer lokalen GeoIP-Abfrage setzen.

Was muss ich genau sichern, und wie stelle ich die Daten wieder her?

Sichern Sie das gesamte linkbreeze-data-Volume, nicht nur die Datenbankdatei. /app/data/linkbreeze.db enthält alle Links, Seiten, Einstellungen, Abonnenten und Analysezeilen. /app/data/uploads enthält die Avatar- und Vorschaubilder, auf die die Seite verweist. Stoppen Sie den Container, führen Sie docker compose cp linkbreeze:/app/data ./backup-$(date +%F) aus und starten Sie den Container anschließend wieder. Für die Wiederherstellung kopieren Sie das Verzeichnis zurück in den gestoppten Container und starten ihn. Der JSON-Export aus dem Dashboard ist eine Konfigurationsmomentaufnahme von Profil, Links, Einstellungen und Themes. Er enthält keine Analysedaten und keine Bilder.

Werden beim Import aus Linktree meine Analysedaten und mein Theme übernommen?

Nein. Der Migrationsassistent liest die Linktitel, URLs, Beschreibungen und Bilder aus Ihrem bisherigen öffentlichen Profil sowie Ihren Anzeigenamen, Ihre Biografie und Ihren Avatar. Der bisherige Analyseverlauf, das Theme, E-Mail-Abonnenten und geplante Veröffentlichungszeitpunkte werden nicht übernommen. Erstellen Sie das Erscheinungsbild nach dem Import im Theme-Editor neu. Ihr Klickverlauf bleibt auf der alten Plattform.