Miraclemin/b2b-website-strategy

B2B-Website-Auswahl und SEO für den Außenhandel

Bestehende Websites werden zunächst durch einen realen Besuch diagnostiziert; bei einem Neubau wird zuerst das Geschäftsmodell erfragt. Anschließend werden Technik, Begleitwerkzeuge, SEO und das Anfrage-Management miteinander verknüpft. Ziel ist es, die für die aktuellen Randbedingungen des Kunden am besten geeignete Lösung zu finden – und nicht eine vermeintlich „optimale Technologie“ oder „beste SEO“ zu versprechen, die für alle Fabriken gleichermaßen funktioniert.

Die chinesischen Erklärungen richten sich an Einsteiger: Die Schlussfolgerung steht am Anfang, Fachbegriffe werden bei ihrer ersten Verwendung in einfachen Worten erklärt und mit Beispielen aus der Branche illustriert. Wenn der Kunde mit „Ich weiß nicht“ antwortet, werden verständliche Optionen angeboten, ohne den Kunden zu zwingen, sich zuerst für SSR, eine Datenbank oder ein Framework zu entscheiden. Bei einer bestehenden Plattformpräferenz wird innerhalb dieser Einschränkung optimiert; nur bei konkreten Konflikten wird dies begründet und ein Alternativvorschlag unterbreitet.

Die begleitenden Acht Ebenen, 32 Wissensgruppen und die interaktive Wissenskarte dienen der Erklärung von Konzepten. Die „acht Ebenen“ beziehen sich hier auf acht geschäftsrelevante Entscheidungsebenen; der Binärbaum ist eine Klassifikation von Wissen, die kombiniert werden kann und nicht als Entscheidungsprozess verstanden werden darf, bei dem der Kunde einem einzigen Pfad folgen muss, um andere Technologien auszuschließen. Bei der Erklärung eines bestimmten Konzepts werden nur die relevanten Einträge herangezogen, nicht das gesamte Dokument.

1. Auswahl des Einstiegspfads

A｜Diagnose einer bestehenden Website. Wenn der Nutzer seine eigene Website einreicht und eine Analyse, Überarbeitung oder einen Vergleich anfordert, wird zuerst Website- und Wettbewerber-Analyse gelesen. Die eigene Website und relevante Wettbewerber werden tatsächlich besucht, um eine nachweisbasierte Bewertung des Ist-Zustands, der Lücken und der Umgestaltungsoptionen zu erstellen. Vorhandene Geschäftsinformationen werden wiederverwendet; es werden nur wenige Fragen ergänzt, die die Vergleichsobjekte und Empfehlungen beeinflussen, ohne den Kunden zu zwingen, den gesamten Fragebogen für eine neue Website auszufüllen. Wenn die vom Kunden genannten Wettbewerber nicht ausreichen, werden unter Berücksichtigung von Produkten, Käufern und Marktbedingungen Kandidaten gesucht und die Auswahl begründet.

B｜Planung einer neuen Website. Wenn der Nutzer keine bestehende Website hat oder explizit eine Neukonzeption wünscht, wird das folgende Interview verwendet, um basierend auf den Antworten eine technische und SEO-Lösung zu erarbeiten. Referenz-URLs des Nutzers bedeuten nicht automatisch, dass diese Website diagnostiziert werden soll. Wenn eine bestehende Website gleichzeitig umgestellt werden soll, wird zuerst die Prüfung gemäß A durchgeführt, dann werden die Einschränkungen aus B für die fehlenden Teile ergänzt und die Optionen „Beibehalten / Teilumstellung / Migration“ verglichen.

Im Modus A darf die bereits im Skill erstellte Lösung nicht als Ergebnis eines tatsächlichen Besuchs dargestellt werden; im Modus B dürfen Lehrbeispiele nicht als Tatsachen des Kunden behandelt werden. Beide Einstiegspfade müssen eine konkrete CDN-Konfiguration und andere anwendbare Begleitprojekte liefern.

2. Kurzes Interview, Wiederverwendung bekannter Antworten

Zunächst werden Antworten aus dem aktuellen Gespräch, Kundenunterlagen und autorisierten Projektdateien ausgefüllt, um Wiederholungen zu vermeiden; aus Lehrbeispielen werden keine realen Kundenfakten abgeleitet. Für einen neuen Durchschnittskunden werden maximal die folgenden sieben Kernfragegruppen abgedeckt, pro Runde höchstens drei, in der Regel zuerst die Fragen 1–3, danach werden nur die fehlenden Teile ergänzt, die die Schlussfolgerung ändern könnten. Der Nutzer kann auch alle Antworten auf einmal geben.

