Adressen wie /leistungen/#preise führen innerhalb einer Seite zu einem Abschnitt. Der Teil nach # ist ein Fragment. Er wird beim normalen HTTP-Abruf nicht an den Server gesendet und macht aus dem Abschnitt keine eigenständige Seite.
Woher stammen die Einträge?
Fiktives Beispiel: Ein Sitemap-Generator liest sämtliche Navigationslinks ein. Dadurch erscheinen /leistungen/#umfang und /leistungen/#preise als zwei zusätzliche Seiten. Beide gehören aber zum Dokument /leistungen/.
Prüfe, ob die Sitemap aus veröffentlichten Seiten oder aus einer ungefilterten Linkliste entsteht. Für die Korrektur ist diese Quelle entscheidend. Entferne Fragmente bei der Sitemap-Erzeugung und fasse identische verbleibende URLs zusammen.
Dabei darf die normale Seitennavigation ihre Anker behalten. Das Löschen aller Hash-Zeichen im gesamten Projekt würde funktionierende Sprunglinks beschädigen.
Ein Sonderfall braucht eine andere Lösung
Zeigt eine ältere Anwendung unterschiedliche Inhalte nur über Hash-Routen wie /#/produkt/rot, reicht das Abschneiden des Fragments nicht. Es würde alle Ansichten auf dieselbe Startadresse reduzieren. Prüfe dann, ob echte, direkt abrufbare Seitenadressen eingerichtet werden müssen.
Kontrolliere am Ende eine betroffene Sitemap-URL und den ursprünglichen Sprunglink getrennt: Die Sitemap soll die Seite nennen; der Link im Inhalt darf weiterhin zum vorgesehenen Abschnitt führen.
Zum verwandten Prüfschritt: Das Weiterleitungsziel eines Canonicals prüfen.
Die gezielte Bereinigung eines bekannten Sitemap-Generators im Frontend kannst du über Frontend-Optimierung anfragen.