Leitfaden zur Kartenveröffentlichung

Bei der Kartenveröffentlichung wird eine bearbeitbare Karte zu einer stabilen Anwendung, die andere öffnen, einbetten oder in einem Produkt nutzen können. Die wichtigsten Optionen sind ein eigenständiger Freigabelink, ein eingebetteter Viewer oder eine tiefere Anwendungsintegration. Eine produktive Karte benötigt außerdem Zugriffsregeln, erlaubte Embed-Domains, eine Live-Version, ein mobiles Layout, Verfahren für Rollout und Aufhebung der Veröffentlichung sowie Messung – nicht nur eine URL.

Die folgenden Abschnitte behandeln Veröffentlichungsmodelle, Zugriffs- und Domainkontrollen, Embed-Layout, Messaging, Versionierung, Analysen sowie die Oberflächen von Kaleidr Studio und Viewer. Produktinformationen finden Sie unter Kaleidr Studio. Zur Einbettung siehe So betten Sie eine interaktive Karte ein. Zur Zuständigkeit von Builder und API siehe No-Code Map Builder vs. Map API. Zu SDK-Mounts siehe Was ist ein AI Map SDK?.

Grundlagen der Veröffentlichung

• Erstellung ≠ Veröffentlichung: Entwürfe dürfen sich ändern; veröffentlichte Karten brauchen eine stabile Nutzungsoberfläche.
• Kopplung wählen: Freigabelinks bleiben schlank, Embeds liegen in einer Seite und Produktintegrationen teilen Anwendungszustand.
• Host absichern: Erlaubte Domains und Origin-Prüfungen gehören zum Veröffentlichungsvertrag.
• Platz reservieren: Ein zusammengefallenes Embed ist ein Layoutfehler, kein Kartenfehler.
• Hinter einer stabilen ID versionieren: Messen, prüfen, veröffentlichen und zurückrollen, ohne jede Hostseite umzuschreiben.

Was bedeutet Kartenveröffentlichung?

Eine Karte zu erstellen und sie zu veröffentlichen sind unterschiedliche Phasen. Während der Erstellung kann ein Team Orte, Ebenen, Beschriftungen, Farben, Kacheln, Kamera, Filter, Interaktionen und Datenquellen ändern. Die Veröffentlichung schafft eine Nutzungsoberfläche: eine eigenständige Seite, ein Website-Embed, einen SaaS-Standortfinder, eine redaktionelle Karte oder eine interne schreibgeschützte Ansicht. Ein Autorenwerkzeug kann Entwürfe tolerieren. Eine veröffentlichte Karte braucht vorhersehbaren Zugriff, Layout, Performance, Verhalten, Versionierung, Quellenangaben und Monitoring. Kaleidr Studio beschreibt die Erstellung derzeit als Prompt → Process → Refine → Deploy und gibt an, dass fertige Karten als eigenständige Seiten veröffentlicht oder als Widgets eingebettet werden können (Studio).

Sollten Teams eine veröffentlichte Karte teilen, einbetten oder integrieren?

Drei Modelle decken die meisten Einführungen ab. Ein Freigabelink ist für Prüfungen, Kampagnen und Leitfäden am schnellsten, weil die Hostwebsite fast keine Implementierung benötigt. Ein eingebetteter Viewer eignet sich für Websites, Landingpages, CMS-Seiten und Kundenportale, wenn die Karte neben Text und Handlungsaufforderung erscheinen soll. Die Produktintegration ist für SaaS, Marktplätze und individuelle Workflows gedacht, bei denen Filter, ausgewählte Datensätze und Anwendungszustand mit der Karte synchron bleiben. Die Wahl hängt davon ab, ob die Karte primär Inhalt, eingebettetes Erlebnis oder Teil des Anwendungszustands ist. Eine Karte kann als Freigabelink starten und später zum Embed oder zur Produktkomponente werden.

Kaleidrs aktuelle Entwicklerdokumentation beschreibt veröffentlichte Viewer-Karten als durch Freigabelinks geschützt und über eine Freigabe-ID statt über einen allgemeinen API-Schlüssel adressiert (Viewer Embed). Eine Share-ID identifiziert ein veröffentlichtes Erlebnis; sie ist kein Servergeheimnis und darf nicht als solches behandelt werden. Studio gibt derzeit an, dass Karten nach der Veröffentlichung als Widgets eingebettet werden können. Chat kann an eine vorhandene Hostkarte angehängt werden, während Viewer auf ein veröffentlichtes Kartenerlebnis ausgelegt ist (kaleidr.js).

