De Toe-Dip Methode voor het veranderen van de URL structuura

Als je websites bouwt of SEO-services aanbiedt, ben je ongetwijfeld op een bepaald moment tegen de vraag aangelopen wat de afwegingen en risico's zijn van het veranderen van de URL-structuur op een website.

Een website kan bijvoorbeeld de volgende URL-structuur hebben:

https://www.website.com/2019/04/26/the-post-title/

Terwijl je liever iets hebt dat lijkt op een van deze twee:

https://www.website.com/the-post-title/
https://www.website.com/articles/the-post-title/ 

Je weet waarschijnlijk ook dat dergelijke veranderingen ongelooflijk riskant kunnen zijn. Als je in een van de bovengenoemde disciplines werkt, voel je waarschijnlijk het gewicht van de verantwoordelijkheid die je draagt voor je eigen bedrijf of voor het bedrijf van je klanten.

Als dat niet zo is, even een korte samenvatting: uw inhoud staat waar het staat (laten we zeggen op de eerste pagina van Google) omdat Google de URL heeft gevonden en erop vertrouwt dat als iemand zoekt naar een relevante zoekopdracht, Google hem naar die URL kan sturen en hij de informatie zal vinden die hij zoekt.

Als die URL niet meer bestaat omdat u uw URL-structuur hebt gewijzigd en de wijziging niet goed hebt beheerd, bestaat uw verkeer ook niet meer.

Lees meer over URL-structuur en omleidingen

Er is heel wat subtiliteit nodig om dit goed te doen en er is al veel over geschreven. Deze post op het Moz-forum behandelt het algemene scala aan vragen en zorgen.

We raden dit bericht van Ahrefs. over dit onderwerp ten zeerste aan. De korte versie is dit: Als je dit verkeerd aanpakt, kun je hun bedrijf de das omdoen - of het op zijn minst ernstig belemmeren op de korte termijn, samen met je reputatie. Zie dat als onze disclaimer om hiermee door te gaan.

Wat echter niet in dat artikel wordt behandeld en wat volgens ons ongelooflijk goed werkt voor het veilig wijzigen van URL's, is de methode die in dit artikel wordt beschreven.

We noemen het de Toe-Dip Methode voor het veranderen van de URL-structuur.

Waarom zou je een canonbal doen als je ook gewoon je tenen kunt onderdompelen?

Canonballen zijn geweldig op zwembadfeestjes met goed gekleed gezelschap, maar als het aankomt op het adviseren van de bedrijven van onze klanten, vraagt het veranderen van de omgeving om wat meer subtiliteit.

In dit artikel wordt beschreven hoe je de URL-structuur van een website ingrijpend kunt wijzigen zonder een vloedgolf te riskeren.

We gebruiken Wordpress in dit bericht (omdat de kans groot is dat jij het ook gebruikt), maar hetzelfde concept is ook van toepassing op andere populaire contentmanagementsystemen.

Dus laten we erin duiken. ...eh, het water testen.

Een beetje achtergrond

Een van onze klanten met meer dan 10.000 berichten op hun website heeft sinds het begin van de site de bovenstaande op datum gebaseerde structuur gebruikt (site.com/yyyy/mm/dd/post-title). Dit betekent dat veel van hun hoogwaardige posts als volgt worden weergegeven in zoekresultaten:

Zo ziet het er nu waarschijnlijk ongeveer uit.

Wat de zaak nog erger maakt, is dat de branche van deze klant er een is waar, terecht of onterecht, versheid van de inhoud wordt gezien als een exclusief teken van relevantie. Dus zelfs als zoekmachines de inhoud hoog waarderen, worden hun organische CTR's ontegenzeggelijk enigszins gedrukt door de leeftijd van de inhoud.

Door de concurrentie in deze sector is het bijna noodzakelijk geworden om de URL-structuur te veranderen om ervoor te zorgen dat ze in elk opzicht hun beste beentje voorzetten.

Toen we eenmaal hadden gekozen voor de nieuwe URL-structuur, kregen we een idee over de beste manier om het risico versus de beloning te optimaliseren:

https://www.website.com/articles/post-title

