Nehmen wir an, Sie haben eine Website, die auf einer Plattform aufgebaut ist, die sich durch Design auszeichnet und unter example.com verfügbar ist. Aber diese Plattform ist beim Bloggen nicht gut. Also denken Sie sich: "Was wäre, wenn ich eine andere Blogging-Plattform nutzen und sie unter example.com/blog verfügbar machen könnte?"
Die meisten Leute würden Ihnen sagen, dass das gegen die Funktionsweise von DNS und Websites verstößt und Sie stattdessen eine Subdomain verwenden sollten. Aber es gibt Vorteile, Ihre Inhalte auf der Root-Domain zu belassen, die wir bei Subdomains nicht haben.
Es gibt eine Möglichkeit, zwei verschiedene Plattformen auf derselben URL bereitzustellen. Und ich werde Ihnen die geheime Zutat zeigen, damit wir am Ende dieses Artikels blog.example.com als example.com/blog bereitstellen.
Warum Sie das tun möchten
Da Sie hier sind, wissen Sie wahrscheinlich schon, warum dies ein Weg ist, den Sie verfolgen sollten. Aber ich möchte sicherstellen, dass Sie aus dem Hauptgrund hier sind: SEO. Schauen Sie sich diese 14 Fallstudien an, die positive Ergebnisse zeigen, wenn Menschen ihre Subdomains in Unterverzeichnisse verschieben. Sie möchten, dass Ihr Blog und Ihre Domain SEO-Werte teilen. Wenn Sie ihn auf einer Subdomain platzieren, würden die beiden etwas getrennt sein.
Das war mein Grund, und ich habe schließlich zwei Plattformen zusammengeführt, wobei die Hauptdomain auf WordPress und die Subdomain auf Drupal lief. Aber dieses Tutorial ist plattformunabhängig – es funktioniert mit fast jeder Plattform.
Allerdings ist der Cloudflare-Ansatz, den wir in diesem Tutorial behandeln, mit Shopify inkompatibel, es sei denn, Sie bezahlen für das Enterprise-Paket von Cloudflare. Das liegt daran, dass Shopify auch Cloudflare nutzt und es uns nicht erlaubt, den Datenverkehr in ihrer kostenlosen Preisstufe zu proxen.
Schritt 0 (Vorschau)
Bevor ich beginne, möchte ich die übergeordnete Ebene dessen erklären, was passieren wird. Kurz gesagt, wir werden zwei Websites haben: unsere Hauptwebsite (example.com) und die Subdomain (blog.example.com). Ich verwende "blog" als Beispiel, aber in meinem Fall musste ich Drupal mit einer anderen Art von Inhalt einbinden. Aber ein Blog ist der typische Anwendungsfall.
Dieser Ansatz beruht auf der Nutzung von Cloudflare für DNS und einem kleinen Extra, das die Magie bewirkt. Wir werden Cloudflare sagen, dass es, wenn jemand example.com/blog besucht,
- diese Anfrage abfängt (da
example.com/blognicht wirklich existiert), - eine andere Domain (
blog.example.com/blog) im Hintergrund anfordert und - die Ergebnisse aus diesem letzten Schritt dem Besucher maskiert durch
example.com/blogliefert.
Okay, tauchen wir tiefer ein!
Schritt 1: Cloudflare verwenden
Auch hier verwenden wir Cloudflare für DNS. Das Verweisen der DNS Ihrer Domain dorthin ist der erste Schritt, um zu beginnen.
Der Grund für Cloudflare ist, dass es uns ermöglicht, Worker zu erstellen, die ein kleines Stück Code ausführen können, wann immer jemand bestimmte URLs (sogenannte Routen, die wir in Schritt 3 erstellen werden) besucht. Dieser Code ist dafür verantwortlich, die Websites im Hintergrund zu wechseln.
Cloudflare hat eine ausgezeichnete Anleitung für den Einstieg. Das Ziel ist es, die DNS Ihrer Domain – wo auch immer sie registriert ist – auf die Nameserver von Cloudflare zu verweisen und zu bestätigen, dass Cloudflare in Ihrem Cloudflare-Konto verbunden ist.
Schritt 2: Den Worker erstellen
Dieser Code ist dafür verantwortlich, die Websites im Hintergrund zu wechseln. Gehen Sie zu Worker und klicken Sie auf Service erstellen.

0,7 ms zur Anfrage hinzugefügt (also praktisch nichts).Benennen Sie Ihren Service und wählen Sie "HTTP-Handler" aus.

Klicken Sie auf Service erstellen und dann auf Schnell bearbeiten.