Wie sollten produktive Embeds Layout, Zugriff und Messaging handhaben?

Legen Sie den Veröffentlichungsvertrag vor dem Start fest: öffentlicher oder eingeschränkter Zugriff, erlaubte Embed-Domains, Status Entwurf, veröffentlicht oder archiviert und die Frage, ob die Live-Oberfläche einen geprüften Datenschnappschuss zeigt. Domainkontrollen sollten reine Origins wie https://www.example.com und https://app.example.com verwenden. Kaleidrs aktuelle Viewer-Dokumentation beschreibt vom Herausgeber festgelegte erlaubte Domains für eingebettete veröffentlichte Karten. Eine durch Anmeldung geschützte Hostseite macht eine unabhängig erreichbare Karten-URL nicht automatisch privat; private Geschäftsdaten benötigen eine dafür entworfene Autorisierungsarchitektur.

Reservieren Sie Höhe und Breite, damit das Embed nicht zusammenfällt. Die HTML-Spezifikation empfiehlt einen knappen iframe-title, damit Hilfstechnologien den verschachtelten Browsing-Kontext benennen können (HTML Standard); die harte Anforderung eines programmatisch bestimmbaren Namens für Frames steht in WCAG 4.1.2. Laden Sie außerhalb des sichtbaren Bereichs liegende Embeds verzögert mit dem unterstützten Verhalten loading="lazy"; der HTML-Standard definiert Lazy-Loading-Attribute, und web.dev empfiehlt, Offscreen-iframes aufzuschieben, um Netzwerk- und Startaufwand zu verringern. Eine primäre Karte oberhalb der Falz sollte dagegen Teil der kritischen Nutzererfahrung sein. Halten Sie einen textlichen Fallback – Ortsnamen, Adressen oder eine Liste – bereit, damit die Seite auch bei Ausfall des Viewers funktioniert.

Die Kommunikation zwischen Origins gehört in einen kontrollierten Kanal. window.postMessage() ist der Standardmechanismus zwischen Fenstern und iframes (HTML Standard). Prüfen Sie event.origin bei eingehenden Nachrichten und setzen Sie bei ausgehenden Nachrichten eine konkrete Ziel-Origin; verwenden Sie nicht standardmäßig "*". Kaleidrs Viewer-Dokumentation beschreibt eine kaleidr-embed:*-Nachrichtenschnittstelle für unterstütztes Viewer-Verhalten. Viewer- und Hostzustand sollten getrennt bleiben: Die veröffentlichte Karte steuert Kamera und Auswahl im Viewer, während die Hostseite Navigation, Formulare und Conversion verantwortet.

// Published Viewer mount: share ID, not a server key
Kaleidr.mount("#published-map", {
  product: "viewer",
  shareId: "YOUR_SHARE_ID"
});

Wie sollten Teams veröffentlichte Karten versionieren, messen und zurückrollen?

Das Speichern eines Entwurfs ist nicht dasselbe wie die Veröffentlichung einer Live-Version. Behalten Sie stabile IDs für Orte und das Embed bei, damit Hostseiten bei Inhaltsänderungen nicht brechen. Versionieren Sie hinter dieser stabilen ID: neuen Entwurf bearbeiten, Datenqualität und mobiles Layout prüfen, veröffentlichen, Produktion verifizieren und bei Fehlern zurückrollen. Messen Sie mehr als Kartenaufrufe. Nützliche Signale sind „map-ready“, Ortsauswahl, CTA und Fehler; behandeln Sie diese Namen als redaktionelle Empfehlungen, sofern sie nicht als automatische Ereignisse dokumentiert sind. Trennen Sie Erstellungs- von Viewer-Analysen, damit Entwurfsexperimente keine Produktions-Funnels verfälschen.