Denk hier eens over na: als je een ervaren Wordpress-gebruiker bent, is het eerste waar je aan denkt als je over de URL-structuur nadenkt de Permalink Instellingen pagina in WP Admin:

Als je niet bekend bent met dit scherm, dan kun je Wordpress hier vertellen hoe de URL's van Posts op je site gestructureerd moeten worden. Het is een eenvoudig hulpmiddel om iets met een enorme impact te beheren. We zullen later in dit artikel terugkomen op dit scherm om onze wijzigingen af te ronden na veel testen.

Maar het probleem met het kijken naar deze pagina voor een oplossing is dat URL-structuurwijzigingen die hier worden gemaakt alles-of-niets zijn: verander de instelling op dit scherm en elke post verandert onmiddellijk, site-breed.

Zoals de Yoast SEO plugin ons waarschuwt bovenaan dit scherm:

Het wijzigen van je permalinks-instellingen kan de zichtbaarheid in zoekmachines ernstig beïnvloeden. Dit moet je bijna nooit doen op een live website.

Yoast SEO Plugin

Hoe kunnen we dan deze nieuwe URL-structuur testen op slechts een deelverzameling van berichten, zeg 20 of zo, en dan de resultaten evalueren? Zouden zoekmachines het nieuwe thuis van de inhoud vinden zonder dat dit ten koste gaat van de ranking?

Dit is hoe we dat hebben gedaan.

De Toe-Dip Methode, uitgelegd

We beginnen met het maken van een nieuw custom post type genaamd "Articles" (met als slug "artikelen"). De beste manier om aangepaste posttypes aan te maken en te beheren is de Wordpress plugin genaamd CPT UI, of Custom Post Type UI.

Installeer die plugin en maak dan je nieuwe aangepaste posttype genaamd "Artikelen". Als je instructies nodig hebt voor het instellen van een nieuw CPT, bekijk de documentatie.

De beste manier om erachter te komen met welke berichten je URL-wijzigingen kunt testen, is door naar je Google Analytics (of vergelijkbaar) te gaan en een aantal berichten te zoeken die veel verkeer hebben, maar misschien niet je topposts zijn (nogmaals, om het risico te beperken). Maak een lijst van de berichten die je wilt testen, sla de namen en URL's ergens op waar het handig is, want je zult de komende weken meerdere keren terug willen komen in je analytics om de prestaties te evalueren.

Om het berichttype van de berichten in kwestie te wijzigen, moet je een van de volgende twee dingen doen.

Je moet ofwel:

• Heb toegang tot de database en kennis om de ID van de post in kwestie te vinden en verander handmatig de waarde van het post_type veld van post in artikel, als je daar vertrouwen in hebt. Deze methode zal veruit het snelst zijn als je veel berichten in de test opneemt. Als je je niet op je gemak voelt om deze wijziging door te voeren, zorg er dan voor huur een ontwikkelaar in, en maak natuurlijk eerst een back-up van je website! Of,

• Installeer Post Type Switcher, en maak de wijziging vanuit het scherm voor het bewerken van berichten. Hier is een bericht om de wijziging met deze methode door te voeren. Opmerking: deze methode wordt vervelend naarmate je meer en meer berichten in je test opneemt.

Gebruik de door jou gekozen methode voor elke post die je wilt testen, en dan gebeurt er een beetje magie. Aangezien Wordpress verzoeken verwerkt op basis van het post-type van een post, hoef je niet eens handmatig redirects aan te maken! Zodra je de oude URL opnieuw opvraagt, verwijst Wordpress je automatisch door naar de nieuwe url-locatie:

Gebruik de door jou gekozen methode voor elke post die je wilt testen, en dan gebeurt er een beetje magie. Aangezien Wordpress verzoeken verwerkt op basis van het post-type van een post, hoef je niet eens handmatig redirects aan te maken! Zodra je de oude URL opnieuw opvraagt, verwijst Wordpress je automatisch door naar de nieuwe url-locatie op:

https://www.website.com/articles/post-title

