Ich habe an meiner eigenen Power-Portals-Homepage gearbeitet und dabei ein neues Coaching-Paket live gestellt. Kaum online, habe ich den Link geteilt, um ihn zu testen, und bekam einen grauen Kasten zu sehen. Kein Titel, kein Bild, keine Beschreibung, nur die nackte URL, als hätte ihr niemand gesagt, was sie eigentlich ist.
Genau da habe ich zum ersten Mal wirklich verstanden, was ein Open-Graph-Tag ist und wie es funktioniert. Ich war jahrelang an den kleinen, ordentlichen Link-Karten in fremden Shares vorbeigescrollt, ohne mich zu fragen, warum meine eigenen nie so aussahen. Sobald ich den Mechanismus verstanden hatte, wollte ich ihn richtig in Power Pages einbauen, nicht nur für eine Seite hingefrickelt.
Auf dem Weg dorthin bin ich zuerst gegen die naheliegende Wand gelaufen: Das Web Template Header, das wie der offensichtliche Ort für ein site-weites <head>-Tag aussieht, rührt den <head> gar nicht an. Bei der Suche nach einem Workaround bin ich dann zufällig auf einen Blogbeitrag von Oliver Rodrigues aus dem Jahr 2020 gestoßen, der die Lösung, Content Snippet inklusive, bereits ausgearbeitet hatte. Das hätte ich mit einer einzigen Suche vorher finden können. 🤦♂️
Halb so wild. Es blieb trotzdem genug zu klären, wie sich das Ganze auf dem heutigen Power Pages verhält, Studio-Sites, Enhanced Data Model, und eine Sicherheitsfalle, in die fast jeder tappt, der das nachbaut. Danke, Oliver, für den Hinweis, der mir das letzte Stück Arbeit erspart hat: sein Originalbeitrag lohnt sich.
Dieser graue Kasten kostet Sie Konversion, und er gehört zu den billigsten Problemen, die Sie je beheben werden. Sie brauchen dafür keinen Shop, keinen Zahlungsdienstleister und kein Redesign. Sie brauchen rund zwanzig Zeilen Liquid im richtigen Web Template.
Ein Punkt vorweg, denn hier liegt der Fehler, den fast alle beim ersten Versuch machen: Die Lösung, die sich naheliegend anfühlt, ist ein Sicherheitsvorfall mit Anlauf.
Warum Power Pages Ihnen hier nichts schenkt
Microsoft dokumentiert vieles rund um Power Pages. Open Graph gehört nicht dazu. Wer auf Microsoft Learn nach Power Pages und Meta-Tags sucht, landet bei ganz anderen Produkten. Der einzige Artikel mit Bezug zur Indizierung ist der über die robots.txt.
Link-Vorschauen sind in Power Pages also kein Feature, das Sie einschalten. Sie sind etwas, das Sie aus einzeln dokumentierten Bausteinen zusammensetzen: Web Templates, Content Snippets und Liquid.
Die gute Nachricht: Der wichtigste dieser Bausteine arbeitet für Sie. Microsoft formuliert es eindeutig, Liquid werde serverseitig verarbeitet und die Ausgabe als reines HTML an den Endanwender geliefert. Ein Crawler, der keine einzige Zeile JavaScript ausführt, bekommt also vollständig gerenderte Tags. Was Sie in Liquid bauen, sieht LinkedIn genauso wie Teams.
Schritt 1: Übernehmen Sie den <head>, Seite für Seite
Open-Graph-Tags stehen im <head>. Wo Sie dorthin kommen, hängt davon ab, welche Art von Site Sie haben, und genau hier scheitert der Plan zuerst, wenn man es falsch annimmt.
Wenn Ihre Site mit der neueren Power-Pages-Studio-Oberfläche gebaut wurde, dem Drag-and-drop-Editor mit Komponenten, auf den neue Sites standardmäßig laufen, gibt es kein Web Template, mit dem Sie den <head> site-weit erreichen. Das Web Template namens Header, das wie der naheliegende Ort für site-weite Tags aussieht, ist gar kein <head>-Inhalt. Direkt geöffnet beginnt sein Quelltext mit einem <div class="navbar-expand-xl navbar ...">. Gegen das gerenderte DOM geprüft, dasselbe Bild: Die Navigationsleiste steckt im <body>, im <head> taucht sie nie auf. Der <head> einer Studio-Site, Zeichensatz, Viewport, die vorhandenen Meta-Tags, die Stylesheet-Links, wird von der Plattform um das herum erzeugt, was Ihr Page Template rendert. Dafür gibt es kein Web Template.
Es gibt allerdings einen site-weiten Weg durch eine andere Tür: ein reserviertes Content Snippet. Legen Sie eines mit exakt dem Namen Head/Bottom an, und Power Pages schleust dessen Inhalt auf jeder Seite in den <head> ein, ganz ohne Page-Template-Chirurgie. Das steht nicht in Microsofts eigener Produktdokumentation für den Open-Graph-Fall, es taucht in einem Community-Blogbeitrag von 2020 und einem Power-Platform-Forumsthread mit akzeptierter Antwort auf, behandeln Sie es also als durch Präzedenzfall belegt, nicht als offiziell dokumentiert. Direkt gegen diese Studio-Site getestet: Es funktioniert, ein statisches <meta>-Tag im Head/Bottom-Snippet erscheint im gerenderten <head> jeder Seite.
Die eine echte Grenze, ebenfalls direkt getestet: Liquid läuft innerhalb von Head/Bottom (Filter und Objekte wie {{ 'x' | upcase }} oder {{ now }} werten korrekt aus), aber die Objekte der aktuellen Anfrage, page und website, sind dort nicht gebunden. {{ page.adx_title }} oder {{ website.adx_name | escape }} lösen sich innerhalb von Head/Bottom zu nichts auf, und das gesamte <meta>-Tag mit diesen Werten verschwindet aus der gerenderten Ausgabe, statt mit leerem content="" ausgeliefert zu werden. Nutzen Sie Head/Bottom für echte statische, site-weite Tags, ein wörtliches og:site_name, twitter:card, ein Fallback-og:image, und lassen Sie es dabei bewenden. Einen abweichenden og:title pro Seite bekommen Sie darüber nicht.
Dafür brauchen Sie weiterhin den zweiten Mechanismus: ein Page Template mit deaktiviertem Use Website Header and Footer (standardmäßig aktiviert), verbunden mit einem Web Template. Was Microsoft für den Fall beschreibt, dass Sie diesen Haken entfernen, ist der ganze Kniff: Das Web Template ist dann für das Rendern der gesamten Antwort verantwortlich, vom Doctype über die <html>-Wurzelelemente bis zu allem dazwischen. Entfernen Sie ihn, und Sie schreiben das komplette Dokument selbst, Doctype inklusive, mit vollem Zugriff auf page, website und entities, und Open-Graph-Tags werden einfach weitere Zeilen in Ihrem eigenen <head>.
Direkt getestet: Ein Page Template mit deaktiviertem Haken, verbunden mit einem Web Template, das ein vollständiges <html><head>...</head><body>...</body></html>-Dokument enthält, rendert genau das. Jedes <meta property="og:...">-Tag landete im <head>, page.adx_title und website.adx_name lösten sich dort zu echten Werten auf, sonst kam nichts Ungebetenes mit. Der Kompromiss ist real: Sie verlieren die eingebaute Navigation und den Footer, die der Haken normalerweise kostenlos mitliefert, und das ist eine Entscheidung pro Page Template. Einen Weg zu site-weiten, dynamischen Tags pro Seite gibt es auf einer Studio-Site nicht, nur die statische Grundlage aus Head/Bottom.
Kombinieren Sie beides, und Sie erhalten eine sinnvolle Aufteilung: statische, site-weite Standardwerte in Head/Bottom, damit jede Seite wenigstens eine passable Karte hat, und das Page Template mit deaktiviertem Haken reserviert für die eine Seite, die tatsächlich einen dynamischen, datensatzgetriebenen Titel und eine Beschreibung braucht. Diese Einschränkung passt besser zum Rest dieses Artikels, als es zunächst klingt. Die Teaser-Seite, die Sie in Schritt 3 bauen, ist genau diese eine Seite. Sie rüsten nicht die ganze Site mit dynamischer <head>-Kontrolle nach, Sie bauen sie einmal, für die Seite, deren Aufgabe es ist, eine ansprechende Vorschau zu tragen.
Falls Ihre Site aus der Zeit vor der Studio-Oberfläche stammt (eine klassische Liquid-/Bootstrap-Site, gebaut mit Layouts wie layout_1_column): Prüfen Sie den Quelltext Ihres eigenen Header- und Footer-Web-Templates, bevor Sie von einem der beiden Verhalten ausgehen. Auf manchen dieser Sites umschließen Header und Footer tatsächlich wörtlich <head>...</head> und die schließenden Tags, was Sie ganz ohne Head/Bottom wieder ins vollständig dynamische, site-weite Terrain bringen würde. Öffnen Sie das Template und sehen Sie nach. Nehmen Sie nichts an.
Eine statische Grundausstattung für das Web Template Ihrer Teaser-Seite sieht so aus:
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="utf-8" />
<title>{{ page.title | escape }}</title>
<meta property="og:site_name" content="{{ website.adx_name | escape }}" />
<meta property="og:type" content="website" />
<meta property="og:title" content="{{ page.title | escape }}" />
<meta property="og:url" content="{{ request.url | escape }}" />
<meta property="og:description"
content="{{ snippets['OG/Description/Default'] | strip_html | truncate: 200 | escape }}" />
<meta property="og:image"
content="{{ request.url | base }}/og-default.png" />
<meta name="twitter:card" content="summary_large_image" />
</head>
<body>
{% include 'Header' %}
<!-- Ihr Seiteninhalt -->
{% include 'Footer' %}
</body>
</html>
Beachten Sie die Zeilen {% include 'Header' %} und {% include 'Footer' %} im Body. Weil der Haken aus ist, ergänzt die Plattform sie nicht automatisch, aber die Web Templates Header und Footer existieren weiterhin als ganz normal einbindbare Templates. Holen Sie sie sich explizit zurück, und Ihre Teaser-Seite behält dieselbe Navigation und denselben Footer wie der Rest der Site, sie besitzt nur zusätzlich ihren eigenen <head>.
Ende-zu-Ende getestet: Die Includes bringen die Navigationslinks und den Footer-Text zurück, aber kein einziges Stylesheet. Die Plattform lädt CSS und JS getrennt von Header und Footer, eine Seite mit deaktiviertem Haken rendert also ungestylt, bis Sie diese Links selbst ergänzen. Öffnen Sie den <head> einer beliebigen regulären Seite und übernehmen Sie, was Sie dort finden, auf dieser Site waren das bootstrap.min.css, theme.css und portalbasictheme.css neben ein paar gehosteten Bundles. Ihre konkrete Liste unterscheidet sich je nach Theme, die Lösung ist aber dieselbe: <link rel="stylesheet">-Tags dafür in Ihren eigenen <head> aufnehmen.
<link>-Tags selbst ergänzen.Drei Details im <head>-Block verdienen einen Hinweis.
request.url | base
request.url ist bereits absolut. Power Pages Liquid kennt keinen Filter absolute_url, egal was Sie in Jekyll- oder Shopify-Beispielen gesehen haben. Wenn Sie nur Schema und Host brauchen, schicken Sie die Request-URL durch den Filter base, den Microsoft als Weg zur Basis-URL dokumentiert.
escape
Keine Zierde. Microsoft empfiehlt in der Liquid-Dokumentation ausdrücklich, immer den Escape-Filter zu verwenden, wenn Sie mit Liquid nicht vertrauenswürdige Benutzerdaten lesen. Ein Datensatzname mit einem Anführungszeichen bricht Ihnen sonst aus dem content-Attribut aus.
snippets[...]
Der Beschreibungstext kommt aus einem Content Snippet, nicht aus fest verdrahtetem Markup. Content Snippets sind laut Microsoft kleine, redaktionell pflegbare Inhaltsbausteine. Das Marketing pflegt das Snippet. Sie fassen das Template nie wieder an.
Schritt 2: Über mehrere Seiten wiederverwenden, mit Fallback-Kette
Ein individuelles Page Template reicht für eine Teaser-Seite. Sobald Sie dieselbe Behandlung für mehrere Produktseiten brauchen, bewahrt Sie eine Fallback-Kette davor, content= für jeden Datensatz von Hand zu schreiben.
Das page-Objekt in Liquid verweist auf die aktuell angeforderte Seite und stellt title und url direkt bereit. Wichtiger als jede einzelne Eigenschaft ist eine allgemeine Regel, die Microsoft dokumentiert: Sie erreichen jedes Attribut des zugrunde liegenden Dataverse-Datensatzes über seinen logischen Namen. Genau so kommen Sie an die Spalte adx_summary der Webseite, obwohl sie nicht als benannte Eigenschaft gelistet ist.
Damit bauen Sie eine saubere dreistufige Fallback-Kette:
{% assign og_title = page.adx_title | default: page.title %}
{% assign og_desc = page.adx_summary %}
{% if og_desc == blank %}
{% assign og_desc = page.adx_copy %}
{% endif %}
{% if og_desc == blank %}
{% assign og_desc = snippets['OG/Description/Default'] %}
{% endif %}
<meta property="og:title" content="{{ og_title | escape }}" />
<meta property="og:description"
content="{{ og_desc | strip_html | truncate: 200 | escape }}" />Erst der Datensatz, dann die Seite, zuletzt das Snippet. Auf die Reihenfolge kommt es an: Der spezifischste verfügbare Text gewinnt, und es ist immer etwas da.
Beachten Sie strip_html vor truncate. Die Felder für Zusammenfassung und Inhalt enthalten Rich Text. Wer rohes HTML in ein content-Attribut schreibt, bekommt Markup-Fragmente in der Vorschaukarte.
Hinweis Enhanced Data Model: Eine Namensfrage lohnt die Klärung, falls Ihre Site auf dem neueren Enhanced Data Model läuft: Die zugrunde liegenden Dataverse-Spalten heißen dort mspp_title, mspp_summary und mspp_copy, nicht adx_title, adx_summary, adx_copy. Direkt gegen eine Enhanced-Data-Model-Site getestet, lösen die Liquid-Objekte page und website die alten adx_-Namen weiterhin zu echten Werten auf, während dieselben Objekte für die mspp_-Namen leer bleiben. Das deckt sich mit Microsofts eigener Aussage zum Enhanced Data Model: Sites darauf hätten "funktionale Parität mit Sites, die das Standard Data Model verwenden", "keine Funktionslücken", und Design Studio wie Liquid-Rendering "funktionieren gleich, unabhängig davon, ob die Site das Enhanced Data Model oder das Standard Data Model verwendet". Die adx_-Namen sind in Microsofts aktueller Referenz für page und website die dokumentierten Liquid-Objekteigenschaften, unabhängig davon, welche Tabelle tatsächlich dahintersteht. Verwenden Sie in dieser Fallback-Kette also in jedem Fall adx_title, adx_summary, adx_copy und adx_name.
Falls Ihre Landing Page eine datensatzgetriebene Tabellenseite ist: Greifen Sie nicht nach einer magischen Variablen entity. Ein solches globales Objekt dokumentiert Microsoft nicht. Dokumentiert sind zwei Wege, entweder page.<spalte>, wenn der zugrunde liegende Datensatz der Seite der aktuelle Request-Datensatz ist, oder der explizite Zugriff über {% assign item = entities['my_product'][request.params.id] %}.
Läuft Ihr Portal in mehr als einer Sprache, lohnen sich zwei weitere Tags: og:locale für die Sprache der gerade betrachteten Seite und, wiederholbar, og:locale:alternate für jede weitere Sprachversion, die existiert. Beide erwarten einen vollständigen Locale-Code, en_US oder de_DE, kein bloßes zweistelliges Sprachkürzel. Direkt getestet: Statische Werte für beide rendern korrekt und bestehen den LinkedIn Post Inspector anstandslos.
Speisen Sie og:locale aus dem, was Ihre Site ohnehin nutzt, um die Sprache einer Seite zu kennen, statt den Wert einmal pro Template fest zu verdrahten, und verweisen Sie mit og:locale:alternate auf die URL der jeweils entsprechenden Seite in jeder anderen Sprache, die Ihr Portal anbietet. Crawler nutzen dieses Paar, um die passende Variante auszuwählen und die gezeigte korrekt zu beschriften. Es ist eine kleine Ergänzung zur Fallback-Kette von weiter oben, kein zweiter <head>-Block zum Pflegen.
Ist die kuratierte Seite tatsächlich ein Artikel, runden zwei weitere Tags das Bild ab: og:type auf article statt website, und article:published_time. Direkt getestet: LinkedIns Post Inspector hatte den Seitentyp zwar schon aus dem Kontext als "Article" erkannt, zeigte Autor und Veröffentlichungsdatum aber erst korrekt an, nachdem beide Tags tatsächlich gesetzt waren. Dabei tauchte eine Falle auf: Der Liquid-Filter date mit einem strftime-artigen Formatstring, {{ now | date: '%Y-%m-%dT%H:%M:%S%z' }}, lieferte auf dieser Umgebung verstümmelte Ausgabe, kein gültiges Datum, reproduzierbar über mehrere Aufrufe und auch mit umgangenem Cache. Das ungefilterte {{ now }} rendert dagegen ein gültiges Datum. Verlassen Sie sich nicht darauf, dass die formatierte Variante auf Ihrer Site funktioniert, prüfen Sie das direkt, bevor Sie article:published_time daran hängen, es ist eine weitere Stelle, an der Power-Pages-Liquid von Shopify- oder Jekyll-Liquid abweicht.
Schritt 3: Die Falle. Crawler können sich nicht anmelden
Hier richten gute Absichten Schaden an.
Sie bauen eine schöne Produktdetailseite hinter der Anmeldung. Sie ergänzen Open-Graph-Tags. Sie teilen den Link. Die Vorschau bleibt leer. Also weiten Sie die Tabellenberechtigung aus, bis sich die Tags füllen, und schon sind die Daten öffentlich.
Kurz gefasst, vor dem Mechanismus: Ein Crawler ist ein anonymer Besucher, nicht mehr. Anonym lesbarer Inhalt bekommt echte Open-Graph-Tags, das ist das ganze Ziel. Angemeldeter, geschützter Inhalt liefert eine Seite, die der Crawler erreicht, aber jedes Tag, das aus einem für Anonymous nicht lesbaren Datensatz gebaut wird, kommt leer zurück, und die Leseberechtigung zur "Behebung" auszuweiten legt den Datensatz für jeden anonymen Besucher offen, nicht nur für Crawler. Die Lösung ist niemals, die Tabelle zu öffnen. Sie besteht darin, dem Crawler etwas anderes zum Lesen zu geben.
Der Mechanismus dahinter lohnt genaues Hinsehen, denn er hat zwei voneinander unabhängige Ebenen.
Der Zugriff auf Seitenebene wird über Seitenberechtigungen gesteuert. Die Option im Design Studio heißt wörtlich "Anyone can see this page", und die Dokumentation sagt dazu, dass die Seite damit öffentlich im Web und für jeden verfügbar ist.
Der Zugriff auf die Daten dieser Seite ist eine getrennte Frage und wird über Tabellenberechtigungen gesteuert, die an die Web Role für anonyme Benutzer gebunden sind. Microsoft beschreibt deren Verhalten unmissverständlich: Diese Rolle ist für die Verwendung mit Tabellenberechtigungen gedacht, sie respektiert keine anderen Regeln oder Berechtigungen, und eine Site kann nur genau eine solche Rolle für nicht authentifizierte Benutzer haben.
Ein Crawler ist ein nicht authentifizierter HTTP-Client. Er bekommt exakt die anonyme Rolle, nicht mehr. Wenn Ihre Open-Graph-Tags also aus einem Datensatz gebaut werden, den anonyme Benutzer nicht lesen dürfen, rendert die Seite, aber die Tags bleiben leer.
Die verlockende Abkürzung ist, der anonymen Rolle Leserechte auf der Tabelle zu geben, damit sich die Tags füllen. Tun Sie das nicht. Tabellenberechtigungen gelten nicht nur für ein Template. Microsoft hält fest, dass der Zugriff auf Dataverse-Datensätze in Power Pages automatisch eingeschränkt wird, wenn Formulare, Listen, Liquid, die Portals Web API und weitere Komponenten auf Dataverse-Tabellen zugreifen. Lesen ist Lesen: Jede Liste, jedes Formular und jeder Web-API-Aufruf auf dieser Tabelle antwortet ab sofort auch anonymen Besuchern. Microsofts eigener Site Checker weist genau auf dieses Muster hin und nennt Tabellenberechtigungen, die der anonymen Web Role zugewiesen wurden und ungewollt Daten offenlegen.
Der richtige Weg ist kleiner und sicherer: eine kuratierte öffentliche Teaser-Seite.
Eine Seite. Bewusst anonym lesbar. Sie trägt den Marketingtext, das Bild und die Open-Graph-Tags, und sie wird entweder aus statischem Snippet-Inhalt oder aus einer bewusst schmalen Tabelle gespeist, in der nichts Vertrauliches steht. Der Call to Action auf dieser Seite führt in den angemeldeten Bereich. Der Crawler bekommt eine schöne Karte, der Mensch bekommt die Anmeldung, und Ihre produktiven Tabellen bleiben zu.
Kuratieren Sie das Schaufenster.
Öffnen Sie nicht das Lager.
Noch eine kleine Anforderung dabei: die Bildgröße. Das Open-Graph-Protokoll selbst schreibt keine feste Größe vor, Facebooks eigene Sharing-Richtlinien tun das: 1200 mal 630 Pixel, nah am Seitenverhältnis 1,91:1, und alle anderen Plattformen, auch LinkedIn, haben sich auf dieselben Werte eingependelt. Laden Sie es als Web File hoch und verweisen Sie mit absoluter URL darauf, Crawler lösen relative Pfade nicht zuverlässig auf.
Die Hürde, die Sie zuerst nehmen: robots.txt
Bevor Sie irgendetwas vom Obigen angehen, prüfen Sie eine Sache, die nichts mit Liquid zu tun hat. Power Pages liefert standardmäßig eine robots.txt aus, die jeden Crawler von der gesamten Site aussperrt: User-agent: * / Disallow: /. Direkt getestet: LinkedIns Post Inspector versucht nicht einmal eine Vorschau für eine URL hinter diesem Standard. Die eigene Fehlermeldung ist eindeutig: Die URL werde nicht neu gescannt, weil sie oder eine ihrer Weiterleitungen durch Regeln in der robots.txt der Domain blockiert sei. Perfekte Open-Graph-Tags auf einer Seite, die der Crawler nie abrufen durfte, bringen Ihnen nichts.
Microsofts dokumentierte Lösung ist ein Web File namens Robots.txt an der Wurzel Ihrer Site mit leerem Disallow:
User-agent: *
Disallow:Das öffnet die gesamte Site fürs Crawling, das ist eine legitime Wahl. Wenn Sie lieber den Großteil der Site aus der Suche heraushalten und trotzdem Crawlern Zugriff auf Ihre eine kuratierte Teaser-Seite geben wollen, grenzen Sie stattdessen ein:
User-agent: *
Disallow: /
Allow: /ihre-teaser-seite/
Das folgt der Standardkonvention für den Robots-Exclusion-Standard, wonach eine spezifischere Allow-Regel gegenüber einem breiteren Disallow gewinnt, und kostet nichts an Datenexposition, da robots.txt ausschließlich Crawl-Absicht signalisiert, niemals Datenzugriff. Es rührt weder Tabellenberechtigungen noch Seitenberechtigungen an. Prüfen Sie die eingegrenzte Variante mit dem Post Inspector an Ihrer eigenen Site, bevor Sie sich darauf verlassen, nicht jeder Crawler setzt die Spezifitätsregel identisch um.
So prüfen Sie, ob es wirklich funktioniert
Konfigurationsänderungen wie Web Templates und Content Snippets laufen über den serverseitigen Cache, trauen Sie also nicht dem, was Sie direkt nach dem Speichern sehen. Warten Sie aber auch nicht einfach ab: Rufen Sie /_services/about auf Ihrer Site auf und leeren Sie den Cache von dort aus, dann ist die Änderung sofort live. Lassen Sie diesen Schritt weg, greift Microsofts eigene Zusage trotzdem von selbst innerhalb von 15 Minuten, es gibt aber keinen Grund, darauf zu warten.
Testen Sie danach mit den Werkzeugen, die Open-Graph-Tags tatsächlich auslesen, nicht mit dem eigenen Browser. LinkedIns Post Inspector und Facebooks Sharing Debugger holen die Seite frisch ab und zeigen genau, was sie sehen, einschließlich harter Fehler wie einer robots.txt-Blockade. Auch das Einfügen des Links in einen Teams-Chat lohnt sich, und zwar separat: Verschiedene Plattformen rendern unterschiedliche Teilmengen derselben Tags. Im Test zeigte der LinkedIn-Post-Editor Titel und Bild, Teams rendert darüber hinaus auch die og:description in derselben Kartenvorschau. Prüfen Sie mindestens zwei Plattformen, bevor Sie es als erledigt betrachten, und nutzen Sie die Aktualisierungsfunktion des jeweiligen Inspektors statt zu raten, alle diese Plattformen cachen aggressiv.
Was Sie dafür bekommen
Keinen Shop. Keinen Checkout. Keine neuen Lizenzen. Ein individuelles Page Template, ein Content Snippet, eine kuratierte Teaser-Seite und ein Bild.
Das Ergebnis: Jeder Link auf Ihr Portal, in jedem Teams-Kanal, in jedem LinkedIn-Beitrag und in jeder E-Mail-Vorschau, sieht nicht mehr aus wie eine kaputte URL, sondern wie ein Produkt. Für die meisten Power Pages Sites ist das die wirksamste Arbeitsstunde, die überhaupt verfügbar ist.
Und es ist der kleinstmögliche Schritt Richtung E-Commerce. Genau deshalb lohnt er sich als erster.
Sie möchten das in Ihrer Site umgesetzt haben, ohne die Umwege?
Weekly Coaching ist mein Festpreisformat für genau solche Themen: eine feste Sitzung pro Woche, in der wir an Ihrem Portal arbeiten, in Ihrer Umgebung, mit Ihrem Team. Diese Woche die Meta-Tags, nächste Woche die Hygiene Ihrer Tabellenberechtigungen.
Weekly Coaching, Festpreis, ohne ÜberraschungenWeiterführende Artikel
Power Pages Sicherheitsarchitektur
Tabellenberechtigungen, Web Roles und das hierarchische Sicherheitsmodell im Detail, der Mechanismus hinter Schritt 3 oben.
Artikel lesen → TutorialMaker's Guide: Daten in Power Pages
Wie Dataverse-Daten in Power Pages bereitgestellt und genutzt werden, der Hintergrund zu den hier verwendeten Objekten page und entities.
Artikel lesen →Quellen
- Enhanced Data Model, Aussage zur funktionalen Parität
- Web Templates in Power Pages, inklusive "Use Website Header and Footer"
- Inhalte über Web Templates ablegen
- Was ist Liquid, Aussage zur serverseitigen Verarbeitung
- Verfügbare Liquid-Objekte, unter anderem page, request, snippets, entities, website
- Verfügbare Liquid-Filter, unter anderem escape, strip_html, truncate, default, base
- Inhalte mit Content Snippets anpassen
- Sicherheitsüberblick Power Pages, anonyme Benutzer
- Web Roles anlegen, Verhalten der anonymen Rolle
- Seitenzugriff steuern, "Anyone can see this page"
- Tabellenberechtigungen setzen
- Site Checker, Konfigurationsprobleme und anonyme Offenlegung
- Cache manuell leeren und die 15-Minuten-Zusage für Konfiguration
- Robots.txt und Indizierung durch Suchmaschinen
- Spezifikation des Open Graph Protocol
- Bildempfehlung von Facebook, 1200 x 630 und 1,91:1
- Community-Beleg für das Content Snippet Head/Bottom (keine offizielle Microsoft-Dokumentation, per direktem Test bestätigt)
- Oliver Rodrigues, "Power Apps Portals: Adding a <head> meta tag" (2020), der ursprüngliche Beitrag hinter dem Head/Bottom-Ansatz