1. Was wird verkauft und an wen? Hauptprodukte, Kundentyp, Rolle (Hersteller/Handelsunternehmen) und der überzeugendste echte Vorteil. Beispiel: „Hotelstühle, verkauft an Bauprojekt-Einkäufer, Stoffe nach Maß möglich“.
2. Welche Märkte zuerst? Prioritär Länder, Sprachen und ob jemand Übersetzungen prüfen kann. Es wird zwischen „deutschen Kunden“ und „deutschem Inhalt“ unterschieden; ein Land wird nicht automatisch mit einer einzigen Website gleichgesetzt.
3. Wie kommen die Käufer zum Abschluss? Anfrage nach Einsehen der Unterlagen, oder Anmeldung für vertragliche Preise / Online-Bestellung? Welche Informationen werden für die Anfrage benötigt? Vorhandene Geschäfts-E-Mails, Kundenservice/Chat und CRM-Informationen werden wiederverwendet; bei Bedarf wird nach Servicezeiten, Anhängen oder Konfiguratoren gefragt.
4. Wie viele Inhalte gibt es und wer aktualisiert sie? Anzahl der Produkte/Kategorien/Artikel, Aktualisierungshäufigkeit, technische Fähigkeiten des Redakteurs, vorhandene Bilder, Parameter und Fallstudien. Wenige, einige hundert oder zehntausende sind ausreichend; der Kunde muss nicht bis zur letzten Einheit zählen.
5. Neubau oder Überarbeitung? Vorhandene URL / System, Suchverkehr und Anfragen, Kontrolle über Domain und Account, verfügbare Search Console / Analytics / Keyword-Daten. Bei einer Überarbeitung müssen wichtige alte URLs und geschäftliche Abhängigkeiten bekannt sein.
6. Budget und zeitlicher Rahmen? Grober Umfang der Investition für den Bau, gewünschter Livegang, monatliche Wartungskosten und Verantwortlicher. Unterschieden werden Budget für den Bau, für laufende SEO-Inhalte und für Werbung.
7. Welche Bedingungen müssen erfüllt sein? Plattformpräferenz, Exportierbarkeit von Quellcode/Daten, besondere Deployment- oder Datenanforderungen, Kundenkonten, Angebotsrechner und Integration in bestehende Systeme. Ohne besondere Anforderungen kann dieser Punkt übersprungen werden.

Es ist nicht nötig, alle sieben Fragen mechanisch abzuarbeiten, bevor mit der Arbeit begonnen wird. Wenn die Richtung klar ist, wird zunächst eine Richtung vorgegeben; nur wenn eine unbeantwortete Bedingung die Lösung umkehren würde, wird weitergefragt. Wenn der Nutzer direkt eine Lösung oder eine Demonstration wünscht, werden die notwendigen Annahmen aufgelistet und fortgefahren, ohne Kundenantworten zu erfinden. Wenn der Kunde einige Fragen nicht beantworten kann, wird eine vorläufige Lösung geliefert und die wichtigsten Lücken werden gekennzeichnet.

3. Technische Entscheidungen auf acht Ebenen treffen

Nach der Auswahlentscheidung und Acht-Ebenen-Vorlage werden die Routen verglichen. In der Regel wird eine Hauptlösung und eine wettbewerbsfähigste Alternative angegeben, wobei die Auswahlkriterien, Abwägungen und die Bedingungen, unter denen die Alternative besser geeignet wäre, klar dargelegt werden; es werden nicht alle Plattformen in einer Werkzeugliste aufgeführt, noch wird eine unbegründete Bewertung zur Erzeugung von Scheingenauigkeit verwendet.

Die acht Ebenen sind: ① Geschäfts- und Website-Route; ② Inhalt und Daten; ③ Frontend und Interaktion; ④ Rendering und Caching; ⑤ Deployment und Leistung; ⑥ SEO und Mehrsprachigkeit; ⑦ Anfragen und Attribution; ⑧ Sicherheit und Wartung.

Pro Ebene wird angegeben: „Was wird gewählt – Warum – Kundenszenario – Abhängigkeiten/Kosten“. Gleichzeitig wird geprüft, ob die gesamte Kombination funktioniert: ob die Laufzeitumgebung beispielsweise ISR des gewählten Frameworks unterstützt, ob WordPress PHP/Datenbank benötigt, wer für die Inhaltsaktualisierung und Fehlerbenachrichtigungen verantwortlich ist.

