Verhuizen van een website

Op Zoekmachine sturen staan wat technieken beschreven om aan bezoekers en zoekmachines (automatisch) duidelijk te maken dat een website verhuist is.

Voordat de bezoekers doorgestuurd kunnen worden moet de site wel zelf eerst verkassen. Liefst met zo min mogelijk verstoring. Omdat verschillende hosting bedrijven andere instellingen op hun systemen hebben kan een perfect werkende site bij de ene host plotseling kuren vertonen bij een andere. Denk hierbij aan instellingen als register globals,safe mode minder rechten m.b.t. het aanpassen van de .htaccess file, andere codering van wachtwoorden (in mysql!). Ook configuraties die sterk op elkaar lijken kunnen toch verschillen, zelfs op servers bij dezelfde host.

Als een (deel van) een website verhuist van locatie of naar een ander domein is de verhuizing vrij eenvoudig:

1. Regel een nieuwe plek/domein
2. Bestanden kopieren naar nieuwe site.
3. Testen en eventueel aanpassen
4. Als de oude site dynamisch is deze sluiten
   • De veranderde bestanden verhuizen, weer testen
5. Bezoekers doorsturen.

Verhuizen naar https

De site verhuizen van http naar https is relatief eenvoudig. Meer hierover staat elders.

Verhuizen van een domein

Iets lastiger wordt het als je een website met domein en al wilt verhuizen.

Een domein bestaat uit twee delen, de registratie en de hosting. Verhuizen van de registratie is meestal niet voor elkaar te krijgen zonder dat de website enige tijd niet bereikbaar is. Verhuizing van de hosting kan als het handig aangepakt wordt met een minimale verstoring. Mits de twee oude en nieuwe hosting de juiste mogelijkheden heeft

Idealiter plaats je de website eerst op de nieuwe server, test je deze en als alles goed werkt verhuis je de site definitief. Nog mooier is als je de site kunt testen op de echte domeinnaam. Dat kan.

Bij de nieuwe hosting heb je een nieuw pakket, maar de domeinnaam verhuis je er (nog) niet heen. Als het goed is heb je wel een IP adres waar de site komt te staan. Ook kun je al je domein opgeven in de admin omgeving van de nieuwe host zodat je op de disk een plek krijgt om de site neer te zetten. De webserver bij de nieuwe host weet dan ook wat deze moet doen met jouw domein. Hoe het precies in zijn werk gaat is afhankelijk van de gebruikte admin-omgeving. Essentie is dat je het nieuwe domein bekend maakt in de admin-omgeving zonder het dns aan te passen.

Verhuis (kopieer) de bestanden van de oude locatie naar de nieuwe.

Ga nu op zoek naar het ‘hosts bestand op de computer waarop je test (dus niet op je host). Op de meeste unix-achtige systemen staat deze in /etc, op windows systemen bijvoorbeeld in c:\windows\system32\drivers\etc. Waarschijnlijk staat er al wat in:

Voeg het ip-nummer van je nieuwe host en je domein naar toe (let wel je eigen ip -nummer niet die uit het voorbeeld)

Viola, je kunt vanaf de computer waar je deze wijziging heb gemaakt verbinding maken met je nieuwe host, terwijl je bezoekers naar de oude locatie gaan.

Zoals je ziet komt er nogal wat kijken bij een verhuizing. De afzondelijke stappen zijn niet ingewikkeld alleen is het zaak het overzicht te houden en niets over te slaan. Hulp nodig? Neem contact op!

De uiteindelijke verhuizing

Als de domein registratie bij de oude aanbieder van domeinnamen blijft is het noodzakelijk dat je zelf de DNS entry kunt aanpassen. Hoe dat precies in zijn werk zou kunnen gaan is afhankelijk van je aanbieder. Dan is het een kwestie van simpel de DNS aan te passen bij je domein registratie.

Mocht de domein registratie ook verhuizen zul je dat bij de nieuwe ( en oude) host moeten opgeven. Hoe het precies gaat kun je het beste bij de nieuwe hosting navragen. Bovenstaande truck met het aanpassen van het IP nummer werkt ook als je domein aan het verhuizen is, je nieuwe host moet het domein echter wel actief hebben in de configuratie van de webserver. Het werkt ook met een helemaal nieuw domein, voor de tijd dat de registratie bij het SIDN nog niet doorgevoerd is op de servers.

De gegevens in je DNS hebben een bepaalde geldigheid de Time-to-live (TTL), deze staat standaard vaak op 3600 seconden. Als een computer een verzoek heeft gedaan om jouw domeinnaam te vertalen in een ip nummer zal deze pas na 6 uur weer een verzoek doen. Dat betekend dat voor een periode van maximaal zes uur bezoekers naar het verkeerde ip nummer gestuurd zouden kunnen worden. Als je veel bezoekers hebt en niet op een rustig moment kunt wachten is het verstandig eerst de TTL omlaag te brengen naar bijvoorbeeld 60 seconden, dan de oude TTL af te wachten.

Dynamische site

Veel websites zijn gebaseerd op een scripting tool ( php, asp,VB, Java< , ruby) en een vorm van database, de database kan bestaan uit een verzameling bestanden ( flat file database) of een echte database als mysql. Voor het verhuizen van een website is het van belang te weten welke gegevens wanneer wijzigen.

In sommige gevallen wordt wel gebruik gemaakt van scripts, maar is de site eigenlijk statisch de onderliggende gegevens wijzigen niet of nauwelijks, het is zonder meer haalbaar de site voor enkele dagen te bevriezen. Dat wil zeggen geen wijzigingen meer op de oude locatie, terwijl aan de website op de nieuwe locatie gewerkt wordt. De website blijft op de oude locatie gewoon werken.

Maar stel je hebt een actieve blog hebt en tussen de eerste kopieerslag van de gegevens naar de nieuwe plek en de uiteindelijke overschakeling zitten enkele dagen van testen een aanpassen. Dan zijn de gegevens op de nieuwe plek uiteraard niet meer compleet en up-to-date; en in dit geval gat er ook zinvolle belangrijke informatie verloren. De database moet nog een keer gemigreerd worden. En het is van belang bij te houden welke aanpassingen gemaakt zijn, en welke daarvan op de dynamische inhoud betrekking hebben.

De informatie die veranderd kan ook minder cruciaal zijn, bijvoorbeeld statistische gegevens; jammer dat er wat informatie mist maar niet van wezenlijk belang. Als je een CMS hebt waar tijdens de test fase geen nieuwe artikelen bijgekomen zijn kun je het voor lief nemen dat gegevens als statistieken of commentaren niet op de nieuwe site komen en verloren zijn gegaan. Ook kan het eenvoudiger en sneller zijn een enkel artikel op de nieuwe site opnieuw te plaatsen in plaats van de hele database nog een keer over te zetten. Keuzes te over, alles is afhankelijk van de hoeveelheid gegevens, het soort gegevens, de tijd die nodig was voor het kopiëren van de gegevens enzovoorts. Indien mogelijk is het wel verstandig de activiteiten op de oude site zo veel mogelijk te beperken.