Eigene Domain verbinden

Verbinden Sie Ihren mit inblog erstellten Blog über eine Subdomain (z. B. blog.example.com), eine Root-Domain oder ein Unterverzeichnis (z. B. example.com/blog) mit Anleitungen zur DNS-Konfiguration.

Überblick

Der Bereich zur Domain-Einrichtung kann die Unterstützung eines Entwicklers erfordern, insbesondere bei der DNS-Konfiguration oder der Code-Implementierung. Bei Bedarf stehen technische Support-Sitzungen zur Verfügung.

Sie können Ihren mit inblog erstellten Blog auf eine von drei Arten verbinden:

• Subdomain (z. B. blog.example.com)
• Root-Domain (z. B. example.com)
• Unterverzeichnis (z. B. example.com/blog)

Wo DNS-Einträge hinzugefügt werden müssen: DNS-Einstellungen müssen dort hinzugefügt werden, wo Ihre Domain verwaltet wird (z. B. Namecheap, GoDaddy, Cloudflare), nicht dort, wo Ihre Website erstellt wurde (z. B. Webflow, Framer). Wenn Sie Ihre Website mit Webflow erstellt, Ihre Domain jedoch über GoDaddy erworben haben, fügen Sie die DNS-Einträge in GoDaddy hinzu.

Wo Sie die Domain-Einstellungen finden

1. Melden Sie sich unter inblog.ai/dashboard an. Sie gelangen zu Ihrer Blog-Liste.
2. Klicken Sie auf die Karte des Blogs, den Sie einrichten möchten. Domains werden pro Blog konfiguriert. Wenn Sie mehr als einen betreiben, prüfen Sie, ob der richtige Blog ausgewählt ist.
3. Klicken Sie im linken Menü unter der Gruppenüberschrift Einstellungen auf Domain. (Öffnen Sie nicht erst den Einstellungen-Bildschirm, um darin zu suchen — klicken Sie direkt im linken Menü auf Domain.)
4. Wählen Sie oben auf dem Domain-Bildschirm den Reiter Unterverzeichnis, Subdomain oder Root-Domain, geben Sie Ihre Adresse ein und klicken Sie auf Verbindung starten. Auf dem Reiter Unterverzeichnis wählen Sie anschließend die von Ihnen verwendete Web-Infrastruktur aus, und die passende Schritt-für-Schritt-Anleitung für den Reverse-Proxy wird angezeigt.

Wenn der Domain-Bildschirm ausgegraut ist und keine Eingaben annimmt, befindet sich der Blog im Free-Plan. Eigene Domains sind im Team-Plan verfügbar, einschließlich der 14-tägigen kostenlosen Testphase.

Wenn beim Klicken auf die Karte statt der Verwaltungsansicht ein initialer Einrichtungsbildschirm geöffnet wird, folgen Sie dem dortigen Domain-Schritt. Einzelheiten finden Sie im Abschnitt zur Ersteinrichtung unter Erste Schritte mit inblog.

Einrichtung einer Subdomain

Wählen Sie in den Einstellungen für die eigene Domain Subdomain und geben Sie Ihre Domain ein — ohne den Subdomain-Teil. Dem Feld ist ein festes https://blog. vorangestellt, sodass die Eingabe von example.com hier immer blog.example.com verbindet.

Ein Blog verwendet jeweils nur eine Verbindungsmethode gleichzeitig; Sie können daher blog.example.com und news.example.com nicht parallel betreiben.

Klicken Sie auf Verbindung starten, um die Anweisungen zur DNS-Konfiguration zu erhalten. Fügen Sie die Einträge bei Ihrem DNS-Anbieter genau wie angegeben hinzu. DNS-Änderungen können bis zu 24 Stunden dauern, bis sie wirksam werden, und inblog überprüft die Verbindung automatisch.

Wenn jemand anderes Ihre Domain verwaltet, verwenden Sie unter den DNS-Einträgen Anfrage kopieren und senden Sie die Nachricht an Ihren Entwickler oder Domain-Administrator. Sie enthält die Adresse und alle Einträge, die hinzugefügt werden müssen.

Wenn Ihr DNS-Anbieter den CNAME-Wert ablehnt: Einige Anbieter (z. B. Gabia) erfordern, dass der Wert ein vollqualifizierter Domainname (FQDN) ist, und zeigen einen Fehler wie „Wert muss mit einem Punkt (.) enden“ an. Fügen Sie in diesem Fall dem genauen Wert, den inblog Ihnen gegeben hat, einen abschließenden Punkt hinzu. Wenn inblog beispielsweise abc123.vercel-dns-016.com anzeigt, geben Sie abc123.vercel-dns-016.com. ein. Andere Anbieter (z. B. Imweb) erwarten den Wert ohne den abschließenden Punkt. Folgen Sie dem Format, das Ihr Anbieter verlangt.

Kann ich auch www verbinden oder eine zweite Domain hinzufügen?

Nein. Ein Blog fasst genau eine eigene Domain. Bei Subdomain- und Root-Domain-Verbindungen stellt inblog ein SSL-Zertifikat nur für die von Ihnen registrierte Adresse aus. Anfragen für eine Adresse, die nicht registriert ist, können nicht empfangen und weitergeleitet werden, und es gibt auch kein separates Alias-Feld für www.

Wenn Sie www.example.com → example.com benötigen (beispielsweise weil Google die www-Version bereits als kanonisch behandelt):

• Wenn Sie www nur mit einem CNAME auf inblog verweisen lassen, führt dies zu einem Zertifikatsfehler wie ERR_CERT_COMMON_NAME_INVALID — www ist ein separater Hostname, für den kein Zertifikat existiert.

• Belassen Sie nur Ihre kanonische Adresse in inblog registriert und verweisen Sie mit www auf den Weiterleitungsdienst der Stelle, die Ihre Domain oder Ihr Hosting verwaltet (Cloudflare, Vercel, Ihr Webserver). Stellen Sie dort ein www-Zertifikat aus und fügen Sie dann eine permanente Weiterleitung wie unten beschrieben hinzu. Wir empfehlen 308 für neue Regeln; behalten Sie eine korrekt funktionierende 301 bei oder verwenden Sie 301, wenn Ihr Anbieter nur dies unterstützt. Siehe 308 vs. 301 und wann welches verwendet werden sollte:

  https://www.example.com/*  →  https://example.com/*
  