Kritische Abgrenzungen:

• CMS/SaaS sind Inhalts- oder Hosting-Fähigkeiten, Headless ist eine Trennung von Frontend und Backend, Frameworks sind Entwicklungswerkzeuge, SSR usw. sind Rendering-Strategien, CDN ist eine Auslieferungsinfrastruktur; sie befinden sich nicht auf derselben Ebene.
• WordPress wird nicht als standardmäßiger Gewinner gesetzt. Betriebsredakteure und Standardanfragen können dafür geeignet sein; geringe Inhaltsmengen und Entwicklungswartung können für eine statische Lösung passen; komplexe Konten/Konfiguratoren könnten eher für ein Anwendungsframework sprechen; standardisierte Transaktionsabläufe können mit E-Commerce-Plattformen verglichen werden.
• Wenn der Kunde KI-Website-Builder erwähnt, wird zwischen der Generierung von erstem Code/Seiten und den laufenden Betriebskosten unterschieden. KI kann die Anpassung von WordPress-Themes, visuelle Tools und die Framework-Entwicklung unterstützen; daraus wird nicht abgeleitet, dass Next.js zwangsläufig besser geeignet ist oder dass die bestehende Website migriert werden muss. Die Wiederverwendung von Code/Komponenten ist eine normale Ingenieurspraxis; es sollte geprüft werden, ob verschiedene Produkte über geeignete Inhaltsfelder und Beschaffungsprozesse verfügen, anstatt nur ein unterschiedliches Erscheinungsbild pro Seite anzustreben.
• Statische Inhalte erzwingen nicht SSG; ein Formular erfordert nicht zwangsläufig SSR auf der gesamten Website; die Verwendung von React im Frontend bedeutet nicht, dass die gesamte Website nur CSR verwendet.
• Das Rendering wird pro Seite oder Bereich gewählt. Es wird erklärt, wann die erste Version erstellt wird, wie Cache-Treffer/-Fehlschläge behandelt werden, wie veröffentlichte Inhalte aktualisiert werden und wie private Daten isoliert werden. Das vollständige Seitencaching von WordPress und das ISR-Verhalten können ähnlich sein, sollten aber nicht gleichgesetzt werden; ISR ist auch nicht unbedingt ein Cron-Job.
• Hosting-Preise, Plugin-Funktionen, Paketbeschränkungen und die Framework-Deployment-Unterstützung werden nicht aus dem Gedächtnis als aktuelle Fakten dargestellt; sie werden in der offiziellen Dokumentation des Anbieters überprüft, wobei Quelle und Abfragedatum notiert werden. Wenn eine Überprüfung nicht möglich ist, werden Kandidaten-/Prüf-Beschreibungen verwendet, ohne Preise zu erfinden.
• CDN und Ursprungsserver werden getrennt gewählt. WordPress benötigt dennoch eine Hosting-Umgebung für PHP/Datenbank; die Verwendung eines CDN erzwingt nicht, dass der Ursprungsserver in Europa steht, und befreit auch nicht automatisch von der Entfernung zum Ursprungsserver. Nach Cache-Treffer, -Fehlschlag, dynamischen Anfragen, Position der Hauptkäufer und Wartungspersonal werden die Regionen verglichen; die europäischen Rechenzentren aus dem vorherigen Beispiel werden nicht als harte Anforderung betrachtet. Im Hosting-Paket enthaltene Funktionen müssen nicht doppelt erworben werden.

4. Plugins, Dienste und Konfiguration umsetzen

Plugins, E-Mail und Kundenservice-Begleiter lesen und die konkrete Begleitliste gemäß der gewählten Plattform ausliefern. Folgendes muss abgedeckt werden: Speicherung von Anfragen, Versenden von E-Mails durch die Website, geschäftliche E-Mail-Postfächer und Antworten, ob ein Live-Chat benötigt wird, SEO/Mehrsprachigkeit, Caching/CDN, Backups und Analysen. Für jeden Punkt werden die erforderliche Fähigkeit oder optionale Erweiterungen, Kandidaten/ausgewählte Werkzeuge, Begründung, wichtige Konfiguration, Kontoinhaberschaft, Kostenrahmen, Abnahme und Überprüfungsstatus angegeben.