Fügen Sie den folgenden Code ein und *ersetzen Sie die Domainnamen durch Ihre eigenen in Zeile 16*.
// Listen for every request and respond with our function.
// Note, this will only run on the routes configured in Cloudflare.
addEventListener('fetch', function(event) {
event.respondWith(handleRequest(event.request))
})
// Our function to handle the response.
async function handleRequest(request) {
// Only GET requests work with this proxy.
if (request.method !== 'GET')
return MethodNotAllowed(request);
// The URL that is being requested.
const url = new URL(request.url);
// Request "origin URL" aka the real blog instead of what was requested.
// This switches out the absolute URL leaving the relative path unchanged.
const originUrl = url.toString().replace('https://example.com', 'https://blog.example.com');
// The contents of the origin page.
const originPage = await fetch(originUrl);
// Give the response our origin page.
const newResponse = new Response(originPage.body, originPage); return newResponse;
}
// Hey! GET requests only
function MethodNotAllowed(request) {
return new Response(`Method ${request.method} not allowed.`, {
status: 405,
headers: { 'Allow': 'GET' }
})
}
Klicken Sie abschließend auf Speichern und bereitstellen.
Schritt 3: Routen hinzufügen
Nun informieren wir Cloudflare, auf welchen URLs (auch Routen genannt) dieser Code ausgeführt werden soll. Gehen Sie zur Website in Cloudflare und klicken Sie dann auf Worker.
Es gibt den Worker-Bereich auf dem Hauptbildschirm von Cloudflare, wo Sie den Code bearbeiten, und dann gibt es den Worker-Bereich auf jeder Website, wo Sie die Routen hinzufügen. Das sind zwei verschiedene Orte, und das ist verwirrend.
Klicken Sie zunächst auf Route hinzufügen.

Da wir einen Blog hinzufügen, der viele Unterseiten hat, verwenden wir https://example.com/blog*. Beachten Sie, dass der Sternchen als Platzhalter für die Übereinstimmung dient. Dieser Code wird auf der Blog-Seite und jeder Seite ausgeführt, die mit blog beginnt.
Dies kann unbeabsichtigte Folgen haben. Sagen wir zum Beispiel, Sie haben eine Seite, die mit "blog" beginnt, aber nicht Teil des eigentlichen Blogs ist, wie https://example.com/blogging-services. Diese würde mit dieser Regel erfasst werden.
Wählen Sie dann im Dropdown-Menü Service den Worker aus.
Wir haben viel Arbeit erledigt, aber es gibt noch mehr Routen, die wir hinzufügen müssen – die CSS-, JavaScript- und anderen Dateipfade, von denen der Blog abhängt (es sei denn, alle Dateien werden auf einer anderen URL gehostet, z. B. auf einem CDN). Eine gute Möglichkeit, diese zu finden, ist, Ihre Route zu testen und die Konsole zu überprüfen.
Gehen Sie zu Ihrer https://example.com/blog und stellen Sie sicher, dass etwas geladen wird. Es wird fehlerhaft aussehen, da die Theme-Dateien fehlen. Das ist vorerst in Ordnung, solange kein 404-Fehler auftritt. Wichtig ist, die Entwicklertools Ihres Browsers zu öffnen, die Konsole zu starten und sich alle roten URLs zu notieren, die nicht gefunden oder geladen werden können (normalerweise eine 404 oder 403) und die Teil Ihrer Domain sind.

Sie möchten diese als Routen hinzufügen… aber nur die übergeordneten Pfade. Wenn Ihre rote URL also https://example.com/wp-content/themes/file1.css lautet, verwenden Sie https://example.com/wp-content* als Ihre Route. Sie können auch einen Unterpfad hinzufügen, wenn Sie spezifischer sein möchten, aber die Idee ist, eine Route zu verwenden, um die meisten Dateien zu erfassen.