Op deze manier is het werk eigenlijk uiterst minimaal om het gewenste resultaat te bereiken. Onze testberichten gebruiken nu onze nieuwe, definitieve URL-structuur, de rest van onze inhoud heeft geen idee dat er iets is veranderd en we kunnen achterover leunen en wachten tot we nieuwe analytische gegevens hebben verzameld om te zien hoe de wijzigingen zijn verlopen.

Voordat je verder gaat, moet je controleren of elke URL goed wordt omgeleid en of alles werkt zoals verwacht. Het zou zonde zijn om je test te laten mislukken vanwege een eerlijke fout.

Testprestatie-intervallen vaststellen

Nu je de test hebt uitgevoerd, raden we je aan om de prestaties van deze URL's de komende dagen en weken goed in de gaten te houden. Wij gebruikten het volgende schema om er zeker van te zijn dat we alles goed in de gaten hielden:

• Een dag later
• Drie dagen later
• Een week later
• Twee weken later
• Drie weken later

Waarom drie volle weken wachten? Dingen veranderen vaak met SEO en websiteprestaties, soms snel, soms langzaam. Onze beslissing om deze tests zo lang uit te voeren was gebaseerd op het feit dat we een manier hadden om het risico van deze verandering te verminderen en dat er geen substantiële urgentie was, dus waarom zouden we dingen overhaasten en risico's toevoegen door te snel te gaan? Je kunt je testschema natuurlijk aanpassen aan de behoeften van je organisatie.

Zoals eerder vermeld, begonnen we met slechts 20 berichten met een gemiddelde impact voor onze eerste testbatch. Nadat we daar succes mee hadden geboekt (zie "Onze resultaten" hieronder), gingen we verder met een grotere batch van 100 berichten, toen 500 berichten, toen 1000 en toen de resterende duizenden berichten. Ook hier was het verminderen van risico's bij zo'n grote verandering van cruciaal belang voor ons.

Het is echter de moeite waard om op te merken dat naarmate we meer vertrouwen kregen bij elke volgende test, we steeds kortere betrouwbaarheidsintervallen gebruikten.

Prestaties evalueren: een snel rapport opstellen

De methode die we hier hebben gebruikt is vrij eenvoudig, maar zeer krachtig, en als het eenmaal is ingesteld, doodsimpel om te gebruiken.

We gaan een aangepast rapport maken in Google Analytics, dat filtert op de URL's waarin we geïnteresseerd zijn. Open Google Analytics en klik op Aanpassingen->Aangepaste rapporten boven in de zijbalk:

Stel vervolgens je rapport in volgens de instellingen die we hier tonen:

Voel je vrij om alle statistieken toe te voegen die je relevant vindt, maar in dit voorbeeld hebben we alleen "Entrances / Pageviews" toegevoegd, omdat we ons hier voornamelijk bezighouden met de impact van deze URL-structuurverandering op het verkeer.

Het kleine beetje "magie" dat hier gebeurt, is dat we onder Filters een Regex filter op "artikelen". Dit is waar de kracht van dit rapport om de hoek komt kijken: als we nieuwe berichten toevoegen aan de test, worden ze hier automatisch opgenomen.

Let op: wanneer u nieuwe URL's toevoegt aan de test, zal uw verkeer in dit rapport ook toenemen, dus zorg ervoor dat u Notaties in uw rapport maakt om een logboek bij te houden wanneer u nieuwe URL's hebt toegevoegd, anders zal het lijken alsof de prestaties skyrocketed zijn (wat mogelijk het geval is, vandaar het nut van de notatie).

Nu we ons gefilterde rapport hebben ingesteld, kunnen we onze test voor het wijzigen van de URL-structuur met een laag risico evalueren en kijken of dit een wijziging is die we sitebreed moeten uitrollen.

Tijd om golven te maken: De laatste verandering doorvoeren

U hebt de hierboven beschreven tests uitgevoerd en de verkeersprestaties zijn (hopelijk) gelijk gebleven of enigszins verbeterd, zoals gemeten in uw aangepaste Google Analytics-rapport. Je hebt het vertrouwen gekregen dat dit de juiste richting is om in te slaan zonder je bedrijf (of dat van je klant) op het spel te zetten.

