En udvikler omdøber en route fra flertal til ental, fordi det er mere konsistent med resten af API'et. Testene kører grønt, review godkendes, og det ryger i produktion. Ingen af de tre led kender til de fjorten eksterne sites, der linker til den gamle adresse.
Hvorfor det opdages for sent
En 404 på en side ingen intern navigation peger på, udløser ingen alarm. Overvågningen tjekker at applikationen svarer, ikke at en bestemt historisk URL stadig gør. Fejlen viser sig som et langsomt fald i organisk trafik, og på det tidspunkt er der gået måneder, og ingen forbinder det med et deploy.
Læg det i pipelinen
Problemet er velegnet til automatisering, fordi det er mekanisk. Tre trin rækker:
- En liste over URL'er der har værdi. Eksportér de adresser der har indgående links eller organisk trafik, og læg listen i repoet.
- Et smoke-test-trin efter deploy. Kald hver adresse og fejl buildet ved 404 eller ved en viderestilling til forsiden.
- Et krav i review. Ændres en route, skal en viderestillingsregel med i samme pull request.
Viderestilling til forsiden er ikke en løsning
Den udbredte genvej er en fangstregel, der sender alt ukendt til forsiden. Det fjerner 404-siden i logfilen og løser ingenting. Google behandler en viderestilling til noget irrelevant som en blød 404, og brugeren, der klikkede på et link om et bestemt emne, lander et sted uden det indhold. Er der ingen tilsvarende side, er en ærlig 410 bedre.
Det historiske efterslæb
Har sitet kørt i nogle år uden den disciplin, ligger der som regel en pæn bunke tabte links, hvor kildesiden stadig findes og stadig linker. Det er de billigste links overhovedet at genvinde, fordi de allerede er givet, og en systematisk gennemgang af brudte links er den hurtigste vej til at finde ud af hvor mange der er tale om.