• Behalten Sie Pfad und Query-String in der Regel bei. Die umgekehrte Richtung (example.com → www.example.com) funktioniert genauso.

Wenn Sie zwei Adressen gleichzeitig betreiben möchten (beispielsweise blog.example.com beibehalten und example.com/guide hinzufügen):

• Erstellen Sie einen zweiten Blog und verbinden Sie die zweite Adresse damit.
• Sowohl Abonnements als auch Domain-Verbindungen gelten bei inblog pro Blog; ein Team-Plan-Abonnement kann daher nicht zwei Blogs abdecken. Der neue Blog benötigt ein eigenes Abonnement — siehe die FAQ.
• Wenn unter dem Pfad, den Sie hinzufügen möchten, bereits eine Seite existiert (z. B. wenn example.com/guide derzeit etwas anderes öffnet), ersetzt die Verbindung als Unterverzeichnis diesen Pfad durch inblog. Verschieben Sie die bestehende Seite an einen anderen Ort oder wählen Sie einen Pfad, der frei ist.

Einrichtung eines Unterverzeichnisses (Unterordner)

Das Dashboard bietet derzeit Einrichtungsanleitungen für Next.js, Vercel, AWS Amplify, AWS CloudFront, Cloudflare, Nginx, Webflow und Framer. Wählen Sie Sonstiges / Kontakt, wenn Ihre Infrastruktur nicht aufgeführt ist.

Unterstützte Plattformen sind unter anderem:

• Next.js: Unterstützt, außer bei statischem Export
• Vercel / AWS Amplify: Als Hosting-Plattformen unterstützt
• Cloudflare: Unterstützt, wenn Sie die Zone, den Worker und die Routen des Hostnamens in Ihrem eigenen Cloudflare-Konto verwalten können und die bestehende Website funktioniert, während ihr DNS-Eintrag auf Proxied steht. Dass Cloudflare in Antwort-Headern oder bei einem IP-Lookup zu sehen ist, reicht allein nicht aus, um diese Anforderung zu erfüllen.
• Framer / Webflow: Unterstützt über einen Reverse-Proxy mit Cloudflare

Bevor Sie die Cloudflare-Anleitung verwenden: Fahren Sie nur fort, wenn die bestehende Website bereits mit Proxied funktioniert und der Zielpfad (beispielsweise /blog) ungenutzt ist oder dessen bestehende Inhalte und URLs migriert wurden. Ein DNS only-Eintrag, ein SaaS-Website-Builder, ein anderes CDN oder ein anderer Proxy oder ein Konto, das die Cloudflare-Zone und die Worker-Routen nicht verwalten kann, erfordert eine separate Prüfung. Wenn der Hostname nicht mit Proxy betrieben werden kann, verwenden Sie stattdessen eine Subdomain-Verbindung.

Die Verbindungsanleitung des Dashboards bietet auch eine Schritt-für-Schritt-Einrichtung für AWS CloudFront und Nginx.

Wenn Ihre Umgebung nicht in dieser Liste enthalten ist (beispielsweise Apache), wählen Sie Sonstiges / Kontakt. Jeder Webserver, der einen bestimmten Pfad an einen externen Ursprung weiterleiten kann, kann über einen benutzerdefinierten Reverse-Proxy verbunden werden — melden Sie sich über den Chat bei uns und wir prüfen die Machbarkeit gemeinsam mit Ihnen.

Wählen Sie in den Einstellungen für die eigene Domain Unterverzeichnis und geben Sie Ihre Domain ein (z. B. example.com/blog). Klicken Sie auf Verbindung starten, um die vollständige Einrichtungsanleitung zu erhalten. Beachten Sie, dass die Einrichtung eines Unterverzeichnisses in der Regel eine Code-Implementierung erfordert.

Die Auswahl der „Web-Infrastruktur“ ändert auf Seiten von inblog nichts. Sie bestimmt lediglich, welche Einrichtungsanleitung Ihnen angezeigt wird. Ein späterer Wechsel hat daher keine Auswirkungen auf eine bereits verbundene Domain.

Wenn sich bereits ein CDN oder Proxy wie Cloudflare oder CloudFront vor Ihrem Webserver (Apache, Nginx usw.) befindet, wählen Sie dieses CDN, unabhängig vom Ursprungsserver. Die Handhabung der Proxy-Regel dort, wo Anfragen zuerst ankommen, ist einfacher und lässt Ihre Origin-Konfiguration unangetastet.

Mein Domain-Registrar ist nicht in der Liste der „Web-Infrastruktur“ aufgeführt

Das ist zu erwarten. Die Liste fragt ab, von wo aus Ihre Website derzeit ausgeliefert wird, nicht wo Sie die Domain gekauft haben. Auf dem Bildschirm steht: „Wählen Sie die Infrastruktur, auf der Ihre Website gehostet wird, und folgen Sie dann der entsprechenden Anleitung unten.“ Es werden nur Umgebungen aufgeführt, für die inblog eine Proxy-Anleitung bereitstellt; Registrare und DNS-Anbieter wie Namecheap oder GoDaddy sind hier daher keine Optionen.

Wenn Ihr Anbieter sowohl Domains als auch Webhosting anbietet (Gabia, Cafe24 und ähnliche), orientieren Sie sich an dem Webserver, auf dem Ihre Website tatsächlich läuft — meist Apache oder Nginx — und nicht am Namen des Anbieters. Nginx bedeutet Nginx; Apache oder alles, was Sie nicht sicher bestimmen können, bedeutet Sonstiges / Kontakt.

Die Liste enthält: NextJS, Vercel, AWS Amplify, AWS CloudFront, Cloudflare, Nginx, Webflow, Framer und Other / Contact us. (Ein koreanischsprachiges Dashboard zeigt zusätzlich Cafe24 und Imweb an; die Auswahl eines der beiden meldet, dass eine Unterverzeichnis-Verbindung für diese Umgebung nicht verfügbar ist.)

So entscheiden Sie:

1. Wenn sich ein CDN oder Proxy wie Cloudflare oder AWS CloudFront vor Ihrer Website befindet, wählen Sie dieses CDN unabhängig vom Ursprungsserver.
2. Wählen Sie andernfalls den Server oder die Plattform, die die Website tatsächlich ausliefert (Nginx, Vercel, NextJS, Framer usw.).
3. Wenn die Website mit etwas erstellt wurde, das nicht aufgeführt ist (WordPress, PHP), richten Sie sich nach dem Server, auf dem sie läuft, nicht nach dem Tool, mit dem sie erstellt wurde. WordPress auf Nginx ist Nginx; WordPress auf Apache ist nicht aufgeführt, wählen Sie also Sonstiges / Kontakt.
4. Wenn Sie es nicht wissen, wählen Sie Sonstiges / Kontakt — dadurch wird ein Chat mit uns geöffnet und wir prüfen die Machbarkeit gemeinsam.

Wenn eine Agentur Ihre Website erstellt hat, fragen Sie sie nach zwei Dingen:

1. Welcher Webserver oder welches Hosting die Website heute ausliefert (Nginx, Apache, Vercel usw.) und ob ein CDN wie Cloudflare oder CloudFront davor geschaltet ist.
2. Ob sie eine Reverse-Proxy-Regel (Rewrite-Regel) ausschließlich für /blog und /blog/* hinzufügen können. Es muss ein Rewrite sein, keine Weiterleitung (Redirect).

Muss ich für eine Subdomain eine Web-Infrastruktur auswählen?

Nein. Die Auswahl der Web-Infrastruktur erscheint nur bei Unterverzeichnis-Verbindungen.

Verbindungen über eine Subdomain (blog.example.com) und eine Root-Domain (example.com) berühren den Server Ihrer bestehenden Website zu keinem Zeitpunkt — Sie fügen lediglich DNS-Einträge hinzu —, sodass dieser Bildschirm gar nicht erst erscheint. Wenn Sie die Infrastrukturliste sehen, befinden Sie sich derzeit im Ablauf für ein Unterverzeichnis.

Wenn Sie auf dem Server Ihrer Website keine Proxy-Regel hinzufügen können, ist der Wechsel zu einer Subdomain-Verbindung im Domain-Reiter meist der schnellere Weg: Er erfordert lediglich DNS-Einträge bei der Stelle, die Ihre Domain verwaltet.

Einrichtung eines Unterverzeichnisses mit AWS CloudFront

Um inblog mit AWS CloudFront in einem Unterverzeichnis einzurichten, prüfen Sie die folgenden Einrichtungsschritte.

1. Verwenden Sie die Distribution, die Ihre Haupt-Website bereitstellt, oder erstellen Sie eine neue Distribution, falls CloudFront noch nicht eingerichtet ist.
2. Setzen Sie Distribution name auf inblog proxy und Domain auf example.com.
3. Setzen Sie Origin type auf Other, Custom origin auf proxy.inblog.dev und Origin path auf /{subdomain}.
4. Setzen Sie die Origin-Request-Policy auf Managed-AllViewerExceptHostHeader, damit CloudFront den Host-Header des Besuchers nicht an proxy.inblog.dev weiterleitet.
5. Erstellen Sie eine CloudFront Function für das URI-Rewriting und fügen Sie den folgenden Code ein.

function handler(event) {
  var request = event.request;
  var uri = request.uri;
  var basePath = "/blog";

  var host = request.headers.host && request.headers.host.value;
  if (host) {
    request.headers["x-inblog-public-host"] = { value: host };
    request.headers["x-forwarded-host"] = { value: host };
  }
  request.headers["x-forwarded-prefix"] = { value: basePath };

  if (basePath === "/") {
    return request;
  }

  if (uri === basePath) {
    request.uri = "/";
    return request;
  }

  if (uri === basePath + "/") {
    request.uri = "/";
    return request;
  }

  if (uri.startsWith(basePath + "/")) {
    request.uri = uri.substring(basePath.length);
    return request;
  }

  return request;
}

6. Fügen Sie Behaviors für /blog, /blog/* und /robots.txt hinzu.
7. Veröffentlichen Sie die Function als Live und verknüpfen Sie sie dann mit dem Viewer request-Event für alle drei Behaviors.

Überprüfen Sie nach der Bereitstellung die folgenden URLs in Ihrem Terminal.

curl -I https://example.com/blog
curl -I https://example.com/robots.txt

CloudFront gibt einen 502-Fehler zurück

Stellen Sie zunächst sicher, dass Sie Origin path nicht leer gelassen haben. Eine Unterverzeichnis-Verbindung verwendet Custom origin proxy.inblog.dev zusammen mit Origin path /{subdomain} — keinen separaten CNAME-Wert.

Wenn Ihre Einstellungen dem entsprechen und 502-Fehler weiterhin auftreten, prüfen Sie die folgenden Punkte der Reihe nach. In den meisten Fällen fehlt einer davon.

1. Alle drei Behaviors — /blog, /blog/* und /robots.txt — verwenden den Ursprung proxy.inblog.dev.
2. Alle drei Behaviors verwenden die Origin-Request-Policy Managed-AllViewerExceptHostHeader. Wenn der Host-Header des Besuchers weitergeleitet wird, kann der Ursprung die Anfrage nicht verarbeiten.
3. Die CloudFront Function ist als Live veröffentlicht — sie nur zu speichern, reicht nicht aus.
4. Diese Function ist bei allen drei Behaviors mit dem Event Viewer request verknüpft.
5. Die Bereitstellung der Distribution ist abgeschlossen (Deployed), einschließlich Ihrer jüngsten Änderung.

Wenn alle oben genannten Punkte überprüft wurden und der 502-Fehler weiterhin besteht, senden Sie uns die Ausgabe der drei folgenden Befehle. Ein Vergleich einer Anfrage über CloudFront mit einer Anfrage direkt an den Ursprung ermöglicht es uns, die Ursache einzugrenzen.

curl -I https://example.com/blog
curl -I https://example.com/robots.txt
curl -I https://proxy.inblog.dev/{subdomain}

Einrichtung eines Unterverzeichnisses mit Apache

Apache ist in der Infrastrukturliste des Dashboards nicht aufgeführt; wählen Sie daher Sonstiges / Kontakt und fügen Sie die Reverse-Proxy-Regeln selbst in Apache ein. Ersetzen Sie example.com, /blog und {subdomain} durch Ihre eigenen Werte.

Bestätigen Sie zunächst, auf welchen Server die Regeln gehören. Das Unternehmen, bei dem Sie die Domain gekauft haben (Registrar/Nameserver), ist oft nicht der Server, der Ihre Website tatsächlich ausliefert. Wenn Ihre Nameserver bei einem Hosting-Anbieter liegen, während die Website selbst auf Apache auf einer AWS EC2-Instanz läuft, gehören die Proxy-Regeln in die Apache-Konfiguration dieser EC2-Instanz, nicht in die DNS-Ansicht des Hosting-Anbieters.

Fügen Sie Folgendes zu dem VirtualHost hinzu, der Ihre Website ausliefert (dem Port-443-VirtualHost, wenn Sie HTTPS verwenden).

SSLProxyEngine On
ProxyPreserveHost Off

<Location "/blog">
  RequestHeader set X-Inblog-Public-Host "expr=%{HTTP_HOST}"
  RequestHeader set X-Forwarded-Host "expr=%{HTTP_HOST}"
  RequestHeader set X-Forwarded-Prefix "/blog"
</Location>

ProxyPass "/blog" "https://proxy.inblog.dev/{subdomain}"
ProxyPassReverse "/blog" "https://proxy.inblog.dev/{subdomain}"

ProxyPass "/robots.txt" "https://proxy.inblog.dev/{subdomain}/robots.txt"
ProxyPassReverse "/robots.txt" "https://proxy.inblog.dev/{subdomain}/robots.txt"

• ProxyPass "/blog" leitet auch alles unterhalb von /blog weiter, sodass Sie keine separate Regel für einzelne Beitrags-URLs benötigen.
• Die beiden RequestHeader-Zeilen innerhalb von <Location "/blog"> übermitteln inblog die Adresse, die Besucher tatsächlich aufrufen (example.com), und das Unterverzeichnis, unter dem sie bereitgestellt wird (/blog). Der Proxy entfernt beides, und Analytics benötigt diese Angaben, um Beitrags-URLs korrekt zuzuordnen. Das Routing liest sie nicht aus, sodass der Blog auch dann weiter funktioniert, wenn Sie sie weglassen (sie erfordern mod_headers). Belassen Sie sie innerhalb des <Location>-Blocks: Auf VirtualHost-Ebene würden sie an jede Anfrage Ihrer eigenen Website angehängt und könnten die Art und Weise verändern, wie Ihre Anwendung ihre URLs aufbaut.
• ProxyPreserveHost Off ist die entscheidende Zeile. Wenn der Host-Header des Besuchers unverändert weitergeleitet wird, kann inblog die Anfrage nicht verarbeiten. Sie erfüllt dieselbe Funktion wie CloudFronts Policy Managed-AllViewerExceptHostHeader und Nginxs proxy_set_header Host proxy.inblog.dev.
• Überspringen Sie die /robots.txt-Regeln, wenn Sie bereits eine eigene robots.txt betreiben. Siehe Überschreibt die Einrichtung eines Unterverzeichnisses meine bestehende robots.txt? weiter unten.

Aktivieren Sie die erforderlichen Module, testen Sie die Konfiguration und laden Sie den Server neu.

Ubuntu / Debian

sudo a2enmod proxy proxy_http ssl headers
sudo apachectl configtest
sudo systemctl reload apache2

Amazon Linux / CentOS / RHEL (die Module sind oft bereits aktiviert)

sudo apachectl configtest
sudo systemctl reload httpd

Sobald beide nachfolgenden URLs den Status 200 zurückgeben, wechselt der Status auf dem inblog Domain-Bildschirm automatisch zu Verbunden.

curl -I https://example.com/blog
curl -I https://example.com/robots.txt

Wenn Sie keine Berechtigungen (sudo) zum Bearbeiten der VirtualHost-Datei haben, bitten Sie die Person, die den Server verwaltet, die oben stehende Konfiguration anzuwenden.

Mein Unterverzeichnis-Blog gibt ERR_TOO_MANY_REDIRECTS zurück

Der Blog-Pfad steckt in einer Weiterleitungsschleife fest und lädt überhaupt nicht. Die Ursache ist in der Regel eine /blog-Regel auf Ihrer eigenen Website. Diese beiden Fälle kommen am häufigsten vor.

1. Es muss ein rewrite sein, kein redirect

Die Übergabe von /blog an inblog erfordert ein Rewrite (Reverse-Proxy) — die Adresse bleibt unverändert und Ihr Server antwortet mit der Antwort von inblog. Ein redirect führt dazu, dass die /blog-Anfrage wieder auf /blog verweist, was zu einer Endlosschleife führt.

/blog       →  https://proxy.inblog.dev/{subdomain}
/blog/:path*  →  https://proxy.inblog.dev/{subdomain}/:path*

2. Die www-Form unterscheidet sich zwischen inblog und der kanonischen Adresse Ihrer Website

Wenn Ihre Website example.com (ohne www) als kanonisch behandelt, die auf inblog registrierte Adresse jedoch www.example.com/blog ist, prallen die Weiterleitungen zwischen www und Non-www gegeneinander ab. Legen Sie sich auf eine Form fest.

• Registrieren Sie die Adresse auf dem inblog Reiter Domain in derselben Form, die Ihre Website als kanonisch verwendet.
• Richten Sie die Vereinheitlichung von www → Non-www in den Domain-Weiterleitungseinstellungen Ihres Hosts in nur eine Richtung ein — nicht als /blog-spezifische Regel.

So stellen Sie fest, welche Seite fehlerhaft ist

Vergleichen Sie die Antwort-Header für jede Adresse. Wenn der letzte Befehl 200 zurückgibt, müssen in der Regel die Weiterleitungsregeln Ihrer Website korrigiert werden — beachten Sie die Ausnahme direkt darunter. Wenn er stattdessen einen 3xx-Code zurückgibt, muss die inblog-Seite überprüft werden — senden Sie uns diese Ausgabe über den Chat.

curl -I https://example.com/blog
curl -I https://www.example.com/blog
curl -I https://proxy.inblog.dev/{subdomain}

Wenn die Regel bereits ein rewrite ist und proxy.inblog.dev mit 200 antwortet, die Schleife aber dennoch fortbesteht, überprüfen Sie den location-Header in der Antwort des ersten Befehls. Wenn er Sie zu der Adresse zurückschickt, die Sie gerade angefordert haben, wird keine weitere Änderung auf Ihrer Seite das Problem beheben. Hören Sie auf, die Regeln zu bearbeiten, und senden Sie uns diesen vollständigen Antwort-Header über den Chat.

Eine Warnung bei der Domain-Verbindungsprüfung auf der Domain-Karte kann dieselbe Ursache haben. Sie erscheint auch bei Firewall-Blockaden oder vorübergehenden Störungen und verschwindet bei der nächsten Überprüfung von selbst, sobald die Proxy-Regeln funktionieren. Siehe Was die Warnung bei der Verbindungsprüfung bedeutet für eine Aufschlüsselung der einzelnen Meldungen.

Mein Blog funktionierte gestern und gibt jetzt 404 zurück

In inblog hat sich nichts geändert, aber die gesamte Adresse example.com/blog gibt 404 zurück. Die häufigste Ursache ist, dass durch ein erneutes Bereitstellen (Redeploy), eine CDN-Änderung oder eine Firewall-Änderung auf Ihrer Website die /blog-Proxy-Regel gelöscht oder überschrieben wurde.

Erstens: Trennen Sie die Domain in inblog nicht. Das Entfernen und erneute Hinzufügen der Verbindung stellt die Proxy-Regel Ihrer Website nicht wieder her — es zwingt Sie lediglich dazu, die Domain-Verifizierung erneut zu durchlaufen.

1. Identifizieren Sie, welche 404-Seite Sie sehen

Das Aussehen der 404-Seite verrät Ihnen, wie weit die Anfrage gelangt ist.

2. Isolieren Sie die fehlerhafte Seite mit einer Anfrage

curl -I https://example.com/blog
curl -I https://proxy.inblog.dev/{subdomain}

Wenn der zweite Befehl 200 zurückgibt, ist bei inblog alles in Ordnung und Sie müssen lediglich die /blog-Regel auf Ihrer Website wiederherstellen. Wenn der zweite Befehl ebenfalls fehlschlägt, senden Sie uns diese Ausgabe über den Chat.

3. Nachvollziehen, was sich kürzlich geändert hat

• Ein Redeploy der Website — wenn die Proxy-Konfiguration nicht Teil Ihrer Build-Ausgabe ist, löscht jedes Deployment die Regel.
• Änderungen an CDN- oder WAF-Regeln oder eine neu hinzugefügte Bot-Schutz-Richtlinie.
• Ersetzen der Webserver-Konfiguration, Zertifikatserneuerung oder ähnliche Serverarbeiten.

4. Überprüfen Sie auch die Warnung im Dashboard

Wenn unter Einstellungen → Domain eine Warnung angezeigt wird, erläutert der folgende Abschnitt die Bedeutung der jeweiligen Meldung.

Was bedeutet die Warnung bei der Verbindungsprüfung auf der Domain-Karte?

inblog prüft regelmäßig, ob Ihre verbundene Domain diesen Blog tatsächlich bereitstellt, und zeigt unter Einstellungen → Domain eine Warnung bei der Domain-Verbindungsprüfung an, wenn nicht die erwartete Antwort eingeht.

Die Warnung allein hindert Besucher nicht daran, Ihren Blog zu erreichen, und sie verschwindet automatisch, sobald eine spätere Prüfung erfolgreich ist. Jede Meldung weist auf eine andere Ursache hin.

Überschreibt die Einrichtung eines Unterverzeichnisses meine bestehende robots.txt?

Die Einrichtungsanleitung enthält eine Regel, die neben Ihren Blog-Pfaden (/blog, /blog/*) auch /robots.txt an inblog weiterleitet. Diese Regel ist für Websites gedacht, die noch keine eigene robots.txt haben. Wenn Sie bereits eine eigene Datei pflegen, wenden Sie diese Regel nicht unverändert an.

Eine Domain hat nur eine robots.txt, die vom Root-Verzeichnis aus bereitgestellt wird und für jeden Pfad darunter gilt. Ein Proxying von /robots.txt bedeutet, dass die Datei von inblog anstelle Ihrer Datei antwortet, sodass alle zuvor vorhandenen Disallow-Regeln nicht mehr greifen.

Wenn Sie bereits eine robots.txt haben, wählen Sie eine der folgenden Optionen:

1. Nur die /robots.txt-Regel weglassen (empfohlen)

• Behalten Sie die Proxy-Regeln für Ihre Blog-Pfade (/blog, /blog/*) bei und entfernen Sie nur die /robots.txt-Regel.
• Fügen Sie die Sitemap Ihres Blogs zu Ihrer bestehenden robots.txt hinzu:

Sitemap: https://example.com/blog/sitemap.xml

• Vergewissern Sie sich, dass keine Ihrer bestehenden Disallow-Regeln den Blog-Pfad (/blog) blockiert.

2. Den Proxy beibehalten und robots.txt innerhalb von inblog bearbeiten

• Gehen Sie im Dashboard zu Einstellungen → SEO Tools → Robots.txt (im kostenpflichtigen Plan, nachdem Ihre eigene Domain verbunden ist).
• Fügen Sie Ihre bestehenden Regeln dort ein und behalten Sie die Zeile für die Blog-Sitemap bei. Alles, was Sie speichern, wird als Antwort für example.com/robots.txt ausgeliefert.
• Der Editor ist mit den Standardeinstellungen vorbefüllt, die inblog generiert (alle Crawler zulassen, plus Sitemap-URLs). Löschen Sie den Inhalt vollständig und speichern Sie, um zu diesem Standard zurückzukehren.

Sie müssen die Sitemap nicht selbst pflegen. Wenn der Proxy eingerichtet ist, wird example.com/blog/sitemap.xml bei jeder Veröffentlichung oder Bearbeitung eines Beitrags von inblog neu generiert. Es muss auf Ihrer Seite keine XML-Datei hochgeladen oder aktualisiert werden.

Unterverzeichnis und Google Search Console

Wenn Sie ein Unterverzeichnis verbinden (z. B. example.com/blog), wird Ihr Blog-Traffic in der bestehenden Search-Console-Property der Root-Domain erfasst. Wenn Sie Blog-Daten separat analysieren möchten, können Sie eine zusätzliche Nur diese Blogadresse-Property (URL-Präfix-Property) hinzufügen:

• Property-Typ: URL-Präfix
• URL: https://example.com/blog

Diese separate Property erfordert ebenfalls eine eigene Verifizierung per HTML-Tag. Fügen Sie das Meta-Tag für diese Property im inblog-Dashboard unter Design-Reiter → Erweiterte Einstellungen (Code-Injection) hinzu.

„Verbindung starten“ bewirkt nichts oder ein Fehler-Popup blockiert den nächsten Schritt

Dies betrifft den Schritt vor den DNS-Einträgen — die Verbindung selbst startet nicht.

Wenn die Anfrage abgelehnt wird, zeigt der Domain-Bildschirm einen Fehler neben dem Adressfeld oder in einem Popup an. Prüfen Sie die folgenden Ursachen, bevor Sie es erneut versuchen.

Prüfen Sie die folgenden Punkte der Reihe nach.

1. Vergewissern Sie sich, dass Sie einen kostenpflichtigen Plan nutzen. Das Verbinden einer eigenen Domain ist eine Funktion der kostenpflichtigen Pläne, weshalb Verbindungsanfragen im Free-Plan abgelehnt werden.
2. Bestätigen Sie, dass Ihr Konto Domains verbinden darf. Nur ein Eigentümer, Administrator oder Redakteur dieses Blogs — mit bereits angenommener Einladung — kann eine Domain verbinden oder trennen.
3. Verbinden und trennen Sie die Domain nicht wiederholt in kurzen Abständen. Anfragen zum Verbinden/Trennen von Domains sind auf 10 pro Stunde begrenzt. Nach Überschreiten dieses Limits wird jeder weitere Versuch abgelehnt und nicht fortgesetzt. Es liegt keine Fehlkonfiguration vor — warten Sie einfach etwa eine Stunde und versuchen Sie es einmal erneut.
4. Prüfen Sie das Eingabeformat. Der Reiter Subdomain stellt dem Feld bereits https://blog. voran; geben Sie daher nur example.com ein — ohne https:// oder www. Der Reiter Unterverzeichnis erwartet den vollständigen Pfad, wie www.example.com/blog.
5. (Unterverzeichnis) Bestätigen Sie, dass die eingegebene Domain im Internet bereits auflösbar ist. Bevor die Verbindung gestartet wird, schlägt inblog den Domain-Teil von www.example.com/blog (www.example.com) im öffentlichen DNS nach. Wenn für diesen genauen Host kein öffentlicher A-, AAAA- oder CNAME-Eintrag existiert, schlägt der Lookup fehl und die Anfrage wird abgewiesen. (Wenn Sie www eingegeben haben, muss der Eintrag auf dem Host www vorhanden sein.)

Eine Unterverzeichnis-Verbindung bettet Ihren Blog in eine Website ein, die bereits live ist. Dieser Schritt prüft nur, ob der DNS-Eintrag existiert; die darauf folgenden Schritte erfordern jedoch, dass Sie eine Reverse-Proxy-Regel auf dieser Website hinzufügen. Richten Sie zuerst den DNS-Eintrag ein, der auf Ihre bestehende Website verweist, bestätigen Sie, dass sich https://www.example.com normal öffnet, und starten Sie dann die Verbindung. Bei Cloudflare muss dieser Eintrag auf Proxied stehen.

Handelt es sich um eine neue Domain, hinter der sich noch keine Website befindet, ist eine Unterverzeichnis-Verbindung nicht geeignet — es gibt keine Website, auf der eine Proxy-Regel eingerichtet werden könnte. Verwenden Sie stattdessen eine Subdomain wie blog.example.com; Subdomain- und Root-Domain-Verbindungen funktionieren durch das Hinzufügen der von inblog bereitgestellten DNS-Einträge, sodass keine bestehende Website erforderlich ist.

Was bedeutet (nicht verifiziert) in der Blog-Liste?

Nach dem Hinzufügen von DNS-Einträgen kann der Domain-Status in der Blog-Liste des inblog-Dashboards (nicht verifiziert) anzeigen. Dies bedeutet, dass inblog Ihre DNS-Einträge noch nicht bestätigt hat. Häufige Gründe:

• Die DNS-Einträge wurden noch nicht hinzugefügt oder die Werte sind fehlerhaft.
• Die DNS-Propagierung dauert nach vorgenommenen Änderungen bis zu 24–48 Stunden.

Sobald der Status zu (verifiziert) wechselt, ist die DNS-Bestätigung abgeschlossen. Es kann noch einige Minuten dauern, bis die Domain vollständig erreichbar ist.

Im Domain-Reiter steht „SSL-Zertifikat wird ausgestellt“. Soll ich einfach warten?

In den meisten Fällen ja. Sofern Sie keinen CAA-Eintrag für die Domain gesetzt haben, gibt es für Sie nichts weiter zu tun. „SSL-Zertifikat wird ausgestellt“ erscheint erst, nachdem Ihre DNS-Einträge bestätigt wurden, wenn die HTTPS-Einrichtung der letzte verbleibende Schritt ist. Das bedeutet, dass Ihre Einträge die Überprüfung bereits bestanden haben.

Bei Subdomain- und Root-Domain-Verbindungen zeigt der Reiter Domain einen von vier Verbindungsstatus an:

Unterverzeichnis-Verbindungen zeigen stattdessen drei andere Status an: Reverse-Proxy-Einrichtung erforderlich, Reverse-Proxy-Verbindung wird überprüft und Verbunden.

DNS-Änderungen können bis zu 24–48 Stunden dauern, bis sie wirksam sind, und es kann nach Ausstellung des Zertifikats noch einige Minuten dauern, bis sich die Website öffnen lässt.

• Wenn Sie einen CAA-Eintrag für die Domain gesetzt haben, überprüfen Sie auch diesen — er kann die Zertifikatsausstellung blockieren.
• Wenn der Status länger als einen Tag auf „SSL-Zertifikat wird ausgestellt“ verbleibt, senden Sie uns die Adresse, die Sie verbinden möchten, zusammen mit einem Screenshot.

Auf der Domain-Karte steht „Nameserver für diese Domain konnten nicht gefunden werden.“

inblog schlägt die Nameserver der Root-Domain hinter der von Ihnen eingegebenen Adresse nach (z. B. blog.example.com → example.com), um Ihnen mitteilen zu können, bei welchem DNS-Dienst Einträge hinzugefügt werden müssen. Diese Warnung bedeutet, dass dieser Lookup kein Ergebnis geliefert hat. Überprüfen Sie Folgendes:

• Die Domain ist richtig geschrieben.
• Die Domain ist tatsächlich registriert und nicht abgelaufen.
• Bei Ihrem Domain-Registrar sind Nameserver zugewiesen (direkt nach dem Kauf können diese leer sein).

Diese Warnung betrifft lediglich den Lookup, den wir verwenden, um Ihnen mitzuteilen, welchen DNS-Dienst Sie nutzen sollen — sie blockiert die Verifizierung nicht. Wenn der Domain tatsächlich keine Nameserver zugewiesen sind, können auch von Ihnen hinzugefügte Einträge nicht aufgelöst werden; schließen Sie die Nameserver-Einrichtung bei Ihrem Registrar daher zuerst ab. Wenn die Verbindung nach dem Hinzufügen der Einträge normal fortschreitet, können Sie diese Warnung ignorieren.

Bei mir funktioniert es, aber andere können meinen Blog nicht aufrufen

Manchmal zeigt der Domain-Status „Verifiziert“ an und der Blog lädt bei Ihnen einwandfrei, aber Personen, mit denen Sie den Link teilen, können ihn nicht erreichen. Dies ist meist kein Problem der Domain-Konfiguration — das Netzwerk, in dem sie sich befinden (Heim-WLAN, Mobilfunkanbieter, Firmennetzwerk), hat im DNS-Cache noch den alten Stand gespeichert. DNS-Änderungen verbreiten sich in verschiedenen Netzwerken unterschiedlich schnell über einen Zeitraum von bis zu 24–48 Stunden, sodass das öffentliche DNS bereits korrekt sein kann, während einige Netzwerke die Adresse noch nicht auflösen können.

Was Sie tun können:

• Teilen Sie die vollständige Adresse (z. B. https://blog.example.com) anstelle einer unvollständigen.
• Bitten Sie Personen, die den Blog nicht erreichen können, es über mobile Daten statt WLAN zu versuchen oder es etwas später noch einmal zu probieren.
• Wenn der Aufruf in einem bestimmten Netzwerk nach 24–48 Stunden immer noch fehlschlägt, senden Sie uns die genaue verwendete Adresse und einen Screenshot des Fehlers aus dieser Umgebung.

Kann ich einen Subdomain-Blog in ein Unterverzeichnis umziehen?

Ja. Stellen Sie den Verbindungstyp auf dem Reiter Domain auf Unterverzeichnis um und registrieren Sie die neue Adresse (z. B. example.com/blog). Beachten Sie, dass ein Blog nur einen Verbindungstyp gleichzeitig nutzen kann; blog.example.com und example.com/blog können daher nicht nebeneinander betrieben werden.

Was automatisch übernommen wird

• Beitrags-Slugs ändern sich nicht. Nur der Host und der führende Pfad unterscheiden sich, sodass keine Arbeit pro Beitrag anfällt.
• Kanonische URLs, die Sitemap, RSS sowie Kategorie- und Autorenseiten-Adressen wechseln zur neuen Adresse, sobald die neue Verbindung verifiziert ist (Caches benötigen möglicherweise einige Minuten zur Aktualisierung).
• API- und CLI-Automatisierungen (Make, Zapier, n8n usw.) sind nicht betroffen. Ein API-Key ist an den Blog selbst gebunden und nicht an die eigene Domain; das Ändern des Verbindungstyps führt daher zu keinen Unterbrechungen.

Was Sie selbst erledigen müssen

• Richten Sie selbst eine permanente Weiterleitung (308 empfohlen) von Ihrer alten eigenen Subdomain (blog.example.com) ein. Sobald die Verbindung getrennt ist, antwortet inblog nicht mehr auf diesem Host; fügen Sie daher eine Regel blog.example.com/{slug} → example.com/blog/{slug} dort hinzu, wo Sie die Domain oder das Hosting verwalten. Da Slugs unverändert bleiben, reicht eine einzige Regel aus, die den Host austauscht und /blog voranstellt.
• Leiten Sie den DNS-Eintrag von blog.example.com zuerst von inblog weg, andernfalls wird die Weiterleitungsregel nicht wirksam — solange der alte CNAME-Eintrag besteht, werden Anfragen weiterhin an inblog geleitet.
• Die Standard-Domain von inblog (xxx.inblog.io) und Ihre alte eigene Domain weisen ein getrenntes Weiterleitungsverhalten auf. Bei Subdomain- und Root-Domain-Verbindungen leitet die Standard-Domain automatisch weiter, sobald die Domain verifiziert ist und der Blog über einen berechtigten Team-Plan (oder höher) oder eine aktive Testphase verfügt. Bei Unterverzeichnis-Verbindungen hängt die Weiterleitung der Standard-Domain von der Proxy-Einrichtung ab: Ein Proxy, der die Standard-Domain als Origin verwendet, kann eine Endlosschleife erzeugen, wenn diese Adresse zurückleitet. Kontaktieren Sie uns über den Chat, um Ihr Setup zu prüfen, bevor Sie sich auf diese Weiterleitung verlassen. Die kanonische URL signalisiert die Unterverzeichnis-Adresse separat als bevorzugte URL. Ihr Team muss Weiterleitungen von der alten eigenen Domain dennoch konfigurieren.

Wird der Blog während des Wechsels ausfallen?

Prüfen Sie nach der Verifizierung des neuen Proxy-Setups, ob der Blog unter der neuen Unterverzeichnis-Adresse lädt. Prüfen Sie außerdem das Weiterleitungsverhalten der Standard-Domain und die Weiterleitungsregeln der alten eigenen Domain separat. Abgesehen vom Hinzufügen der Pfadregel für /blog bleibt Ihre bestehende Website unberührt.

Suchmaschinen benötigen Zeit, um eine geänderte Adresse neu zu indexieren. Richten Sie eine permanente Weiterleitung von jeder alten Adresse auf die passende neue Seite ein. Wir empfehlen 308 für neue Regeln; eine bestehende, korrekt funktionierende 301 müssen Sie jedoch nicht ändern. Weiterleitungen signalisieren die neue Adresse; sie garantieren weder Indexierung noch Rankings oder Traffic.

Werden nach einer Domain-Änderung auch Links und CTA-Buttons in meinen Beiträgen aktualisiert?

Nein — in Beiträgen hinterlegte Adressen bleiben so, wie sie sind. Kanonische URLs, die Sitemap, RSS sowie Kategorie- und Autorenseiten werden für die neue Domain neu generiert, diese beiden Elemente werden jedoch im Beitrag selbst gespeichert und nicht angepasst:

• Absolute Adressen im Text (Links, Bilder oder Buttons, die auf https://alte-domain/... verweisen)
• Die URL auf dem unteren CTA-Button jedes Beitrags
• Eine kanonische URL, die Sie selbst manuell im Beitrag eingegeben haben. Eine beitragsbezogene kanonische URL hat Vorrang vor der generierten URL und verweist daher weiterhin auf die alte Domain.

Untere CTAs können gesammelt bearbeitet werden. Wählen Sie in der Beitragsverwaltung die Beiträge aus und klicken Sie auf Bearbeiten, um den Dialog zur Massenbearbeitung zu öffnen. Aktivieren Sie dann CTA-Einstellungen und geben Sie unter CTA-Link die neue Adresse ein, um sie auf alle ausgewählten Beiträge gleichzeitig anzuwenden.

• Die Massenbearbeitung überschreibt die ausgewählten Beiträge mit demselben Wert. Es gibt keine Suchen-und-Ersetzen-Funktion, die „alte Domain → neue Domain“ pro Beitrag austauscht; wenn sich die Links unterscheiden, gruppieren Sie Beiträge mit derselben Adresse und wenden Sie die Änderungen schrittweise an.
• Links im Textinhalt werden von der Massenbearbeitung nicht erfasst. Öffnen Sie den jeweiligen Beitrag und bearbeiten Sie sie dort.
• Eine permanente Weiterleitung auf der alten Adresse leitet Besucher zur neuen weiter, die in Ihren Beiträgen gespeicherten Links verweisen jedoch weiterhin auf die alte Domain.

Wenn jeder Beitrag einen anderen CTA-Link hat und Sie nur die Domain austauschen möchten

Wenn Sie Hunderte von Beiträgen haben, deren CTA-Links sich alle unterscheiden, sodass das „überall derselbe Wert“ der Massenbearbeitung nicht weiterhilft, können Sie über die Posts-API nur die Domain austauschen. Sie müssen nicht auf ein eigenes Feature warten.

1. Erstellen Sie im linken Menü unter Einstellungen → API-Keys einen API-Key, der die Scopes posts:read und posts:write enthält.

2. Rufen Sie GET /api/v1/posts seitenweise mit page[number] und page[size] auf, um das Feld cta_link jedes Beitrags auszulesen.

3. Behalten Sie nur die Beiträge, deren Wert die alte Domain enthält.

4. Belassen Sie Pfad, Query und Hash unverändert und ersetzen Sie ausschließlich die Domain durch die neue.

5. Senden Sie für jeden Beitrag PATCH /api/v1/posts/{POST_ID} mit nur dem Feld cta_link. Der Request-Body sieht wie folgt aus:

   { "data": { "type": "posts", "attributes": { "cta_link": "https://new-domain/path" } } }
   

6. Rufen Sie die Beiträge erneut ab und vergewissern Sie sich, dass keine alte Domain mehr vorhanden ist.

Wenn Sie nur cta_link senden, bleiben Inhalt, Titel und Veröffentlichungsstatus unberührt. Beachten Sie, dass dadurch updated_at jedes Beitrags aktualisiert wird, sodass sich die lastmod-Werte in Ihrer Sitemap für jeden bearbeiteten Beitrag auf dieses Datum verschieben. Wir empfehlen, dies zunächst an einigen Beiträgen zu testen und das Ergebnis zu prüfen, bevor Sie den gesamten Bestand bearbeiten. Das genaue Anfrageformat finden Sie in der API-Dokumentation.

Wenn Sie dies nicht selbst durchführen können, kontaktieren Sie uns im Chat unter Angabe Ihrer Blog-Adresse.

Keine Domain? Kein Problem.

Wenn Sie keine eigene Domain haben, können Sie weiterhin die Standard-Blog-Domain verwenden (z. B. example.inblog.io), indem Sie während der Einrichtung die Option „I don't own a domain“ auswählen. Sie können jederzeit auf eine eigene Domain umsteigen.

Wie füge ich der Navigation meiner Haupt-Website einen „Blog“-Reiter hinzu?

inblog hat keinen Zugriff auf das Navigationsmenü Ihrer Haupt-Website. Um einen Blog-Link hinzuzufügen, aktualisieren Sie die Navigation in dem Tool, mit dem Ihre Haupt-Website erstellt wurde (z. B. Webflow, Framer, WordPress oder Ihr CMS).

Verwenden Sie Ihre inblog-Blog-Adresse als Linkziel:

• Subdomain: https://blog.example.com
• Unterverzeichnis: https://example.com/blog

Vor dem Verbinden einer eigenen Domain können Sie vorübergehend die Standard-Domain von inblog verwenden, z. B. https://example.inblog.io.

Wie sorge ich dafür, dass das Logo im Blog-Header zu meiner Haupt-Website verlinkt?

Gehen Sie im inblog-Dashboard zu Design-Reiter → Header. Dort können Sie das Logobild und die URL festlegen, zu der Besucher beim Klicken weitergeleitet werden. Geben Sie die URL Ihrer Haupt-Website ein, um Besucher zu Ihrer Startseite zu führen.

Zuletzt aktualisiert 2026-10-14