Domain-Verifizierung
Eine URL zu scannen steht jedem offen – eine öffentliche Aussage über sie zu veröffentlichen nicht. Die Domain-Verifizierung ist der Weg, auf dem AllyProof feststellt, dass die Website, über die Sie Aussagen treffen, tatsächlich Ihnen gehört.
Warum es die Verifizierung gibt
Jeder kann jede URL scannen. Das ist bewusst so, und jedes vergleichbare Werkzeug arbeitet genauso: WAVE, Lighthouse, PageSpeed und axe DevTools lassen Sie alle auf eine Domain zeigen, die Sie nie angefasst haben.
Veröffentlichen ist etwas anderes. Ein Freigabelink, eine Barrierefreiheitserklärung, ein einbettbares Siegel oder eine Zusammenfassung automatisierter Scan-Nachweise veröffentlicht Beobachtungen über eine Website gegenüber der Öffentlichkeit. Ohne Besitznachweis könnte jeder einen Wettbewerber scannen und "WCAG nicht bestanden" veröffentlichen oder ein grünes Siegel auf eine Website setzen, die er nicht kontrolliert.
Die Regel ist deshalb eng und absolut: Scannen ist offen, Veröffentlichen ist geschützt.
Was die Verifizierung freischaltet
Bis eine Website verifiziert ist, wird sie normal gescannt und ihre Ergebnisse sind für Ihr eigenes Team sichtbar. Die Verifizierung schaltet alles frei, was nach außen wirkt:
| Funktion | Verifizierung nötig |
|---|---|
| Scannen, Problemlisten, Bewertungen, Verlauf | Nein |
| Öffentliche Freigabelinks | Ja |
| Barrierefreiheitserklärungen | Ja |
| Einbettbares Barrierefreiheits-Siegel | Ja |
| Zusammenfassungen automatisierter Scan-Nachweise | Ja |
| Regulatorik-/Compliance-Modul | Ja |
| Erklärte Märkte, Niederlassungsland, Sprachwurzeln | Ja |
Ihre AllyProof-Administration kann zusätzlich verlangen, dass eine Website vor jedem Scan verifiziert ist. Das ist eine organisationsweite Einstellung und standardmäßig aus; die oben beschriebene Veröffentlichungssperre ist dagegen nicht optional und lässt sich nicht abschalten.
Methode wählen
Zwei Methoden werden unterstützt. Sie sind gleichwertig – nehmen Sie die, die Sie schneller ausrollen können, und Sie können vor der Verifizierung jederzeit wechseln.
HTML-Meta-Tag ist meist schneller, wenn Sie auf die Website deployen können. Es wirkt, sobald die Seite live ist.
DNS-TXT-Eintrag ist die bessere Wahl, wenn Sie das Markup der Website nicht anfassen möchten, wenn die Startseite hinter einem Login oder Bot-Schutz liegt oder wenn ein Marketing-Team das HTML und ein Infrastruktur-Team das DNS verantwortet. DNS-Änderungen brauchen bis zu 48 Stunden.
Beides richten Sie unter Websites → (Ihre Website) → Verifizierung ein – dort finden Sie den Token, das genaue Snippet und die Schaltfläche Jetzt verifizieren.
Methode 1 – HTML-Meta-Tag
Fügen Sie das von AllyProof angezeigte Tag in den <head> der Startseite ein:
<meta name="allyproof-verification" content="allyproof-verify-IHR-TOKEN">
Deployen Sie die Änderung und klicken Sie dann auf Jetzt verifizieren.
AllyProof ruft die Startseite ab und sucht den Token. Die Prüfung folgt
Weiterleitungen, eine Umleitung von http auf https oder von der Apex- auf
die www-Domain ist also unproblematisch.
Das Tag muss unter der URL erreichbar sein, die für die Website registriert
ist. Haben Sie https://example.com registriert, das Tag liegt aber nur auf
https://www.example.com und es gibt keine Weiterleitung dazwischen, findet
die Prüfung es nicht.
Methode 2 – DNS-TXT-Eintrag
Legen Sie bei Ihrem DNS-Anbieter einen TXT-Eintrag für die Root-Domain an:
| Feld | Wert |
|---|---|
| Typ | TXT |
| Host / Name | @ (oder leer lassen – das meint die Root-Domain) |
| Wert | allyproof-verify-IHR-TOKEN |
Speichern, Propagierung abwarten, dann Jetzt verifizieren klicken. AllyProof löst die TXT-Einträge der Domain auf und sucht einen, der den Token enthält. Andere TXT-Einträge – SPF, DKIM und so weiter – bleiben unberührt: Die Prüfung liest alle und trifft auf den Token zu, es muss also nichts entfernt werden.
Der Token
Jede Website erhält einen eigenen Token, abgeleitet aus ihrer Kennung und einem serverseitigen Geheimnis. Er ist stabil: Der heute angezeigte Token verifiziert auch morgen noch, Sie können ihn also gefahrlos in ein Template übernehmen oder in Infrastructure-as-Code einchecken.
Da er websitebezogen ist, verifiziert ein Token einer Website keine andere. Ein von einer Property zur anderen kopiertes Meta-Tag ist die häufigste Ursache für eine Verifizierung, die nicht durchgeht.
Wenn die Verifizierung fehlschlägt
Meta-Tag – prüfen Sie, ob die Änderung auf der Live-Seite und nicht in einem
Staging-Build liegt, ob sie innerhalb von <head> steht und ob die Seite auf
eine einfache Anfrage HTML zurückgibt. Eine vollständig clientseitig durch
JavaScript gerenderte Startseite funktioniert nicht: Die Prüfung liest das HTML,
das der Server sendet, und führt niemals Skripte aus. Setzen Sie das Tag in das
serverseitig gerenderte Dokument oder nutzen Sie stattdessen die DNS-Methode.
DNS – meist ist es die Propagierung; prüfen Sie mit
dig TXT example.com +short (oder nslookup -type=TXT example.com), ob der
Token in der Ausgabe steht. Hängt Ihr Anbieter die Domain automatisch an das
Host-Feld an, hat die Eingabe @ möglicherweise einen Eintrag auf
example.com.example.com erzeugt. Lassen Sie das Host-Feld dann leer.
Die Verifizierung lässt sich beliebig oft wiederholen – ein Fehlversuch kostet nichts und ändert nichts.
Nach der Verifizierung
Geprüft wird, wenn Sie auf Jetzt verifizieren klicken, nicht nach Zeitplan. Ist eine Website einmal verifiziert, bleibt sie es, und das Entfernen des Eintrags widerruft das nicht stillschweigend.
Lassen Sie den Eintrag trotzdem stehen. Er ist ohnehin folgenlos – ein TXT-Eintrag kostet nichts und das Meta-Tag ist für Besucher unsichtbar – und Sie brauchen ihn, falls die Website erneut verifiziert wird: nach einer Änderung der registrierten URL, beim Wechsel der Verifizierungsmethode oder wenn Sie die Website später erneut anlegen. Löschen Sie ihn, wird aus einer künftigen Ein-Klick-Prüfung ein Deployment.