Wenn der Kunde bestimmte Produkte wie Tidio erwähnt, werden diese in den Vergleich und die Lösung einbezogen, nicht nur „Live-Chat anschließen“. Ebenso wird die E-Mail-Konfiguration nicht auf „SMTP-Plugin installieren“ reduziert: Die Rollen von geschäftlichem E-Mail-Postfach, Website-SMTP/API-Versandkanal und Domain-Validierung werden klar getrennt. Nicht benötigte Fähigkeiten werden für diesen Durchlauf als zurückgestellt gekennzeichnet; Funktionen, die nativ oder durch das Hosting abgedeckt sind, werden nicht doppelt installiert.

Jede Lösung muss eine separate CDN-Auswahl-, Anschluss- und Cache-Konfigurationstabelle enthalten, für die die CDN-Lösungsspezifikation gelesen wird. Es müssen der Anbieter/Paket-Grund, der Ursprungsserver und die Anschlussdomain, die DNS/Proxy- oder Ressourcen-Domain-Verbindungsmethode, TLS, konkrete Match-Bedingungen, Edge/Browser-Cache-Zeiten, Bypass-Bedingungen, Cache-Keys, Regelreihenfolge, Cache-Löschung bei Veröffentlichung, Fallback und Abnahme angegeben werden. Es wird nicht akzeptiert, nur „Cloudflare/CDN konfigurieren“ zu schreiben; bei Verwendung eines integrierten CDN des Hostings muss der steuerbare Umfang angegeben werden. Wenn kein zusätzliches CDN aktiviert wird, wird der Grund und die Verantwortung für die Auslieferung genannt, ohne eine Lücke zu hinterlassen.

5. SEO- und Anfrage-Lösung mit Nachweisen erstellen

Gemäß der SEO-Lösungs- und Nachweisspezifikation erstellen. Zuerst wird zwischen Kundenfakten, tatsächlicher Recherche und zu verifizierenden Hypothesen unterschieden, dann wird festgelegt, welche Beschaffungsanforderungen durch Kategorieseiten, Produktseiten, Anwendungsseiten oder Artikel abgedeckt werden sollen.

Wenn eine Internetverbindung besteht, werden die relevanten offiziellen Google-Richtlinien und die Fähigkeiten der Anbieter überprüft und für einige wenige wichtige Beschaffungsanforderungen und vom Nutzer bereitgestellte Wettbewerber eine der Entscheidung angemessene Recherche durchgeführt. Das Zielland/die Zielsprache und der tatsächliche Recherche-Umfang werden dokumentiert; gewöhnliche Suchen werden nicht als präzise SERPs für eine bestimmte Region ausgegeben, noch wird behauptet, eine nicht geöffnete Seite gesehen zu haben. Ohne Website/Keyword-Liste wird dennoch ein brauchbarer erster Entwurf geliefert: Kandidaten-Keywords werden klar gekennzeichnet, Suchvolumen/Schwierigkeit/Traffic bleiben leer oder als „zu prüfen“, ohne Werte zu erfinden.

Es werden nur ausreichende Daten für die aktuelle Entscheidungsrunde gesammelt; der Kunde wird nicht gezwungen, Tools zu kaufen, einen zehntausend Keyword-Liste zu exportieren oder eine feste Anzahl von Wettbewerbern zu sammeln. Wenn bereits eine detaillierte Keyword-Liste und Ranking-URLs vorliegen und der Kunde eine tiefergehende Seitenstrukturanalyse wünscht, kann auf das installierte $b2b-seo-site-architecture verwiesen werden; dieses Skill muss jedoch in der Lage sein, die Technologieauswahl und den SEO-Erstentwurf unabhängig auszuliefern.

6. Diskutierbare und umsetzbare Ergebnisse liefern

Zunächst werden die Schlussfolgerungen im Chat präsentiert. Abhängig vom Projektumfang werden die folgenden Inhalte geliefert, ohne leere Abschnitte nur zum Füllen der Vorlage hinzuzufügen:

1. Kurzzusammenfassung und Modus: Ziele, Einschränkungen, Bekanntes/Annahmen/Fehlendes; klar als Diagnose einer bestehenden Website, Neukonzeptionsentwurf oder Lehrbeispiel gekennzeichnet.
2. Ist-Zustand und Wettbewerbslücken (nur bei Modus A): Tatsächlicher Besuchsumfang, technischer Ist-Zustand auf acht Ebenen, Tabelle mit Funktions- und Plugin-Hinweisen; unterschieden werden bestätigte Beobachtungen, Vermutungen, nicht Gefundenes und nicht Bewertbares; es werden nachzurüstende Funktionen mit Priorität aufgelistet.
3. Empfehlung und Alternative: Acht-Ebenen-Auswahltabelle mit Erläuterung der Abwägungen; bei Modus A werden Beibehalten/Teilumstellung/Migration verglichen, wobei alte URLs und funktionierende Anfrageprozesse geschützt werden. Kosten werden nur aufgeführt, wenn es eine Budgetgrundlage gibt, und es wird zwischen Einmal- und laufenden Kosten unterschieden.
4. Plugin- und Dienstkonfigurationsliste: Gemäß der Begleitspezifikation werden umsetzbare Auswahlen und Konfigurationen gegeben, ohne „geplant“ als „installiert, verifiziert“ zu schreiben; Lizenz-/Dienstkosten und Wartungsverantwortung sind enthalten.
5. CDN-Auswahl- und Regeltabelle: Gemäß der CDN-Spezifikation werden konkrete Anschlüsse, Cache-/Bypass-Bedingungen, TTL, Cache-Keys und Prioritäten, Aktualisierung/Fallback, Verifikationsergebnisse oder Abnahmeschritte angegeben; unbekannte Werte werden als Annahmen klar gekennzeichnet, mit umsetzbaren vorläufigen Werten und Begründung.
6. SEO-Seiten-Blueprint: Strukturbaum der Kernseiten und Seitentabelle mit Zielkäufer, Bedarf/Kandidaten-Keywords, URL, Seitentyp, Inhaltsnachweisen, CTA, Priorität und Recherchestatus. Chinesische Erklärungen; Seitenname/URL-Beispiele für englischsprachige Websites bleiben auf Englisch; Artikelplan wird separat aufgeführt.
7. Betriebsschema: Inhaltsbearbeitung → Seitenaktualisierung; Besucher → CDN/Ursprungsserver-Auslieferung; Anfrage absenden → speichern → E-Mail versenden → Geschäftspostfach → Antwort/Follow-up; Chat-Abzweigungen erklären die Online- und Offline-Verarbeitung.
8. Ausführungsreihenfolge und Abnahme: Nach Abhängigkeiten angeordnet, kann als 30/60/90-Tage-Arbeitsplan dargestellt werden, ohne Daten als Ranglisten-/Anfrageversprechen zu setzen. Abdeckung der Sichtbarkeit in der Suche, Kernvorlagen, Sprachen, Leistung und echte Anfragekette.
9. Verifikationsgrenzen und nächste Schritte: Die wenigen Lücken, die die Entscheidung am meisten beeinflussen könnten, sowie Methoden zur Datenergänzung, Quelle und Abfragedatum auflisten. Bei Modus A wird erklärt, dass die alleinige Betrachtung der Webseite von der tatsächlichen Backend-Situation abweichen kann; es wird klar angegeben, was einer Bestätigung durch das Backend oder den Verantwortlichen bedarf.

Wenn der Nutzer keine Dateien anfordert, wird die Ausgabe bevorzugt direkt geliefert, ohne automatisch Websites zu erstellen, Dienste zu kaufen, DNS zu ändern, Nachrichten zu senden, Formulare abzuschicken, Seiten zu veröffentlichen oder bestehende Websites zu ändern. Der Bau der Website, die SEO-Umsetzung oder Veröffentlichung erfolgt gemäß der späteren Autorisierung des Nutzers; Recherche wird nicht als Freigabe für den Livegang dargestellt.

Beispiele und Abnahme

Wenn der Nutzer Beispiele sehen oder die Form der Ausgabe verstehen möchte, wird das Vollständige Beispiel einer Möbelfabrik gelesen. Kunden, Budgets, Felder und Keywords im Beispiel sind Demonstrationszwecke und dürfen nicht als echte Kundendaten oder verifizierte Forschungsergebnisse behandelt werden.

Vor Abschluss prüfen: Wurde bei A tatsächlich ein Besuch durchgeführt und liegen Seitenbelege vor? Sind Plugin-Schlussfolgerungen ehrlich? Wurde bei B von den Kundenantworten abgeleitet? Wurden Plattformpräferenzen und bestehende Websites berücksichtigt? Hat das CDN eine Anschluss- und Regeltabelle und nicht nur einen Markennamen? Sind der Seitenaktualisierungs- und Anfrageprozess klar? Wird zwischen Vorlagen/Seitenanzahl unterschieden? Bleiben unbekannte Daten und Zertifikatsfälle unbekannt? Ist klar, unter welchen neuen Bedingungen die Hauptlösung neu bewertet werden müsste?