Laten we het officieel maken.

Voordat we beginnen, zorg ervoor dat je een back-up maakt van je website (inclusief je database) voor het geval je fouten maakt of om wat voor reden dan ook je wijzigingen moet terugdraaien.

De laatste stappen in dit proces zijn uiteindelijk een beetje genuanceerd, maar volledig uitvoerbaar als jij (of je ontwikkelaar) een beetje "techneut" bent. Waarom?

Het lijkt erop dat je nu alleen nog maar naar Instellingen->Permalinks hoeft te gaan en een aangepaste structuur hoeft toe te wijzen die begint met /artikelen/, zoals je hieronder ziet:

DOE DIT NIET - tenzij je maar één posttype op je site hebt (en altijd zult hebben). je site hebt. Dan zou het goed moeten zijn. Maar TEST!

Het probleem dat zich voordoet is dat als je andere berichttypes op je site hebt, deze wijziging ook /articles/ aan URL's van dat berichttype zal toevoegen.

Dus we gaan deze verandering met een vier-stappen aanpak benaderen: met behulp van de Permalinks instellingen en wat eenvoudige logica in je functions.php. Houd je code editor klaar en open dit bestand, want je wilt deze wijzigingen heel snel doorvoeren (anders loop je het risico dat je gebruikers beïnvloedt). Denk natuurlijk goed na over de wijziging voordat u deze opslaat, maar als u klaar bent om verder te gaan - ga!

Stap 1: Wijzig permalink-instellingen

Ga terug naar de Wordpress admin en ga nogmaals naar Instellingen->Permalinks en maak de wijziging die je hier ziet (kijk naar het Postnaam gedeelte):

Stap 2: Logica toevoegen om Wordpress te vertellen /artikels/ alleen aan Posts toe te voegen

Voeg het volgende toe aan je functions.php bestand, pas het articles gedeelte aan indien nodig, als je niet precies die string gebruikt voor je nieuwe URLs.

Bekijk het codefragment voor deze functie op deze Gist

De actie (zie add_action) herschrijft de URL's voor onze berichten. Het filter (zie add_filter) bewerkt de koppelingen naar berichten die Wordpress op verschillende plaatsen in de backend en frontend van je site genereert.

Stap 3: Wijs artikelen opnieuw toe als posts.

We moeten nog steeds het post-type van alle berichten die we eerder hebben toegewezen aan het post-type Artikelen opnieuw toewijzen. Gebruik de methode die u hierboven hebt geselecteerd om het posttype van deze berichten terug te wijzigen (dit gaat veel sneller als u de optie met de database hebt gekozen. Zorg ervoor dat je een ontwikkelaar inhuurt om deze wijziging door te voeren als je het zelf niet durft).

Verwijder vervolgens het artikeltype van je site met de CPT UI-plugin.

Stap 4 en een "gotcha": Regex redirects van je webserver

Weet je nog dat Wordpress het veranderen van /yyyy/mm/dd/post-title naar /articles/post-title gemakkelijk afhandelde? Nou, dat zal nu niet het geval zijn, want door de permalink structuur te veranderen, hebben we effectief het mechanisme onderbroken dat eerder in werking was (Wordpress gaf ons het voordeel van de twijfel op basis van het posttype).

Omdat we nu buiten de mechanismen van Wordpress voor het afhandelen van redirects vallen, moeten we onze webserver specifieke instructies geven over wat hij moet doen als er verzoeken voor datumgebaseerde (/yyyy/mm/dd/post) URL's binnenkomen. We gebruiken Nginx en hier is het kleine stukje dat we hebben bedacht om deze laatste stap af te handelen:

location ~ "/([0-9]{4})/([0-9]{2})/([0-9]{2})/(.*)" {
  return 301 https://www.website.com/articles/$4;
}