Testen Sie Fehlerzustände: blockierte Domain, unveröffentlichte Share-ID, langsames Netzwerk und fehlender Text-Fallback. Produktionsdomains, Content Security Policy, Quellenangaben und sichere ausgehende Links gehören zum selben Release. CMS-Seiten brauchen einen reservierten Container und einen geprüften Schnappschuss. SaaS-Produkte müssen die Karte an den Anwendungszustand koppeln. Marketingseiten benötigen einen Conversion-Pfad, der nicht allein von Karteninteraktionen abhängt. Echtzeit- und 3D-Karten stellen höhere Anforderungen an Performance und Fallback; veröffentlichen Sie sie nur, wenn die Hostseite diese Kosten tragen kann.

Welche Fehler bei der Kartenveröffentlichung sollten Teams vermeiden?

Fazit

Kartenveröffentlichung gelingt, wenn das Team die Live-Karte als Produktoberfläche und nicht als Export behandelt. Wählen Sie Teilen, Einbetten oder Integrieren danach, wie eng die Karte mit Hostinhalt und Anwendungszustand gekoppelt sein muss. Ergänzen Sie dann den Produktionsvertrag: Zugriff, erlaubte Domains, reserviertes Layout, Origin-validiertes Messaging, Versionierung, Messung und Rollback. Kaleidr Studio veröffentlicht derzeit eigenständige Seiten und einbettbare Widgets; Kaleidr Viewer adressiert eine veröffentlichte Karte per Share-ID. Diese Trennung hält die Erstellung schnell, während die Hostseite für Conversion, Barrierefreiheit und Release-Disziplin verantwortlich bleibt.

Karten mit Kaleidr Studio veröffentlichen

Erstellen, prüfen und veröffentlichen Sie eine Karte als eigenständige Seite oder einbettbares Widget und mounten Sie veröffentlichte Viewer-Embeds dort, wo die Hostwebsite sie benötigt. Kaleidr Studio öffnen, um zu veröffentlichen, und die Entwicklerdokumentation für Viewer-Share-IDs, erlaubte Domains und SDK-Mounts nutzen.

Häufig gestellte Fragen

Was ist Kartenveröffentlichung?

Kartenveröffentlichung verwandelt eine bearbeitbare Karte in ein stabiles Erlebnis, das andere öffnen, einbetten oder in einem Produkt nutzen können – mit Kontrollen für Zugriff, Layout, Versionierung und Messung.

Was ist der Unterschied zwischen einem Freigabelink und einem Embed?

Ein Freigabelink öffnet die veröffentlichte Karte als eigene Seite. Ein Embed platziert diese Karte innerhalb einer Hostwebsite oder eines Produktlayouts.

Wann sollte ein Team eine Produktintegration statt eines Embeds verwenden?

Wenn Filter, ausgewählte Datensätze oder Workflow-Zustand mit der Karte synchron bleiben müssen, statt nur einen eigenständigen Viewer zu umgeben.

Benötigt Kaleidr Viewer einen API-Schlüssel?

Die aktuelle Viewer-Dokumentation beschreibt veröffentlichte Viewer-Karten als per Freigabelink statt API-Schlüssel geschützt. Prüfen Sie vor der Bereitstellung die aktuelle Entwicklerdokumentation, da sich Zugriffsmodelle ändern können.

Ist eine Share-ID dasselbe wie ein API-Schlüssel?

Nein. Eine Share-ID identifiziert ein veröffentlichtes Kartenerlebnis. Ein Server-API-Schlüssel autorisiert privilegierte API-Operationen und muss geheim bleiben.

Sollte ich ein Karten-Embed verzögert laden?

Meistens, wenn es unterhalb der Falz liegt oder für die Seite zweitrangig ist. Ist die Karte die primäre Interaktion, laden Sie sie als Teil der kritischen Erfahrung und optimieren Sie stattdessen ihren Start.

Wie mache ich eine iframe-Karte barrierefrei?

Geben Sie einem rohen iframe einen knappen title, stellen Sie hilfreiches umgebendes HTML bereit, unterstützen Sie per Tastatur bedienbare Aufgaben und bieten Sie Textinformationen an, die kein Ziehen der Karte erfordern.

Können zwei Cross-Origin-Seiten mit einer eingebetteten Karte kommunizieren?

Ja, wenn die Integration dies unterstützt. window.postMessage() ermöglicht kontrolliertes Cross-Origin-Messaging. Verwenden Sie eine konkrete Ziel-Origin und prüfen Sie die Origins eingehender Nachrichten.

