Funktioniert Builder.io in China? Content-Auslieferung, ICP & die PIPL-Linie
Builder.io ist ein headless visuelles CMS, das Ihre Inhalte und Seiten-Designs von einem Offshore-CDN-Edge (Google Cloud, AWS CloudFront und Fastly) ohne Point of Presence in Festlandchina ausliefert — sie live aus China zu holen, ist also ein Auslieferungsrisiko —, während die ICP-Beian und die PIPL-Pflichten, die über die Rechtmäßigkeit entscheiden, auf der Site sitzen, die Builder.io einbettet, nicht auf dem CMS. Ein ehrlicher, Compliance-zuerst-Blick.
Funktioniert Builder.io in China?
Es hängt davon ab, welche Hälfte der Frage Sie meinen, und die zwei Hälften antworten verschieden. Builder.io ist aus Festlandchina erreichbar, aber es liefert Ihre Inhalte und Designs von einem Offshore-CDN-Edge aus — das ehrliche Risiko auf Builder.io-Ebene ist also zuverlässige Auslieferung, nicht Datenresidenz. Die ICP-Beian und die PIPL-Pflichten, die tatsächlich über die Rechtmäßigkeit entscheiden, sitzen auf der Site, die Builder.io einbettet, nicht auf dem CMS.
Builder.ios eigene Dokumentation sagt „Builder Content serves content from the CDN edge cache while revalidating in the background“, bedient vom Content-Endpunkt cdn.builder.io, und Builder beschreibt diesen Stack als „AWS CloudFront as our CDN“ mit „Fastly as a secondary caching layer“, auf einer Plattform, die „Architected to run natively on Google Cloud across all regions“ ist — nichts davon bedient das Festland von innerhalb. Eine Seite, die Inhalte zur Anfragezeit abruft, überquert also bei jedem Aufruf die Grenze: ein Erreichbarkeitsrisiko, aber für sich allein kein Grenztransfer der personenbezogenen Daten Ihrer Nutzer, denn die Payload sind Ihre eigenen redaktionellen Inhalte und Designs. Die Pflichten, die über die Rechtmäßigkeit entscheiden — eine ICP-Beian auf inländischem Hosting und PIPL für alle personenbezogenen Daten, die Ihre Site erhebt —, hängen an Ihrer einbettenden Site, nicht an Builder.io. Die Tabelle unten ist Builder.ios eigener Wortlaut und die Linie, auf der jeder Fakt sitzt.
Dies ist eine Risikokarte, kein Urteil — welche Pflichten gelten, hängt davon ab, wie Ihre Site gehostet ist, was sie erhebt und wer Ihre Nutzer sind. Unser China-Team kann Ihre Exponierung mit Ihnen kartieren →
Compliance-Momentaufnahme
- ! Builder.ios Content-CDN ist offshore — erreichbar, aber jeder Abruf überquert die Grenze
- ✓ Die Payload sind Ihre eigenen Inhalte und Designs, nicht die personenbezogenen Daten Ihrer Nutzer
- ✕ Eine öffentliche Site, die von außerhalb des Festlands bedient wird, kann nicht ICP-gemeldet werden
- ! Die ICP-Beian und die PIPL-Pflichten sitzen auf Ihrer einbettenden Site, nicht auf dem CMS
- ! Legen Sie personenbezogene Daten in ein Builder-Feld, und sie verlassen das Festland bei jedem Abruf
Was die offizielle Builder.Io-Dokumentation über China sagt
| Fakt | Primärquelle |
|---|---|
Builder.io ist ein headless, visuelles CMS: Ihre Site holt ihre Inhalte zur Anfragezeit von Builders CDN-Edge. Builders Content-API-Dokumentation gibt an, dass „Builder Content serves content from the CDN edge cache while revalidating in the background“, wobei Ihr Frontend den Endpunkt https://cdn.builder.io/api/v3/content/ für jedes Modell aufruft. Das ist das Auslieferungsmodell — und es ist die Hälfte von „funktioniert es in China“, die an der Erreichbarkeit hängt, nicht am Recht. | Builder.io — Content API documentation (builder.io/c/docs/content-api), abgerufen 2026-10-07 |
| Dieser CDN-Edge ist vollständig offshore, ohne Point of Presence innerhalb Festlandchinas. Builder.ios eigenes Personal beschreibt den Auslieferungs-Stack als „AWS CloudFront as our CDN“ mit „Fastly as a secondary caching layer“, mit Bildern gespeichert auf „a US-based Google Cloud Platform Bucket“, und Builders Newsroom von 2025 sagt, die Plattform sei „Architected to run natively on Google Cloud across all regions“ auf „Google Cloud's global infrastructure“. Google Cloud betreibt keine Festlandchina-Region, und weder CloudFronts noch Fastlys globales Standard-Netzwerk bedient das Festland von innerhalb — ein Abruf hinter der Großen Firewall reist also hinaus und zurück. Es ist ein Auslieferungsrisiko, keine Sperre. | Builder.io — Google Cloud Marketplace announcement (builder.io/news/google-cloud-marketplace) & official community forum (forum.builder.io), abgerufen 2026-10-07 |
| Für sich allein ist Builder.io kein Grenztransfer der Daten Ihrer Nutzer. Was Builder speichert und ausliefert, sind Ihre eigenen redaktionellen Inhalte und Seiten-Designs — das Material, das Ihr Team für die öffentliche Anzeige verfasst —, nicht die personenbezogenen Daten der Menschen, die es ansehen. Das durch Builders US-basierte Google-Cloud- und AWS-Infrastruktur zu bewegen, erzeugt für sich allein keinen Grenztransfer von Nutzerdaten nach PIPL (Art. 38–43). Die eine Ausnahme ist selbstverschuldet: Modellieren Sie personenbezogene Daten als Inhalt innerhalb eines Builder-Felds, und sie verlassen das Festland bei jedem Abruf wie jede andere Payload. | Builder.io — Content API documentation (builder.io/c/docs/content-api), abgerufen 2026-10-07; PIPL Art. 38–43 |
| Die Pflichten, die über die Rechtmäßigkeit entscheiden, sitzen auf der Site, die Builder.io einbettet, nicht auf dem CMS. Eine öffentliche Site, die Festland-Besuchern gezeigt wird, braucht eine ICP-Beian (ICP 备案) auf inländischem Hosting nach Staatsratserlass Nr. 292 und MIIT-Erlass Nr. 33 — entschieden davon, von wo Ihr HTML und Ihr Origin bedient werden, nicht wo Ihr CMS lebt. Separat: Jede personenbezogene Information, die Ihre Site erhebt, ist Ihre eigene PIPL-Verantwortung als Verarbeiter: Mitteilung, gesonderte Einwilligung und ein Transfermechanismus, wenn sie offshore geht (Art. 38–43), und inländische Speicherung für einen Betreiber kritischer Informationsinfrastruktur oder Verarbeiter großer Mengen (PIPL Art. 40; Cybersicherheitsgesetz Art. 39 (vormals Art. 37)). | Staatsratserlass Nr. 292; MIIT-Erlass Nr. 33; PIPL Art. 38–43 & 40; Cybersicherheitsgesetz Art. 39 (vormals Art. 37) (Cyberspace Administration of China), abgerufen 2026-10-07 |
Quellen vom 21YunBox Compliance-Team am 7. Oktober 2026 geprüft.
Für ein Festland-China-Publikum sind bei „Funktioniert Builder.io“ in Wahrheit zwei Fragen in einen Mantel gesteckt, und sie auseinanderzuhalten ist, was die Antwort nützlich macht. Builder.io ist ein headless, visuelles CMS: Es speichert Ihre Inhalte und Ihre Seiten-Designs und reicht sie Ihrer Site über eine Content-API, die von seinem eigenen CDN-Edge bedient wird. Dieser Edge läuft auf Offshore-Infrastruktur ohne Point of Presence innerhalb Festlandchinas, das ehrliche Risiko auf Builder.io-Ebene ist also Erreichbarkeit — eine Site, die ihre Inhalte live hinter der Großen Firewall abruft, kann langsam oder unzuverlässig sein. Was Builder.io für sich allein nicht tut, ist, Ihr Projekt in ein Datenresidenz-Problem zu verwandeln, denn was es trägt, ist das Material, das Sie veröffentlichen, nicht die personenbezogenen Daten der Menschen, die es lesen. Die Melde- und Datenschutz-Pflichten, die tatsächlich entscheiden, ob Ihre auf China ausgerichtete Site rechtmäßig ist, sitzen auf der Site, die Builder.io einbettet — und diese von der Auslieferungsfrage zu trennen, ist die ganze Aufgabe dieser Seite.
Builder.io in China auf einen Blick
| Worüber es entscheidet | In Builder.ios eigenen Worten |
|---|---|
| Wo es läuft | Builders Plattform ist „Architected to run natively on Google Cloud across all regions“ auf „Google Cloud's global infrastructure“, und sein Content-Stack nutzt „AWS CloudFront as our CDN“ mit „Fastly as a secondary caching layer“. Keines dieser Netzwerke läuft innerhalb Festlandchinas. |
| Wie Ihre Site Inhalte bekommt | Ihr Frontend fragt Builders Content-API auf dem Host cdn.builder.io zur Anfragezeit ab; „Builder Content serves content from the CDN edge cache“. Ohne Festland-Point-of-Presence überquert jeder Abruf die Grenze. |
| Was in der Payload steckt | Ihre eigenen Inhalte und Seiten-Designs — Seiten, Layouts, Texte, Bilder —, verfasst für die öffentliche Anzeige, nicht die personenbezogenen Daten Ihrer Endnutzer. Für sich allein ist das im Allgemeinen kein PIPL-Grenztransfer von Nutzerdaten. |
| Die Öffentlichkeit bedienen | Die öffentliche Site, die Builder.io einbettet und Festland-Besuchern gezeigt wird, braucht eine ICP-Beian auf inländischem Hosting. Diese Pflicht gehört der Site und ihrem Host, nicht dem CMS. |
| Der Grenzfall | Modellieren Sie personenbezogene Daten als Inhalt innerhalb von Builder, und sie verlassen das Festland mit jedem Abruf — und PIPLs Grenzübertritts-Regeln heften sich daran wie an jede andere Payload. |
Erreichbarkeit ist die ehrliche Frage auf Builder.io-Ebene
Builder.io ist offen darüber, wie Ihre Inhalte reisen. Seine Content-API-Dokumentation sagt, dass „Builder Content serves content from the CDN edge cache while revalidating in the background“, wobei Ihr Frontend den Content-Endpunkt cdn.builder.io für jedes Modell aufruft, das Sie anfragen. Wo dieser Edge physisch sitzt, ist die ganze Erreichbarkeits-Geschichte: Builders eigenes Personal beschreibt den Auslieferungs-Stack als „AWS CloudFront as our CDN“ mit „Fastly as a secondary caching layer“, mit Bildern gespeichert auf „a US-based Google Cloud Platform Bucket“, und Builders Newsroom von 2025 sagt, die Plattform sei „Architected to run natively on Google Cloud across all regions“ auf „Google Cloud’s global infrastructure“. Jedes dieser Netzwerke bedient das Festland von der fernen Seite der Grenze — keines betreibt einen Point of Presence darin —, eine Anfrage aus Peking oder Guangzhou muss also das Land verlassen und zurückkommen, um Builders Edge zu erreichen. Dieser Hin- und Rückweg, und die Filterung unterwegs, ist, woher die langsamen Renders und der gelegentlich gescheiterte Abruf kommen. Es ist ein echtes Auslieferungsrisiko, und es ist auch die Hälfte der Frage, die Netzwerk-Design tatsächlich beheben kann. Lesen Sie es als Erreichbarkeit, nicht als Urteil über die Rechtmäßigkeit.
Ein visuelles CMS ist für sich allein kein Datenresidenz-Problem
Es ist leicht, „our CMS runs on US infrastructure“ zu sehen und direkt zum Grenzdaten-Alarm zu greifen. Für ein Content-und-Design-CMS ist das meist das falsche Instrument. Was Builder.io hält und ausliefert, ist das Material, das Ihr Team für die Öffentlichkeit baut — Marketingseiten, Layouts, Texte, Bilder, wiederverwendbare Design-Blöcke —, nicht die personenbezogenen Daten der Menschen, die sie ansehen. Das durch Builders Google-Cloud- und AWS-Backend zu bewegen, ist für sich allein kein Grenztransfer von Nutzerdaten nach PIPL. Das klar zu sagen, ist wichtig: Blähen Sie ein visuelles CMS zu einem Datenresidenz-Verstoß auf, erzeugen Sie eine Pflicht, die es nie auslöste, während die Pflichten, die real sind, aus dem Blick geraten.
Es gibt einen einzigen Grenzfall, der Beachtung verdient. Builder.io speichert, was immer Sie als Inhalt zu modellieren wählen, in dem Moment also, in dem Sie personenbezogene Daten — ein Nutzerprofil, einen Formulareintrag, alles, was eine reale Person identifiziert — in ein Builder-Feld legen, überquert dieser Datensatz nun mit jedem Abruf die Grenze, genau wie eine Landing-Page, und PIPLs Grenzübertritts-Regeln (Art. 38–43) heften sich daran. Die Disziplin ist einfach: Behalten Sie Builder.io für Inhalt und Design, behalten Sie personenbezogene Daten in Systemen, die Sie kontrollieren, und die Residenzfrage landet nie auf dem CMS.
Die Compliance-Türen leben auf Ihrer Site, nicht auf dem Builder
Die Pflichten, die entscheiden, ob Ihre auf China ausgerichtete Site rechtmäßig ist, ruhen nicht auf Builder.io; sie ruhen auf der Website, die es einbettet. Eine öffentliche Site, die Festland-Besuchern gezeigt wird, braucht eine ICP-Beian (ICP 备案) nach Staatsratserlass Nr. 292 und MIIT-Erlass Nr. 33, und diese Beian muss an Hosting physisch innerhalb des Festlands gebunden sein. Was es entscheidet, ist, von wo Ihr HTML und Ihr Origin bedient werden — nicht wo Ihr CMS lebt —, ein in Builder.io zusammengesetztes Frontend braucht also weiterhin sein eigenes inländisches, ICP-gemeldetes Hosting, um für chinesische Nutzer sauber zu laufen. Separat: Jede personenbezogene Information, die Ihre Site von diesen Nutzern erhebt — Anmeldungen, Bestellungen, Support-Anfragen —, ist Ihre als Verarbeiter zu verantworten: Mitteilung, gesonderte Einwilligung und ein Transfermechanismus, wenn diese Daten offshore gehen (Art. 38–43), und inländische Speicherung, wenn Sie ein Betreiber kritischer Informationsinfrastruktur oder Verarbeiter großer Mengen sind (PIPL Art. 40; Cybersicherheitsgesetz Art. 39 (vormals Art. 37)). Nichts davon ist Builder.ios zu tragen, und nichts davon wird gelöst, indem Ihre Seiten schneller ankommen.
Dies ist eine Risikokarte, kein Urteil: Ob Ihre Site eine ICP-Beian, inländische Speicherung oder schlicht einen stetigeren Weg zu Builder.io braucht, hängt davon ab, wie Sie sie hosten, welche personenbezogenen Daten sie erhebt und wer Ihre Nutzer sind — es lohnt, es mit Rechtsbeistand zu klären, bevor Sie bauen.
Wo 21YunBox hineinpasst — eine rechtskonforme Overlay, keine Migration
Sie bauen weiter in Builder.io, genau wie heute. Was wir hinzufügen, ist das Stück, das eine Offshore-Content-API nicht kann: rechtskonforme, ICP-gemeldete Auslieferung aus dem Festland heraus, vor Ihren bestehenden Origin gesetzt, sodass Ihre Seiten chinesische Nutzer erreichen, ohne auf einen Grenz-Hin-und-Rückweg zu Builders Edge zu warten — ohne Neuaufbau, ohne zweite Codebasis und ohne Änderung an Ihrem Builder.io-Workflow. Unser China-Team nimmt die zwei Hälften einzeln: wie zuverlässig Ihre Inhalte ankommen, und die ICP- und PIPL-Pflichten, die auf Ihrer einbettenden Site sitzen, abgewogen gegen Ihre Gesellschaft, Ihr Hosting und die personenbezogenen Daten, die Ihre Site tatsächlich erhebt. Builder.io bleibt Ihr CMS; die rechtskonforme China-Präsenz wird darum herum gebaut.
Compliance-Einschätzung anfordern →
Weiterführend:
Häufige Fragen
Ist Builder.io in Festlandchina gesperrt oder nur langsam?
Es ist ein Erreichbarkeitsproblem, keine Sperre. Builder.io liefert Ihre Inhalte von einem Offshore-CDN-Edge — CloudFront, Fastly und Google Cloud — ohne Point of Presence innerhalb Festlandchinas, eine Seite, die Inhalte live hinter der Großen Firewall abruft, muss also einen Grenz-Hin-und-Rückweg machen, was sich als langsame Renders und der gelegentlich gescheiterte Ladevorgang zeigt statt als glattes Verbot. Das ist die Hälfte der Frage, die Netzwerk-Design angehen kann, und sie ist getrennt davon, ob Sie zum Betrieb freigegeben sind — was eine Lizenzierungs- und Datenschutzfrage ist, keine Geschwindigkeitsfrage.
Bewegt es die personenbezogenen Daten unserer Nutzer aus China heraus, unsere Site auf Builder.io zu legen?
Im Allgemeinen nicht für sich allein. Builder.io speichert und liefert Ihre redaktionellen Inhalte und Designs, nicht die personenbezogenen Daten der Menschen, die sie lesen, es zu nutzen, ist also für sich allein kein Grenztransfer von Nutzerdaten nach PIPL. Die Ausnahme ist, wenn Sie personenbezogene Daten als Inhalt innerhalb eines Builder-Felds modellieren — dann überqueren sie die Grenze bei jedem Abruf wie jede andere Payload. Die personenbezogenen Daten, die PIPL-Pflichten tragen, sind alles, was Ihre eigene Site erhebt — Konten, Formulare, Bestellungen —, wo immer Sie es verarbeiten.
Kann 21YunBox helfen, unsere Builder.io-Site in Festlandchina zum Laufen zu bringen?
Ja. Unser China-Team trennt die zwei Hälften für Sie — die Erreichbarkeit Ihrer Builder.io-Inhalte und die ICP-Beian und die PIPL-Pflichten, die auf Ihrer einbettenden Site sitzen — und setzt dann eine rechtskonforme, ICP-gemeldete, inländische Auslieferung vor Ihren bestehenden Origin, während Ihr Builder.io-Workflow genau so bleibt, wie er ist. Nehmen Sie Kontakt auf, um Ihr konkretes Setup durchzugehen.