Hier maken we een locatieblok in onze Nginx-server met behulp van een reguliere expressie die zal reageren op alle routes met het formaat /yyyy/mm/dd/, en het verzoek zal doorsturen naar wat we in het blok hebben ingesteld. Het $4 gedeelte van het knipsel betekent in feite "het vierde deel van de bovenstaande regex", wat in dit geval de slug voor de URL is, zonder de datum (die is samengesteld uit de delen $1, $2, en $3 (hier niet gebruikt).

Als je Apache gebruikt in plaats van Nginx, bekijk dan deze post op Stack Overflow, die de oplossing lijkt te hebben.

Test grondig!

Controleer nu je site om er zeker van te zijn dat alles nog goed werkt. Als je de bovenstaande instructies hebt gevolgd, zouden al je Posts nu vrij moeten zijn van de oude op datum gebaseerde URL-structuur (of wat je eerder had) en de nieuwe /articles/-structuur moeten gebruiken (of wat je ook hebt gekozen).

Zorg ervoor dat je de verkeersprestaties van je website de komende weken en maanden blijft volgen. Maar wees gerust in de wetenschap dat u hebt gekozen voor wat waarschijnlijk de minst riskante aanpak is voor het wijzigen van uw URL-structuur.

Wat als de prestaties afnemen?

Het eerste dat u wilt controleren is of u de test goed hebt opgezet. Open een paar van uw test-URL's en controleer of uw inhoud toegankelijk is op de nieuwe locatie.

Alles duidelijk? Goed, we gaan verder. Niet? Herlees deze post, je hebt iets gemist.

Controleer de vorige URL voor deze inhoud (de versie die in ons voorbeeld de /yyyy/mm/dd structuur zou hebben gehad). Wanneer u naar die URL navigeert, wordt u dan doorgestuurd naar de nieuwe test-URL?

Ja? Goed, we gaan verder. Nee? Nogmaals, herlees deze post, je hebt waarschijnlijk een stap overgeslagen.

Zorg er ook voor dat je deze tests uitvoert als een uitgelogde, anonieme gebruiker zonder browsercache, omdat dit de resultaten kan beïnvloeden (browsers sturen omleidingen in cachegeheugen).

Als beide controles resulteren in een succesvolle omleiding, kijk dan naar de 404-logboeken op je server om te zien of er ooit een onderbreking is geweest in de beschikbaarheid van bronnen. Onwaarschijnlijk, maar het is de moeite waard om dit uit te sluiten.

Hoewel er nog andere mogelijkheden zijn, zijn dit de meest waarschijnlijke. Als u deze opties hebt uitgesloten en de prestaties op deze test-URL's een duik hebben genomen, hebt u een paar belangrijke opties:

• Wacht een paar weken, de situatie kan verbeteren
• Wachten op de volgende grote algoritme-update van Google. Deze liggen over het algemeen 6-8 maanden uit elkaar, dus we raden dit niet aan, maar Google zou deze inhoud moeten kunnen vinden en de omleiding moeten begrijpen, dus het is mogelijk dat een volledige re-crawl van uw site in afwachting van een grote algoritme-uitrol kan resulteren in een verandering in de prestaties, maar beschouw dit als een randgeval.
• Keer uw wijzigingen terug en ga weg in de wetenschap dat u het maken van deze wijziging in de URL-structuur hebt getest en dat het rampzalig zou zijn geweest als u het globaal had gedaan, en u hebt zojuist uzelf of uw klant (of beide) een hoop hartzeer bespaard, waardoor u fantastisch bent en een grote voorsprong hebt.

Onze resultaten: Een zeer grote overwinning

In onze ervaring werkte deze methode ongelooflijk goed en de klant behield niet alleen zijn verkeer voor de testberichten, maar verbeterde dit drastisch voor bijna alle geteste berichten.

Het beste deel is dit: op geen enkel moment tijdens deze test werden ze ooit ernstig blootgesteld aan een enorm risico met hun verkeer. En het verkeer is aanzienlijk toegenomen als gevolg hiervan.

Wij zijn van mening dat dit recept het ontbrekende "geheim" is voor het veilig maken van site-brede URL-structuurwijzigingen.

Heb je hulp nodig bij het uitvoeren van deze test of wil je dat wij het voor je doen?

Geen probleem, we helpen u graag. Neem contact met ons op met wat basisgegevens over uw website en we nemen contact met u op.