Kann ich private Geschäftsdaten über ein Karten-Embed veröffentlichen?

Nur wenn Veröffentlichungs- und Autorisierungsarchitektur dafür ausgelegt sind. Eine anmeldungsgeschützte Hostseite macht eine unabhängig erreichbare Karten-URL nicht automatisch privat.

Sollte eine veröffentlichte Karte versioniert werden?

Ja, wenn Änderungen Kunden, Embeds, Berichte oder Geschäftsabläufe betreffen können. Versionierung macht Rollback und Fehlersuche erheblich sicherer.

Kann Kaleidr Studio Karten ohne Code veröffentlichen?

Ja. Laut aktueller Studio-Seite können Autoren Karten visuell erstellen und verfeinern und anschließend als eigenständige Seiten oder einbettbare Widgets veröffentlichen.

Referenzen

• Kaleidr. Design Custom Maps, Powered by Spatial AI. Kaleidr Studio. Abgerufen am 19. August 2026. https://kaleidr.com/studio
• Kaleidr. kaleidr.js Loader. Kaleidr Developer Documentation. Abgerufen am 19. August 2026. https://docs.kaleidr.com/sdk/kaleidr-js
• Kaleidr. Viewer Embed. Kaleidr Developer Documentation. Abgerufen am 19. August 2026. https://docs.kaleidr.com/sdk/viewer-embed
• WHATWG. HTML Standard — Lazy loading attributes. Abgerufen am 19. August 2026. https://html.spec.whatwg.org/multipage/urls-and-fetching.html#lazy-loading-attributes
• WHATWG. HTML Standard — The iframe element. Abgerufen am 19. August 2026. https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-iframe-element
• W3C. Understanding Success Criterion 4.1.2: Name, Role, Value. WCAG 2.2. Abgerufen am 19. August 2026. https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html
• WHATWG. HTML Standard — Posting messages. Abgerufen am 19. August 2026. https://html.spec.whatwg.org/multipage/web-messaging.html#posting-messages
• web.dev. Lazy load images and iframe elements. Abgerufen am 19. August 2026. https://web.dev/learn/performance/lazy-load-images-and-iframe-elements

@misc{kaleidr_studio_publish_2026,
  title  = {Design Custom Maps, Powered by Spatial AI},
  author = {{Kaleidr}},
  note   = {Kaleidr Studio; accessed 19 August 2026},
  url    = {https://kaleidr.com/studio}
}

@misc{kaleidr_viewer_embed_2026,
  title  = {Viewer Embed},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Documentation; accessed 19 August 2026},
  url    = {https://docs.kaleidr.com/sdk/viewer-embed}
}

@misc{kaleidr_js_loader_2026,
  title  = {kaleidr.js Loader},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Documentation; accessed 19 August 2026},
  url    = {https://docs.kaleidr.com/sdk/kaleidr-js}
}

@misc{whatwg_iframe_2026,
  title  = {HTML Standard -- The iframe element},
  author = {{WHATWG}},
  note   = {Accessed 19 August 2026},
  url    = {https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-iframe-element}
}

@misc{wcag_412_2026,
  title  = {Understanding Success Criterion 4.1.2: Name, Role, Value},
  author = {{W3C}},
  note   = {WCAG 2.2; accessed 19 August 2026},
  url    = {https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html}
}

@misc{whatwg_lazy_loading_2026,
  title  = {HTML Standard -- Lazy loading attributes},
  author = {{WHATWG}},
  note   = {Accessed 19 August 2026},
  url    = {https://html.spec.whatwg.org/multipage/urls-and-fetching.html#lazy-loading-attributes}
}

@misc{whatwg_postmessage_2026,
  title  = {HTML Standard -- Posting messages},
  author = {{WHATWG}},
  note   = {Accessed 19 August 2026},
  url    = {https://html.spec.whatwg.org/multipage/web-messaging.html#posting-messages}
}

@misc{webdev_lazy_iframe_2026,
  title  = {Lazy load images and iframe elements},
  author = {{web.dev}},
  note   = {Accessed 19 August 2026},
  url    = {https://web.dev/learn/performance/lazy-load-images-and-iframe-elements}
}