// stack · schnittstelle
Im B2B ist die LinkedIn-Unternehmensseite für viele Firmen der Ort, an dem sichtbar wird, dass etwas passiert — und die Website ist der Ort, an dem daraus Anfragen werden. siteway verbindet beides so, dass die Beiträge serverseitig abgeholt, im CMS zwischengespeichert und als eigenes HTML ausgegeben werden. Diese Seite beschreibt die Technik dahinter — und sagt offen, was beim Zugang zu den LinkedIn-Schnittstellen vorher zu klären ist.
// definition
LinkedIn bündelt seine Schnittstellen im LinkedIn Marketing API Program, dessen Dokumentation Microsoft veröffentlicht. Das Programm ist breit: Es reicht von Werbung und Kampagnensteuerung über Veranstaltungen und Leads bis zu Zielgruppen und Auswertung. Für eine Unternehmenswebsite ist davon nur ein Ausschnitt relevant.
Dieser Ausschnitt heißt Community Management API. Sie deckt laut Dokumentation die Verwaltung von Unternehmensseiten ab — Seitendaten und Marken, Administratorrollen, Follower, das Erstellen und Lesen von Beiträgen samt Kommentaren und Reaktionen sowie Auswertungen zu Seite und Beiträgen. Wer „LinkedIn auf der Website“ sagt, meint fast immer genau das: die Beiträge der eigenen Unternehmensseite, dargestellt im eigenen Layout statt in einem fremden Kasten.
Dazu kommt ein dritter Berührungspunkt, der oft übersehen wird: die Stellenanzeigen. Wer auf LinkedIn ausschreibt, hat damit einen zweiten Kanal neben der eigenen Karriereseite — und die Frage, welche Quelle führend ist. Wie der Baustein auf der Website daraus aussieht, beschreibt die Komponente Social Media Newsroom. Hier geht es um die Schnittstelle darunter.
// praxis
abruf auf dem server
Der erste Schritt ist ein Gespräch, kein Code: Wir klären den Zugang, bevor wir bauen. Der Zugriff auf die Inhalte einer Unternehmensseite setzt eine Entwickleranwendung voraus, deren Zugang beantragt und von LinkedIn freigegeben wird. Das ist kein Häkchen in einer Oberfläche und keine Frage von Minuten. Wir schreiben deshalb zu Projektbeginn auf, was der Bereich zeigen soll, prüfen, was der freigegebene Umfang hergibt, und legen erst danach fest, wie er gefüllt wird.
Steht der Zugang, ist die Mechanik immer dieselbe: abholen, zwischenspeichern, selbst rendern. Ein geplanter Lauf auf dem Server fragt die Beiträge der Unternehmensseite ab und schreibt sie als Datensätze ins CMS — Text, Datum, Verweis auf den Originalbeitrag, Bilder als lokale Kopien in den Formaten der Website. Das Frontend liest anschließend nur noch aus dem CMS. Zwischen dem Seitenaufruf eines Besuchers und LinkedIn liegt damit keine einzige Verbindung.
Daraus folgt der angenehme Nebeneffekt: Die Seite ist unabhängig vom Zustand der Schnittstelle. Antwortet sie langsam, verzögert das einen Hintergrundlauf und keinen Seitenaufruf. Antwortet sie gar nicht, bleibt der zuletzt abgeholte Stand stehen, bis der nächste Lauf durchgeht. Und weil die Beiträge als echtes HTML auf der eigenen Domain liegen, sind sie lesbar — für Besucher, für Suchmaschinen und für die Suche auf der Website selbst.
Und wenn ein Zugang nicht zustande kommt oder für den gewünschten Umfang nicht reicht, gibt es den Weg, der immer trägt: dieselbe Darstellung, redaktionell gepflegt. Die Redaktion legt die Beiträge im CMS an und verweist auf die Unternehmensseite; auf der Website ist das Ergebnis dasselbe Modul mit denselben Feldern. Das ist eine Zuordnung nach Voraussetzungen, keine Rangliste — und weil beide Wege im selben Template enden, lässt sich später umschalten, ohne den Bereich neu zu bauen.
Was bei alldem nicht passiert: Es landet kein LinkedIn-Code im Browser. Keine fremde Bibliothek, kein Rahmen mit unbekannter Höhe, kein Aufruf zu einem weiteren Host. Warum das über den Datenschutz hinaus zählt, steht unter Performance im Stack.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus der öffentlichen Entwicklerdokumentation zum LinkedIn Marketing API Program. Wir nennen bewusst nur, was dort belegt ist — Programmnamen, Zugangsstufen und das Verfahren. Konkrete Kontingente, Berechtigungsnamen und Versionsstände ändern sich und gehören deshalb in die Klärung eines konkreten Projekts, nicht in eine Technikbeschreibung.
// d-01seite
Der für Websites relevante Bereich des Programms. Laut Dokumentation deckt er die Verwaltung von Unternehmensseiten ab: Seitendaten und Marken, Administratorrollen, Follower sowie das Erstellen und Lesen von Beiträgen, Kommentaren und Reaktionen. Alles, was auf einer Website als Newsroom-Bereich landet, hängt hier dran.
zweck: unternehmensseite
// d-02zugang
Die Dokumentation beschreibt eine Entwicklungsstufe und eine Standardstufe. Die Entwicklungsstufe wird zuerst vergeben, dient dem Bauen und Testen und arbeitet mit Aufrufgrenzen; sie ist darauf angelegt, dass die Integration innerhalb von zwölf Monaten fertiggestellt wird. Die Standardstufe ist die Stufe für den laufenden Betrieb ohne diese Beschränkungen.
zweck: entwicklung → betrieb
// d-03freigabe
Die Hochstufung wird gesondert beantragt; zum Antrag gehört laut Dokumentation eine Bildschirmaufnahme, die die angegebenen Anwendungsfälle zeigt. LinkedIn behält sich ausdrücklich vor, Anträge zu prüfen und Partner nach eigenem Ermessen auszuwählen — auch wer die Mindestanforderungen erfüllt, hat keinen Anspruch auf die Hochstufung.
zweck: vorher klären
// d-04anmeldung
Die Berechtigungen sind laut Dokumentation Mitgliedsberechtigungen im dreibeinigen OAuth-Verfahren: Ein angemeldetes Mitglied stimmt der Anwendung zu, und es muss die passende Rolle auf der Unternehmensseite besitzen — die Verwaltung setzt die Administratorrolle voraus. Der Zugang hängt damit an einer Person; wer das ist und wie erneuert wird, gehört in die Betriebsdokumentation.
zweck: berechtigung
// d-05versionen
Die Marketing-Schnittstellen sind versioniert, und die Dokumentation weist regelmäßig auf abgekündigte Versionen und nötige Migrationen hin. Für ein Projekt heißt das: Eine Anbindung ist nichts, was einmal gebaut und dann vergessen wird. Wir planen sie als betreute Verbindung mit Überwachung ein, nicht als einmalige Lieferung.
zweck: wartung einplanen
// d-06abruf
Weil die Zugangsstufen mit Aufrufgrenzen arbeiten, ist der Zwischenspeicher keine Optimierung, sondern Voraussetzung. Ein geplanter Lauf holt die Beiträge in ruhigem Takt, schreibt sie ins CMS und protokolliert das Ergebnis. Die Zahl der Aufrufe hängt danach am Takt des Laufs — und nicht mehr an der Zahl der Besucher.
zweck: entkopplung
Aus dem Abruf wird kein eingebetteter Kasten, sondern ein Bereich der Website. Die Beiträge stehen als Karten oder Liste im Layout der Seite, mit den Schriften und Farben der Website, in der Bildgröße, die dort ohnehin ausgeliefert wird. Jeder Beitrag trägt einen Verweis auf das Original in der Unternehmensseite — wer weiterlesen oder reagieren will, geht dorthin.
Weil die Inhalte im CMS liegen, sind sie auch kuratierbar: Ein Beitrag lässt sich anheften, einer ausblenden, die Auswahl über eine Regel eingrenzen. Und weil sie als Text auf der eigenen Domain stehen, werden sie gefunden — von der internen Suche ebenso wie von Suchmaschinen, ergänzt um strukturierte Daten aus denselben Feldern.
Der Bereich hat dabei von Anfang an eine feste Struktur: Karten mit gleichbleibendem Aufbau, Bilder mit gesetzten Maßen, ein definierter Zustand für den Fall, dass gerade keine Beiträge vorliegen. Nichts verspringt nachträglich, weil nichts nachträglich kommt.
// integration
drei systeme · ein muster
Der Weg ist in jedem System derselbe, und er steht und fällt mit einer Entscheidung: Die Beiträge der Unternehmensseite werden serverseitig abgeholt und im CMS zwischengespeichert; das Frontend rendert sie als eigenes HTML. Ein geplanter Lauf fragt die Beiträge ab, legt sie als Datensätze ab und zieht die Bilder als lokale Kopien nach. Was ein Besucher später bekommt, ist eine gewöhnliche Seite aus dem eigenen CMS — kein LinkedIn-Code im Browser, keine zusätzliche Verbindung, kein eingebetteter Rahmen.
Das hat zwei Folgen, die den Unterschied ausmachen. Erstens bleibt die Seite schnell und funktioniert bei einem Ausfall der Schnittstelle weiter: Der Abruf liegt im Hintergrund, nicht im Ladepfad, und der zuletzt geholte Stand steht so lange, bis der nächste Lauf durchgeht. Zweitens liegt das Zugriffstoken serverseitig — in der Konfiguration des Systems oder in einer Umgebungsvariablen, nie in einem Template, nie im Repository, nie in etwas, das im Browser landet. Was sich zwischen den Systemen unterscheidet, sind nur die Bordmittel, mit denen wir das bauen.
// cms-01typo3
Wir bauen die Anbindung als eigene Extension. Der Abruf läuft als Scheduler-Task: Er holt die Beiträge der Unternehmensseite, schreibt sie als Records mit eigenem TCA in einen Systemordner und legt die Bilder in der Dateiverwaltung ab. Die Redaktion sieht die Beiträge damit im Backend wie jeden anderen Inhalt und kann einzelne anheften oder ausblenden. Das Zugriffstoken steht in der Extension-Konfiguration statt im Template. Im Frontend gibt ein Fluid-Template die Datensätze aus, ein Content-Element setzt den Bereich auf jede Seite, die ihn braucht.
// cms-02wordpress
In WordPress entsteht die Anbindung als eigenes Plugin und nicht als Theme-Code — so überlebt sie den Theme-Wechsel. Die Beiträge werden ein Custom Post Type mit Meta-Feldern für Datum, Verweis und Medien, dazu eine Taxonomie, wenn nach Thema gefiltert werden soll. Der Abruf hängt an einem geplanten Lauf, der die neuen Beiträge anlegt und bestehende aktualisiert; die Bilder landen in der Mediathek und werden in den Größen des Themes ausgeliefert. Das Token steht in der wp-config.php oder in einer Umgebungsvariablen. Fürs Frontend kommen ein Block für den Editor und Template-Teile dazu.
// cms-03statamic
Statamic läuft auf Laravel, und das macht diesen Teil angenehm gerade. Der Abruf wird ein Artisan-Command, den der Laravel-Scheduler regelmäßig aufruft und der sich jederzeit von Hand nachziehen lässt. Die Beiträge werden Entries in einer eigenen Collection, beschrieben über ein Blueprint mit Feldern für Text, Datum, Verweis und Bild; ein Fehlversuch landet im Log statt auf der Seite. Das Token steht in der .env und wird über die Konfiguration gelesen. Antlers oder Blade rendern die Entries — und weil Static Caching die Seiten ausliefert, kostet der Bereich beim Aufruf praktisch nichts.
// datenschutz
technik, nicht rechtsberatung
Der technische Sachverhalt ist schnell beschrieben: Ein eingebettetes LinkedIn-Element lädt Code von fremden Servern in den Browser deiner Besucher. Damit diese Auslieferung überhaupt funktionieren kann, geht die IP-Adresse an den Server, der die Daten schickt — und weil es sich um ein soziales Netzwerk handelt, kommen in aller Regel Wiedererkennungsmerkmale dazu, die weit über die Anzeige eines Beitrags hinausreichen. Das gilt für Beitrags-Einbettungen ebenso wie für Folgen- und Teilen-Schaltflächen.
Deshalb ist der serverseitige Abruf bei siteway der Standardweg. Die Verbindung besteht zwischen deinem Server und LinkedIn, nicht zwischen deinen Besuchern und LinkedIn. Was im Browser ankommt, ist HTML von deiner Domain mit Bildern von deinem Server. Es wird nichts nachgeladen, es entsteht keine zusätzliche Verbindung, und der Verweis auf den Originalbeitrag ist ein gewöhnlicher Link, den nur betätigt, wer ihn betätigen will.
Wo eine echte Einbettung ausdrücklich gewünscht ist, gilt derselbe Weg wie bei jedem Fremdinhalt: An ihrer Stelle steht zunächst ein beschrifteter Platzhalter, der benennt, was beim Laden passiert; erst nach aktiver Zustimmung wird nachgeladen. Die Einwilligung wird an einer zentralen Stelle verwaltet und lässt sich zurücknehmen — dann steht beim nächsten Aufruf wieder der Platzhalter.
Dazu gehört die Seite der Zugangsdaten: Das Zugriffstoken bleibt auf dem Server, in der Systemkonfiguration oder einer Umgebungsvariablen, und taucht im Quelltext der Seite gar nicht erst auf. Wir beschreiben hier die Technik und ihre Umsetzung — die rechtliche Bewertung des Einzelfalls gehört in die Hand von Juristinnen und Juristen. Wie das im Zusammenhang der ganzen Website aussieht, steht unter Sicherheit & Datenschutz; wer den Bestand einer vorhandenen Seite geprüft haben will, findet das im Datenschutz-Audit.
// faq
LinkedIn bündelt seine Schnittstellen im LinkedIn Marketing API Program, dessen Dokumentation Microsoft veröffentlicht. Für eine Unternehmenswebsite ist davon vor allem ein Bereich interessant: die Community Management API. Sie deckt laut Dokumentation die Verwaltung von Unternehmensseiten ab — Seitendaten, Administratorrollen, Follower, Beiträge samt Kommentaren und Reaktionen sowie Auswertungen zu Seite und Beiträgen. Daneben stehen Bereiche für Werbung, Veranstaltungen, Leads und Zielgruppen, die mit einer Unternehmenswebsite in der Regel nichts zu tun haben. Wer von „LinkedIn auf der Website“ spricht, meint fast immer dasselbe: die Beiträge der eigenen Unternehmensseite, dargestellt im eigenen Layout.
Technisch ist der Weg klar, und er führt über den Server: Die Beiträge der Unternehmensseite werden serverseitig abgeholt, im CMS zwischengespeichert und vom Frontend als eigenes HTML ausgegeben. Im Browser der Besucher läuft dabei kein LinkedIn-Code. Der ehrliche Vorbehalt steht davor: Der Zugriff auf die Inhalte einer Unternehmensseite setzt eine Entwickleranwendung mit freigegebenem Zugang voraus, und diese Freigabe ist kein Häkchen in einer Oberfläche, sondern ein Antragsverfahren. Ob und in welchem Umfang sie erteilt wird, entscheidet LinkedIn. Deshalb steht die Klärung des Zugangs bei uns am Anfang eines Projekts und nicht am Ende — sie entscheidet mit darüber, wie der Bereich gebaut wird.
Über eine Entwickleranwendung und ein Antragsverfahren, das die Dokumentation in zwei Stufen beschreibt. Die Entwicklungsstufe wird zuerst vergeben; sie ist zum Bauen und Testen gedacht, arbeitet mit Aufrufgrenzen je Anwendung und je Mitglied und ist laut Dokumentation darauf angelegt, dass die Integration innerhalb von zwölf Monaten fertiggestellt wird. Die Standardstufe ist die Stufe für den laufenden Betrieb ohne diese Beschränkungen; sie wird gesondert beantragt, und zum Antrag gehört eine Bildschirmaufnahme, die die angegebenen Anwendungsfälle zeigt. LinkedIn behält sich in der Dokumentation ausdrücklich vor, Anträge zu prüfen und Partner nach eigenem Ermessen auszuwählen — auch wer die Mindestanforderungen erfüllt, hat keinen Anspruch auf die Hochstufung. Genau deshalb ziehen wir diesen Punkt vor die Umsetzung.
Dann steht die Seite trotzdem. Weil die Beiträge zwischengespeichert im CMS liegen und als eigenes HTML gerendert werden, ändert ein Ausfall der Schnittstelle nichts an der Auslieferung: Der zuletzt abgeholte Stand bleibt sichtbar, bis der nächste Abruf durchgeht. Und für den Fall, dass ein Zugang gar nicht zur Verfügung steht, gibt es den Weg, der immer trägt — dieselbe Darstellung, redaktionell gepflegt. Die Redaktion legt die Beiträge im CMS an und verweist auf die Unternehmensseite; auf der Website sieht der Bereich identisch aus. Beide Wege enden im selben Template, deshalb lässt sich später umschalten, ohne den Bereich neu zu bauen.
Das hängt daran, wo der Code läuft. Ein eingebettetes LinkedIn-Element lädt Code von fremden Servern in den Browser deiner Besucher; damit die Auslieferung überhaupt funktionieren kann, geht dabei die IP-Adresse mit, und häufig kommen Wiedererkennungsmerkmale dazu. Der Weg über den Server vermeidet das: Der Abruf passiert zwischen deinem Server und LinkedIn, die Besucher bekommen fertiges HTML von deiner Domain, und beim Seitenaufruf wird von fremder Stelle nichts nachgeladen. Wo eine echte Einbettung ausdrücklich gewünscht ist, kommt sie hinter eine Einwilligung und lädt erst nach aktiver Zustimmung. Die rechtliche Bewertung des Einzelfalls gehört in die Hand der Rechtsberatung — wir liefern die technische Umsetzung und die Dokumentation dazu.
In der Bauweise über den Server praktisch nicht. Ausgeliefert wird HTML aus dem eigenen CMS, mit Bildern vom eigenen Server in den Formaten und Größen, die die Seite ohnehin verwendet. Es kommt kein Skript von fremder Stelle dazu, keine zusätzliche Verbindung zu einem weiteren Host und kein Rahmen, dessen Höhe erst nach dem Laden feststeht. Der Netzwerkaufruf zu LinkedIn passiert in einem geplanten Lauf im Hintergrund und liegt damit außerhalb des Seitenaufrufs — ein langsamer oder ausfallender Abruf verzögert keine einzige Anfrage eines Besuchers. Ein eingebettetes Widget verhält sich umgekehrt: Es steht mitten im Ladepfad.
In der Regel läuft es andersherum. Die Stellen liegen im Bewerbermanagement- oder HR-System des Unternehmens, dort werden sie gepflegt und freigegeben, und von dort holt die Website sie ab — sie sind Inhalte der eigenen Domain, keine Kopien aus einem Netzwerk. Auf der Karriereseite bekommen sie strukturierte Daten, damit Suchmaschinen sie als Stellenanzeigen erkennen; das ist der Weg zu Google for Jobs. Die Unternehmensseite bei LinkedIn steht daneben und macht das, wofür sie gedacht ist: Sichtbarkeit im Netzwerk und der Verweis zurück auf die Karriereseite. Wer beides pflegt, bespielt zwei Kanäle aus einer Quelle.
Ja, in allen drei Systemen — und wir bauen die Anbindung jeweils selbst, mit den Bordmitteln des Systems. In TYPO3 entsteht eine eigene Extension: der Abruf als Scheduler-Task, die Beiträge als Records im Backend, das Zugriffstoken in der Extension-Konfiguration, die Ausgabe über ein Fluid-Template. In WordPress entsteht ein eigenes Plugin statt Theme-Code: die Beiträge als Custom Post Type, der Abruf als geplanter Lauf, das Token in der wp-config.php oder in einer Umgebungsvariablen. In Statamic liegt Laravel darunter: ein Artisan-Command im Scheduler, die Beiträge als Entries in einer eigenen Collection, das Token in der .env. Die Mechanik ist überall dieselbe — serverseitig abholen, zwischenspeichern, selbst rendern —, nur die Bordmittel heißen anders.
// womit das zusammenhängt
baustein, technik & grundlagen
// komponente · buchen
Die Technik hier, der Baustein dort: Beiträge aus mehreren Kanälen als Feed auf der Website — kuratierbar, im eigenen Look, als buchbare Komponente.
zur komponente →
// stack · schnittstelle
Der zweite Kanal für viele Unternehmen: Facebook und Instagram an der Website — dieselbe Mechanik, andere Schnittstelle.
zur technik →
// stack · schnittstelle
Der Berührungspunkt zur Karriereseite: Stellen aus dem HR-System, strukturiert ausgezeichnet und in der Jobsuche auffindbar.
zur technik →
// komponente · buchen
Wo die Stellen wirklich herkommen: Karriereseite mit Anbindung ans Bewerbermanagement, Bewerbungsstrecke und Auszeichnung.
zur komponente →
// stack · grundlage
Wo Fremdcode ins Spiel kommt, wird es konkret: serverseitiger Abruf, Token in der Konfiguration, Einwilligung, Dokumentation.
zur technik →
// leistung · buchen
Analyse, Zugang, Mapping, Umsetzung, Monitoring und Betrieb einer Anbindung — als buchbare Leistung beschrieben.
zur leistung →
// LinkedIn-Beiträge auf der Website — ohne Fremdcode im Browser?
Projekt anfragen