Ein Wiederauffindbarkeitsnachweis verbindet die fachliche Identität einer Bekanntmachung mit mindestens einem geprüften öffentlichen Rückweg. Er enthält Herausgeber, Bekanntmachungsservice und operative Vergabeplattform, Verfahrenskennung, Kennung und Fassung der Bekanntmachung, Veröffentlichungsnummer, Los, Referenz des Auftraggebers, öffentliche Darstellung, offene Datendarstellung, Prüfzeit und Suchanleitung. „public_locator_verified“ gilt, wenn die dokumentierte öffentliche Adresse in einer frischen Sitzung die erwartete Bekanntmachung liefert. „public_recovery_verified“ gilt, wenn die direkte Adresse fehlt, die Kennungssuche aber reproduzierbar zum richtigen Treffer führt. „authenticated_route_only“ beschreibt einen zulässigen Zugang erst nach Anmeldung, ohne dessen Sitzungsadresse zu speichern. „temporary_locator_rejected“ sperrt befristete oder zugangstragende Adressen. „identity_mismatch“, „source_conflict“ und „source_unavailable“ verhindern eine Weiterverwendung bei falschem Ziel, Widerspruch oder nicht prüfbarer Quelle. „superseded“ verweist auf den ersetzenden Datensatz. Der Nachweis sagt nichts darüber aus, ob das Verfahren noch offen ist.
Bei deutschen Vergaben erscheinen häufig mehrere richtige Webseiten: der zentrale Bekanntmachungsservice, TED bei EU-Verfahren, eine ältere Anzeige auf service.bund.de, das Portal der Vergabestelle und ein Bietercockpit für Unterlagen oder Abgabe. Ein Link aus dem angemeldeten Bietercockpit kann von einer Sitzung, einem Mandanten oder einer ausgewählten Trefferliste abhängen. Ein alter service.bund.de-Eintrag kann verschwinden, weil der Dienst ausdrücklich keine Langzeitarchivierung verspricht. Ein zentraler Datensatz kann weiterhin auffindbar sein, während der Link zur operativen Plattform umzieht. Wer nur eine Browseradresse ablegt, vermischt Veröffentlichung, Wiederauffindbarkeit und Zugang. Das fällt oft erst auf, wenn eine Kollegin oder ein Agent den Datensatz ohne Cookies öffnen soll.
Beginnen Sie mit den Kennungen der Bekanntmachung, nicht mit dem sichtbaren Link. Der Datenservice Öffentlicher Einkauf bündelt Bekanntmachungsdaten und stellt sie frei zugänglich sowie über Open Data bereit. eForms-DE übernimmt für EU-weite Veröffentlichungen definierte Kennungen und Fassungen. Sichern Sie diese Werte zusammen mit Auftraggeber, Bekanntmachungsart, Los und Prüfzeit. Prüfen Sie den öffentlichen Weg ohne ELSTER-Konto und ohne Portal-Cookies. Trennen Sie anschließend die Veröffentlichung von Unterlagen, Kommunikation und elektronischer Angebotsabgabe. Ein Agent darf offene Daten lesen, öffentliche Links prüfen und einen Rückweg beschreiben. Er darf kein Unternehmenskonto verwenden, keine AGB bestätigen, keine Sitzung nachspielen und keine geschützten Vergabeunterlagen abrufen, sofern dafür keine gesonderte Beauftragung besteht.
Direkte Antwort
Ein belastbarer Link funktioniert außerhalb der ursprünglichen Sitzung
Speichern Sie nie nur die Browseradresse. Legen Sie daneben die amtlichen Kennungen, den Auftraggeber, die Bekanntmachungsart, die Fassung und das Los ab. Öffnen Sie den vorgesehenen öffentlichen Link danach in einer frischen Sitzung. Im Ziel müssen dieselben Identitätsmerkmale stehen. Fehlt ein dauerhafter Detailweg, dokumentieren Sie eine öffentliche Suche, die mit der Kennung wieder zum Treffer führt.
Der Test braucht einen leeren Zugriffskontext. Ein vorhandenes ELSTER-Login, ein Cookie der Vergabeplattform oder eine zuvor ausgewählte Trefferliste kann den Fehler verdecken. Prüfen Sie deshalb mit einem neuen Browserprofil oder einem nicht angemeldeten HTTP-Client. Halten Sie die Weiterleitungskette fest. Eine 200-Seite mit Anmeldefeld oder allgemeiner Trefferliste ist kein erfolgreicher Nachweis.
Eine öffentliche Bekanntmachung und ein geschützter Projektraum dürfen nebeneinander bestehen. Der erste Link belegt, was veröffentlicht wurde. Der zweite Bereich kann aktuelle Unterlagen, Nachrichten und die Abgabe enthalten. Im gemeinsamen Datensatz steht für diesen Bereich nur die öffentliche Eintrittsseite, die Verfahrensreferenz und „authenticated_route_only“. Interne Sitzungsadressen bleiben im Browser.
Auch ein technisch dauerhafter Link altert fachlich. Er kann weiterhin die erste Fassung liefern, nachdem eine Berichtigung eine Frist geändert hat. Der Wiederauffindbarkeitsnachweis bewahrt die zitierte Veröffentlichung. Ein anderer Prüfschritt stellt fest, welche Fassung gegenwärtig maßgeblich ist. Diese Trennung erhält sowohl Beleg als auch Aktualität.
| Zustand | Beleg | Folge |
|---|---|---|
| public_locator_verified | Anonymer Abruf mit Identitätstreffer | Öffentlichen Link mit Prüfzeit teilen |
| public_recovery_verified | Kennungssuche führt zum richtigen Treffer | Suchanleitung statt unsicherer Direktadresse teilen |
| authenticated_route_only | Amtlicher Weg verlangt Anmeldung | Nur Grenze und öffentlichen Einstieg nennen |
| temporary_locator_rejected | Sitzung, Ticket, Signatur oder Ablauf erkennbar | Adresse verwerfen und Kennung nutzen |
| identity_mismatch | Zielmerkmale passen nicht | Weiterverwendung stoppen |
| source_unavailable | Quelle lässt sich derzeit nicht prüfen | Später wiederholen, keinen Defekt behaupten |
Deutscher Quellenweg
DÖE und Vergabeplattform erfüllen unterschiedliche Aufgaben
§ 10a VgV ordnet die Übermittlung von EU-Bekanntmachungen über den Datenservice Öffentlicher Einkauf. Das Bundesportal beschreibt den Bekanntmachungsservice als zentrale, frei zugängliche Stelle für Bekanntmachungsdaten, die von Vergabeplattformen des Bundes, der Länder und der Kommunen zugeliefert werden. Die Open-Data-Schnittstelle bietet Exporte in eForms-DE, CSV und OCDS. Für die Wiederauffindbarkeit ist dieser öffentliche Veröffentlichungsweg oft stabiler als ein Link, der erst im Bietercockpit entsteht.
Die Detailangaben des Bekanntmachungsservices führen zur ausschreibenden Vergabeplattform. Dort finden Unternehmen die teilnahmerelevanten Aktionen. Daraus folgt keine Austauschbarkeit der Links. Der DÖE-Datensatz ist ein öffentlicher Veröffentlichungs- und Recherchebeleg. Die Zielplattform kann die aktuellen Unterlagen, Bieterkommunikation und Abgabe steuern. Ein Register sollte beide Beziehungen ausdrücken und für jede ein eigenes Zugriffsmerkmal führen.
eForms-DE baut auf den EU-eForms auf. In der Bekanntmachung stehen eine UUID als Bekanntmachungskennung, eine Fassung und, soweit vorgesehen, eine Verfahrenskennung. TED ergänzt bei der Veröffentlichung eine Veröffentlichungsnummer. Diese Werte überleben eine Änderung der Benutzeroberfläche besser als Titel oder Listenposition. Sie müssen trotzdem mit ihrem Namensraum gespeichert werden, weil dieselbe Zeichenfolge in einem anderen Feld etwas anderes bedeuten kann.
Der DÖE kann über offene Daten erneut befragt werden, wenn sich die Oberfläche ändert. Ein Agent hält dafür die Kennung, das gewünschte Format und die erwarteten Identitätsfelder fest. Er nutzt keine hohe Abrufrate und respektiert die veröffentlichten Schnittstellenregeln. Schlägt der maschinelle Zugriff wegen einer Sperre fehl, bleibt die öffentliche manuelle Suche als separater Rückweg erhalten.
| Quelle | Typische Aufgabe | Zu sichernder Rückweg |
|---|---|---|
| DÖE Bekanntmachungsservice | Zentrale öffentliche Recherche | Kennungssuche und öffentlicher Datensatz |
| TED | EU-Veröffentlichung | Veröffentlichungsnummer und dokumentierter Direktlink |
| Vergabeplattform | Unterlagen und Verfahrenshandlungen | Öffentliche Eintrittsseite plus Referenz |
| Bietercockpit | Angemeldete Bearbeitung und Abgabe | Keine Sitzungsadresse im Register |
| service.bund.de Altbestand | Veröffentlichungshinweis | Beleg sichern, aber kein Langzeitarchiv annehmen |
| Lokale Kopie | Zeitpunktbezogene Dokumentation | Hash und Abrufzeit, niemals als aktueller Herausgeber |
Identität
Titel und Trefferposition taugen nur zur Gegenprobe
Ein Titel kann berichtigt, abgekürzt oder auf mehreren Plattformen anders dargestellt werden. Auch die Position in einer Trefferliste ändert sich mit Sortierung und neuen Veröffentlichungen. Legen Sie deshalb eine Liste typisierter Kennungen an. Zu jedem Wert gehören Feldname, System, Reichweite, Rohwert, Quellstelle und Abrufzeit. Der normalisierte Titel unterstützt die Prüfung, entscheidet sie aber nicht.
Die Verfahrenskennung verbindet mehrere Ereignisse derselben Beschaffung. Eine Bekanntmachungskennung unterscheidet eine Veröffentlichungslinie. Die Fassung bezeichnet deren Bearbeitungsstand. Eine Veröffentlichungsnummer adressiert die tatsächlich veröffentlichte Darstellung. Die Loskennung grenzt den Teil der Leistung ein. Die interne Vergabenummer des Auftraggebers hilft im operativen Portal, ist aber ohne Herausgeber und Jahr möglicherweise nicht eindeutig.
Offene Daten nach OCDS unterscheiden ebenfalls Prozess und Veröffentlichungsereignis. Der OCID verbindet Releases eines Beschaffungsvorgangs. Eine einzelne Release-ID bezeichnet den unveränderlichen Datenstand eines Ereignisses, während ein kompilierter Record die jüngsten Werte zusammenführt. Wer eine frühere Entscheidung belegen will, braucht den damaligen Release. Wer den aktuellen Stand sucht, prüft den Record und seine neueren Releases.
Ein gutes Gegenprüfungsset ist klein und eindeutig. Für eine Auftragsbekanntmachung genügen gewöhnlich Bekanntmachungskennung oder Veröffentlichungsnummer, Auftraggeber, Bekanntmachungsart und betroffenes Los. Eine Übereinstimmung nur beim Titel reicht nicht. Zwei Kommunen können dieselbe Standardleistung gleich benennen, und eine Berichtigung kann den Titel unverändert übernehmen.
| Wert | Geltungsbereich | Prüfung |
|---|---|---|
| Verfahrenskennung | Gesamter Beschaffungsvorgang | Verknüpfte Bekanntmachungen suchen |
| Bekanntmachungskennung | Eine Bekanntmachungslinie | Richtige Publikationsart bestätigen |
| Fassung | Ausgabe dieser Bekanntmachung | Bearbeitungsstand nachweisen |
| Veröffentlichungsnummer | Publizierte Darstellung | Direktlink oder TED-Suche bilden |
| Loskennung | Teil der Beschaffung | Richtigen Gegenstand prüfen |
| Vergabenummer | Namensraum des Auftraggebers | Mit Herausgeber und Jahr speichern |
| OCID und Release-ID | Offener Prozess und Ereignis | Aktuellen Record vom zitierten Release trennen |
Zugriffsschutz
Sitzungsdaten gehören weder in Linksammlungen noch in Logs
Nicht jeder Parameter ist geheim. RFC 3986 erlaubt, dass eine Abfrage einen Datensatz über ein öffentliches Schlüssel-Wert-Paar auswählt. Entscheidend ist die dokumentierte Bedeutung im jeweiligen Portal. Ein Parameter mit amtlicher „id“ kann zum öffentlichen Link gehören. Ein Sitzungsschlüssel, Zugriffsticket oder signierter Ablaufwert gehört nicht dazu. Verwenden Sie eine Freigabeliste bekannter öffentlicher Routen anstelle einer unvollständigen Liste verdächtiger Parameternamen.
Die OWASP-Empfehlung zur Sitzungsverwaltung nennt Links, Protokolle, Browserhistorie, Lesezeichen, Referrer und Suchmaschinen als mögliche Abflusswege für Sitzungskennungen in URLs. Eine solche Kennung kann im angemeldeten Zustand denselben Zugriff vermitteln wie die vorangegangene Authentisierung. Kopieren Sie sie nicht in Tickets oder CRM-Felder. Für die Diagnose reichen Host, Pfadform, Parameternamen und der Vermerk, dass ein vertraulicher Wert entfernt wurde.
Ein „rel=canonical“-Hinweis kann auf die vom Herausgeber bevorzugte Darstellung ohne Sitzungsparameter zeigen. RFC 6596 beschreibt genau diese Beziehung zwischen inhaltsgleichen Adressen. Der Zielinhalt muss trotzdem geprüft werden. Ein falsch gesetzter Canonical kann auf einen anderen Datensatz, eine Oberseite oder eine fehlerhafte Sprache verweisen. Der Hinweis ist eine starke Quelle für die Routenwahl, aber kein Ersatz für den Identitätsvergleich.
Bauen Sie aus einer privaten Adresse keinen vermeintlich öffentlichen Link, indem Sie einzelne Parameter raten und löschen. Das kann den Kontext wechseln oder auf eine andere Ressource führen. Kehren Sie zum öffentlichen Einstieg zurück und suchen Sie mit der amtlichen Kennung. Falls nur ein angemeldeter Weg existiert, dokumentiert der Nachweis diese Grenze. Eine befugte Person führt den Zugang später unter ihrem eigenen Konto aus.
| Beobachtung | Behandlung | Nachweis |
|---|---|---|
| Dokumentierter öffentlicher Detailpfad | Anonym testen und speichern | Identitätsfelder stimmen |
| Öffentliche Abfrage mit Kennung | Bei dokumentierter Semantik behalten | Suchwert ist kein Zugangsnachweis |
| Canonical-Ziel | Inhalt prüfen und als Begründung erfassen | Doppelte Darstellung bestätigt |
| Sitzung oder Einmal-Ticket | Nicht teilen und nicht wiederholen | Zugriffsrisiko |
| Befristeter Download | Nur als Abrufbeobachtung notieren | Kein dauerhafter Identitätsweg |
| Weiterleitung zur Anmeldung | authenticated_route_only | Öffentliche Wiederauffindbarkeit separat suchen |
| Weiterleitung zur Startseite | identity_mismatch | Bekanntmachungsmerkmale fehlen |
Beispiel
Ein Portalwechsel darf die Beschaffungsidentität nicht mitnehmen
Ein fiktiver Bundesauftraggeber veröffentlicht im DÖE die Bekanntmachung mit der beispielhaften UUID „11111111-2222-4333-8444-555555555555“, Fassung „01“, und der internen Vergabenummer „BUND-IT-2026-47“. Der DÖE-Eintrag verweist auf Portal A. Ein Rechercheagent speichert sowohl die öffentliche Bekanntmachung als auch eine URL aus dem angemeldeten Bietercockpit von Portal A. Zwei Wochen später wechselt der Auftraggeber für die operative Bearbeitung zu Portal B.
Der Sitzungslink zu Portal A scheitert erwartungsgemäß. Die Bekanntmachungskennung bleibt im DÖE auffindbar. Der Agent öffnet den Datensatz ohne Konto, bestätigt UUID, Fassung, Auftraggeber und Vergabenummer und sieht den neuen Link zu Portal B. Der Zustand des öffentlichen Nachweises bleibt „public_locator_verified“; die operative Route erhält eine neue Beobachtung. Der alte Zielhost bleibt als Historie erhalten, nicht als empfohlener Zugang.
Auf Portal B gibt es nur eine öffentliche Suchseite. Der Agent dokumentiert das Suchfeld „Vergabenummer“, den Wert „BUND-IT-2026-47“, den erwarteten Auftraggeber und die Trefferart. Nach der Auswahl beginnt die Anmeldung. Deshalb lautet der operative Zustand „public_recovery_verified“ bis zur Eintrittsseite und „authenticated_route_only“ für Unterlagen und Kommunikation. Der Agent testet keine Zugangsdaten.
Alle Namen und Kennungen dieses Beispiels sind erfunden. Der Ablauf zeigt die Grenze des Ergebnisses. Die gleiche Bekanntmachung ist wiederauffindbar, und der neue operative Einstieg ist nachvollziehbar. Ob die Unterlagen vollständig sind, eine Berichtigung gilt oder die Angebotsfrist noch läuft, wird damit nicht entschieden.
| Element | Gespeicherter Wert | Verwendung |
|---|---|---|
| Bekanntmachung | UUID, Fassung 01, Auftraggeber | Öffentliche Identität |
| Interne Referenz | BUND-IT-2026-47 mit Namensraum | Suche auf Portal B |
| Portal A | Alter Host und letzte Prüfzeit | Historie, kein Zugang |
| Portal B | Öffentliche Startseite und Suchanleitung | Wiederauffindbarer Einstieg |
| Bietercockpit | authenticated_route_only | Nur durch befugte Person |
| Fachlicher Stand | Nicht durch Linkprüfung belegt | Eigene Änderungs- und Fristprüfung |
Woran gute Arbeit erkennbar ist
Konkrete Ergebnisse für dauerhafter Vergabelink
- Jede gespeicherte Adresse ist einem Herausgeber, einer Portalrolle und einer konkreten Darstellung zugeordnet.
- Verfahrenskennung, Bekanntmachungskennung, Fassung, Veröffentlichungsnummer und Los bleiben als getrennte Schlüssel erhalten.
- Der öffentliche Rückweg wurde ohne ELSTER-Konto, Bietercockpit und vorhandene Cookies nachgestellt.
- Eine Anmeldung wird als Zugangsgrenze beschrieben; die Adresse innerhalb der Sitzung wird nicht geteilt.
- Die Recherche kann eine Bekanntmachung über DÖE, TED oder eine dokumentierte Suchfunktion erneut finden.
- Ein alter Veröffentlichungshinweis und die laufende operative Plattform werden nicht als austauschbar behandelt.
- Umleitungen, Portalwechsel und fehlende Langzeitarchive lösen eine erneute Prüfung aus.
- Nachgelagerte Agenten erhalten ein maschinenlesbares Ergebnis mit belegten und unbekannten Feldern.
Betriebsmodell
So wird die Arbeit ausgeführt
- 01
Portalrollen feststellen
Benennen Sie Veröffentlichungsdienst, Vergabeplattform, Unterlagenbereich, Kommunikation und Abgabeweg getrennt. Das Logo im Browser beweist keine Herausgeberrolle.
- 02
Kennungen mit Namensraum sichern
Erfassen Sie jedes Feld unter seiner amtlichen Bezeichnung, seinem System und seiner Reichweite. Eine Referenz der Vergabestelle ist nicht automatisch eine globale ID.
- 03
Öffentliche Darstellung bestimmen
Bevorzugen Sie einen vom Herausgeber vorgesehenen Detail- oder Datenendpunkt. Halten Sie HTML, PDF, XML, eForms-DE und OCDS als eigene Darstellungen fest.
- 04
Sitzungsmerkmale ausschließen
Prüfen Sie Pfad, Parameter und Fragment lokal. Übernehmen Sie keine Sitzungskennung, Signatur, Einmal-Ticket, Ablaufzeit oder private Objektadresse in ein gemeinsames Register.
- 05
Ohne Anmeldung testen
Starten Sie mit leerem Browserprofil. Protokollieren Sie Status, Weiterleitungen, Zielhost, Medientyp und die im Ziel bestätigten Kennungen.
- 06
Suchweg ausschreiben
Nennen Sie öffentliche Startseite, Suchfeld, Kennung, erwarteten Auftraggeber und Bekanntmachungstyp. Ein gespeicherter persönlicher Filter genügt nicht.
- 07
Aktualität separat prüfen
Verfolgen Sie Berichtigung, Aufhebung, Folge- und Zuschlagsbekanntmachung in einem eigenen Nachweis. Ein dauerhafter Link kann dauerhaft auf eine alte Fassung zeigen.
- 08
Wiederholungsanlass festlegen
Prüfen Sie erneut nach Portalumzug, neuer Fassung, abweichender Kennung, generischer Weiterleitung, Zertifikatsfehler oder bevor der Link extern veröffentlicht wird.
Bewertung
Fragen, die den Entscheid verändern
- Welche konkrete Bekanntmachung, Fassung und welches Los soll später wiedergefunden werden?
- Wer veröffentlicht den Datensatz, und wer betreibt nur den operativen Vergaberaum?
- Welche Kennung gilt für das ganze Verfahren, welche für die Bekanntmachung und welche nur innerhalb des Portals?
- Bietet DÖE, TED oder der Herausgeber einen dokumentierten öffentlichen Detail- oder Datenweg?
- Enthält die beobachtete Adresse Sitzungszustand, Zugriffsnachweis oder eine Ablaufbedingung?
- Liefert ein Test ohne Konto dieselbe Kennung, denselben Auftraggeber und dieselbe Bekanntmachungsart?
- Ist das Ziel eine unveränderte Veröffentlichung oder ein fortgeschriebener aktueller Datensatz?
- Wie lautet der öffentliche Suchweg, falls die direkte Adresse nicht mehr funktioniert?
Fehlermuster
Wo Teams die Kontrolle verlieren
Eine angemeldete Adresse kann den Zugriffskontext des ursprünglichen Nutzers offenlegen oder beim Empfänger scheitern.
Ein erfolgreicher Seitenaufruf kann nur eine Anmeldemaske oder leere Anwendungsschale enthalten.
Eine Weiterleitung auf die Startseite kann fälschlich als intakte Bekanntmachung gewertet werden.
Die Referenz der Vergabestelle kann mit der eForms-Verfahrenskennung oder Bekanntmachungs-ID verwechselt werden.
Ein service.bund.de-Link kann als Langzeitarchiv behandelt werden, obwohl der Dienst diese Funktion ausschließt.
Ein befristeter Unterlagendownload kann in einem öffentlichen Register landen.
Die erste Bekanntmachung kann als aktueller Stand gelten, obwohl eine Berichtigung veröffentlicht wurde.
Ein Agent kann zur Linkreparatur ein Konto verwenden oder Portalbedingungen annehmen, ohne dazu befugt zu sein.
Messung
Das fertige Ergebnis messen
Gemessen wird der abgeschlossene Prozess inklusive Review-Aufwand und Ausnahmen. Reines Output-Volumen beweist noch keine bessere Arbeitsweise.
- Nachweise mit Portalrolle, Kennungsnamensraum, öffentlichem Rückweg und Prüfzeit
- anonyme Tests mit übereinstimmender Bekanntmachungs-ID, Auftraggeber und Bekanntmachungsart
- gemeinsam genutzte Adressen ohne Sitzung, Zugangscode, Signatur oder Ablaufwert
- erfolgreiche Kennungssuchen ohne Konto und gespeicherten Filter
- getrennte Verweise für Veröffentlichung, Unterlagen, Kommunikation und Abgabe
- erkannte generische Weiterleitungen und inhaltliche Fehlzuordnungen
- gesperrte Automatisierung bei nicht erreichbarer oder widersprüchlicher Quelle
- erneuerte Prüfungen nach Portal- und Fassungsänderungen
Fragen
Häufige Fragen
Kann ich einen Link aus dem Bietercockpit weiterleiten?
Nur wenn das Portal ausdrücklich einen öffentlichen Freigabelink erzeugt und dieser ohne Ihre Sitzung geprüft wurde. Eine normale Cockpit-Adresse bleibt privat.
Brauche ich ein ELSTER-Unternehmenskonto für die DÖE-Suche?
Nein. Der Bekanntmachungsservice ist frei zugänglich. Ein Konto aktiviert Komfortfunktionen, darf aber keine Voraussetzung für den öffentlichen Wiederauffindbarkeitstest werden.
Ist die Vergabenummer immer eindeutig?
Nicht zwingend. Speichern Sie sie mit Auftraggeber, Portal, Jahr und Feldbezeichnung. Für EU-Veröffentlichungen kommen eForms-Kennungen und die TED-Veröffentlichungsnummer hinzu.
Warum reicht der Titel der Ausschreibung nicht?
Titel können mehrfach vorkommen, gekürzt oder berichtigt werden. Kennung, Auftraggeber, Bekanntmachungsart und Los ergeben einen stärkeren Identitätstest.
Kann service.bund.de als Archiv dienen?
Der Dienst erklärt selbst, dass er keine Langzeitarchivierung übernimmt. Ein dortiger Hinweis kann Beleg sein, braucht aber einen weiteren amtlichen Rückweg oder eine zeitbezogene Sicherung.
Darf ein Agent einen Sitzungsparameter schwärzen und den Rest speichern?
Nicht als geratenen Direktlink. Der Agent soll über den amtlichen Einstieg und die Kennung einen dokumentierten öffentlichen Weg finden.
Beweist ein dauerhafter Link die aktuelle Frist?
Nein. Er kann eine frühere Fassung korrekt wiedergeben. Prüfen Sie Berichtigungen, Portalhinweise und die maßgebliche Frist in einem eigenen Nachweis.
Was bedeutet eine Bot-Sperre im Linktest?
Sie bedeutet „source_unavailable“, nicht automatisch „Link defekt“. Bewahren Sie Kennung und manuelle Suchanleitung und wiederholen Sie den Test später.
Quellen
Primärquellen
- Open-Data-Richtlinie des Bekanntmachungsservice Datenservice Öffentlicher Einkauf
- § 10a Vergabeverordnung Bundesministerium der Justiz
- Bundesportal zur zentralen Bekanntmachungssuche Bundesportal
- Hinweis zur fehlenden Langzeitarchivierung service.bund.de
- TED Direktlinks und öffentliche Suchschnittstelle Amt für Veröffentlichungen der Europäischen Union
- eForms Kennungen und Fassungen Amt für Veröffentlichungen der Europäischen Union
- OCDS Kennungen und Veröffentlichungsereignisse Open Contracting Partnership
- OWASP Empfehlungen zu Sitzungskennungen in URLs OWASP Foundation
- RFC 6596 zur Canonical Link Relation RFC Editor
Über den Autor
Tony Kim
Tony schreibt über angewandte AI, verlässliches Product Engineering und Systeme, die komplexe Response-Arbeit kontrollierbar machen.
Zelius
Gemanagte Ausschreibungsintelligenz und Bid-Ausführung für Teams, die das Geschäftsergebnis suchen.
Anbieter, Gründerinnen und Gründer sowie Vertriebsteams für öffentliche und private Chancen. Ausgangspunkt sind der bestehende Ablauf, seine Grenzen und die vorhandenen Nachweise.