Sobald Sie diese Routen hinzugefügt haben, schauen Sie sich Ihre URL an und prüfen Sie, ob sie Ihrer Subdomain ähnelt. Wenn nicht, überprüfen Sie die vorherigen Schritte. (Wahrscheinlich müssen Sie weitere Routen hinzufügen.)
Es ist am besten, eine Qualitätskontrolle durchzuführen, indem Sie mehrere Seiten aufrufen und prüfen, ob etwas fehlt. Ich empfehle auch, die Entwicklertools zu öffnen und nach Ihrer Subdomain (blog.example.com) zu suchen. Wenn diese angezeigt wird, müssen Sie entweder Routen hinzufügen, um diese Ressourcen anzusprechen, *oder* etwas mit Ihrer Plattform tun, um die Ausgabe dieser URLs zu stoppen. Zum Beispiel gab meine Plattform ein kanonisches Tag mit meiner Subdomain aus, also habe ich ein Plugin gefunden, um die kanonische URL auf meine Root-Domain zu ändern.
Schritt 4: Die geheimste aller geheimen Soßen (noindex)
Wir könnten ein Problem feststellen. Unsere URLs sind unter zwei verschiedenen URLs verfügbar. Ja, wir können das canonical-Attribut verwenden, um Google mitzuteilen, welche URL unsere "Haupt"-URL ist, aber wir sollten es Google nicht überlassen, die richtige auszuwählen.
Zuerst, setzen Sie Ihre gesamte Subdomain auf noindex (die Art und Weise, dies zu tun, variiert je nach Plattform). Dann werden wir im Cloudflare Worker die folgende Codezeile hinzufügen, die im Grunde besagt, noindex zu entfernen, wenn die aktuelle URL über den Proxy aufgerufen wird.
newResponse.headers.delete("x-robots-tag");
Die vollständige Code-Lösung wird am Ende dieses Artikels bereitgestellt.
Schritt 5: Die Sitemap ändern
Das Letzte, was zu tun ist, ist die Änderung der Sitemap der Subdomain, damit sie die Subdomain nicht enthält. Die Art und Weise, wie dies geschieht, variiert je nach Plattform, aber das Ziel ist, die Basis-/absolute/Domain in Ihrer Sitemap zu ändern, sodass sie example.com/mypost anzeigt) anstelle von blog.exmaple.com/mypost. Einige Plugins und Module erlauben dies ohne benutzerdefinierten Code.
Das war's! Die Lösung sollte funktionieren!
Einschränkungen
Diese Cloudflare-Magie ist nicht ohne Nachteile. Zum Beispiel akzeptiert sie nur GET-Anfragen, was bedeutet, dass wir nur Dinge vom Server abrufen können. Wir können nicht POSTen, was Formulare verwenden. Wenn Sie also möchten, dass Ihre Besucher sich anmelden oder Formulare absenden, müssen Sie zusätzlich zu dem, was wir bereits getan haben, mehr Arbeit leisten. Mehrere Lösungen dafür habe ich in einem anderen Artikel besprochen.
Wie bereits erwähnt, ist eine weitere Einschränkung, dass die Verwendung dieses Ansatzes auf Shopify die Anmeldung zum Enterprise-Tarif von Cloudflare erfordert. Wieder einmal liegt das daran, dass Shopify auch Cloudflare verwendet und die Möglichkeit, Traffic zu proxen, in seinen anderen Tarifen einschränkt.
Sie könnten auch Probleme bekommen, wenn Sie versuchen, zwei Instanzen derselben Plattformen zusammenzuführen (z. B. wenn Ihre Top-Level-Domain und Ihre Subdomain WordPress verwenden). Aber in einem solchen Fall sollten Sie in der Lage sein, eine Instanz der Plattform zu konsolidieren und zu verwenden.
Vollständige Lösung
Hier ist der Code in seiner ganzen Pracht.
// Listen for every request and respond with our function.
// Note, this will only run on the routes configured in Cloudflare.
addEventListener('fetch', function(event) {
event.respondWith(handleRequest(event.request))
})
// Our function to handle the response.
async function handleRequest(request) {
// Only GET requests work with this proxy.
if (request.method !== 'GET') return MethodNotAllowed(request);
// The URL that is being requested.
const url = new URL(request.url);
// Request "origin URL" aka the real blog instead of what was requested.
// This switches out the absolute URL leaving the relative path unchanged.
const originUrl = url.toString().replace('https://example.com', 'https://blog.example.com');
// The contents of the origin page.
const originPage = await fetch(originUrl);
// Give the response our origin page.
const newResponse = new Response(originPage.body, originPage);
// Remove "noindex" from the origin domain.
newResponse.headers.delete("x-robots-tag");
// Remove Cloudflare cache as it's meant for WordPress.
// If you are using Cloudflare APO and your blog isn't WordPress, (but
// your main domain is), then stop APO from running on your origin URL.
// newResponse.headers.set("cf-edge-cache", "no-cache"); return newResponse;
}
// Hey! GET requests only
function MethodNotAllowed(request) {
return new Response(`Method ${request.method} not allowed.`, {
status: 405,
headers:
{ 'Allow': 'GET' }
})
}
Wenn Sie Hilfe auf dem Weg benötigen, können Sie mich gerne über meine Website CreateToday.io kontaktieren oder sich mein YouTube-Video für eine Video-Demonstration ansehen.
Ich finde, das ist keine elegante genug Lösung. Sie entfernt auch den Deindex-Header von Beiträgen oder Seiten, die ich nicht von Google indexiert haben möchte. Und wenn die Verwaltung dessen im Code erforderlich ist, ist das ein Code-Geruch, da wir den Zustand von Inhalten im CMS verwalten sollten.
Was ist der Grund für die Existenz der Subdomain?
Warum kann Ihre Drupal-Anwendung nicht einfach im Unterverzeichnis liegen, aus dem Sie sie bereitstellen möchten?
Hey John,
Vielen Dank für die Tipps. Die Verwendung von Cloudflare auf diese Weise hilft uns, wie erwartet, unser Problem zu lösen und funktioniert einwandfrei.
Ich denke, die Sorge sollte sein, dass es wie eine Black-Hat-Technik aussieht.
https://www.thesitewizard.com/sitepromotion/cloaked-domain-redirection-issues.shtml
Was denken Sie? Macht das Sinn?
Leider entfernt
newResponse.headers.delete("x-robots-tag");den noindex-Tag auf meiner WordPress-Seite nicht.Für alle, die bei technischen Details hängen bleiben, gibt es jetzt No-Code-Tools, die genau das tun, was in diesem Leitfaden beschrieben wird.
* https://slashblog.co/
* https://pressproxy.io/