Πώς να μεταφέρετε ένα domain χωρίς να καταβαραθρώσετε τις κατατάξεις σας στην αναζήτηση

Η αλλαγή domain είναι ένα από τα λίγα SEO projects όπου ένα τεχνικά μικρό λάθος μπορεί να γίνει πολύ ορατό πολύ γρήγορα. Ένα redirect που λείπει, μια αποκλεισμένη διαδρομή crawl ή ένα ξεχασμένο canonical μπορούν να μετατρέψουν ένα απλό rebrand σε εβδομάδες αστάθειας στις κατατάξεις.

Κάποια μετακίνηση είναι φυσιολογική. Οι μηχανές αναζήτησης χρειάζονται χρόνο για να κάνουν crawl τα παλιά URLs, να ανακαλύψουν τα redirects, να επεξεργαστούν τα σήματα και να σταθεροποιήσουν το νέο domain στο index. Ο στόχος δεν είναι να αποφύγετε κάθε πτώση. Ο στόχος είναι να κάνετε τη μετεγκατάσταση βαρετή: ένα παλιό URL οδηγεί σε ένα ισοδύναμο νέο URL, ο server απαντά καθαρά και τίποτα σημαντικό δεν εξαφανίζεται.

Ξεκινήστε με απογραφή, όχι με έναν κανόνα redirect

Η πιο συνηθισμένη αποτυχία σε μια μετεγκατάσταση είναι να αντιμετωπίζεται ως εργασία ρύθμισης server. Δεν είναι. Είναι εργασία αρχιτεκτονικής πληροφορίας που τυχαίνει να καταλήγει σε ρύθμιση server.

Πριν αγγίξετε το DNS, φτιάξτε μια λίστα με URLs που έχουν σημασία:

• URLs που λαμβάνουν οργανική επισκεψιμότητα
• URLs με εξωτερικά backlinks
• URLs που φέρνουν conversions, παράγουν leads ή υποστηρίζουν campaigns
• Canonical URLs που βρίσκονται αυτή τη στιγμή στο XML sitemap σας
• PDFs, εικόνες και αρχεία προς λήψη που συνδέονται εξωτερικά
• Υψηλής αξίας legacy URLs που μπορεί να μην εμφανίζονται στην τρέχουσα πλοήγηση

Για κάθε παλιό URL, ορίστε έναν προορισμό στο νέο domain. Στις περισσότερες περιπτώσεις, αυτός ο προορισμός πρέπει να είναι η ίδια σελίδα με την ίδια πρόθεση. Αν το /pricing γίνει https://newdomain.com/pricing, αυτό είναι απλό. Αν τρεις παλιές σελίδες προϊόντων συγχωνεύονται σε έναν νέο οδηγό, τεκμηριώστε αυτή την απόφαση σκόπιμα.

Αποφύγετε το εύκολο μοτίβο: να κάνετε redirect τα πάντα στη νέα αρχική σελίδα. Είναι βολικό, αλλά πετάει τη συνάφεια. Τόσο οι μηχανές αναζήτησης όσο και οι χρήστες περιμένουν ο προορισμός να απαντά στην ίδια ανάγκη με το αρχικό URL.

Διατηρήστε τη δομή URL όπου μπορείτε

Μια μετεγκατάσταση domain είναι ευκολότερη όταν τα paths παραμένουν σταθερά. Η μετακίνηση από oldsite.com/blog/example σε newsite.com/blog/example είναι πολύ πιο καθαρή από το να αλλάξετε domain, CMS, slugs, δομή φακέλων και περιεχόμενο ταυτόχρονα.

Μερικές φορές ένα redesign ή μια μετεγκατάσταση CMS κάνει τις αλλαγές URL αναπόφευκτες. Αν συμβαίνει αυτό, διαχωρίστε τις αποφάσεις:

1. Τι αλλάζει επειδή αλλάζει το domain;
2. Τι αλλάζει επειδή αλλάζει η δομή του site;
3. Τι διαγράφεται, συγχωνεύεται ή ξαναγράφεται;

Όσο περισσότερες μεταβλητές εισάγετε, τόσο δυσκολότερο γίνεται να διαγνώσετε προβλήματα αργότερα. Αν η μετεγκατάσταση είναι σημαντική και το τρέχον site αποδίδει καλά, εξετάστε το ενδεχόμενο να μετακινήσετε πρώτα το domain και να κάνετε redesign αργότερα.

Χρησιμοποιήστε μόνιμα redirects με ένα hop

Για μια πραγματική μετεγκατάσταση domain, χρησιμοποιήστε server-side 301 ή 308 redirects από τα παλιά URLs στα νέα ισοδύναμά τους. Τα προσωρινά redirects είναι για προσωρινές καταστάσεις. Τα JavaScript redirects, τα meta refreshes και τα soft redirects είναι ασθενέστερα σήματα και σπάνε πιο εύκολα.

Οι στόχοι των redirects σας είναι απλοί:

• Κάθε σημαντικό παλιό URL επιστρέφει μόνιμο redirect.
• Κάθε redirect πηγαίνει απευθείας στον τελικό προορισμό.
• Το HTTP κάνει καθαρά redirect σε HTTPS.
• Οι παραλλαγές www και non-www αντιμετωπίζονται με συνέπεια.
• Τα redirects δεν εξαρτώνται από εύθραυστη συμπεριφορά query-string, εκτός αν είναι απαραίτητο.

Μια κακή αλυσίδα μοιάζει έτσι:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

Αυτό μπορεί τελικά να καταλήξει στη σωστή σελίδα, αλλά είναι αργό, δυσκολότερο για crawl και πιο πιθανό να κρύψει λάθη. Στοχεύστε σε ένα hop από κάθε παλιά παραλλαγή προς το τελικό νέο URL.

Όταν επαληθεύετε τη συμπεριφορά, επιθεωρήστε τις πραγματικές HTTP responses αντί να εμπιστεύεστε αυτό που δείχνει ο browser. Ο οδηγός μας για debugging redirects και HTTP headers σε production είναι χρήσιμος εδώ, επειδή οι browsers είναι υπερβολικά ευγενικοί: ακολουθούν την αλυσίδα και κρύβουν τα άσχημα σημεία.

Προετοιμάστε DNS και certificates πριν από το launch

Το DNS δεν μεταφέρει άμεσα κατατάξεις, αλλά ένα κακό DNS μπορεί να κάνει μια μετεγκατάσταση να φαίνεται χαλασμένη. Μειώστε τις τιμές TTL πριν από το παράθυρο launch, ώστε οι αλλαγές να διαδοθούν πιο προβλέψιμα. Επιβεβαιώστε ότι το νέο domain έχει σωστά records για web traffic, email και οποιαδήποτε απαραίτητα subdomains.

Χρειάζεστε επίσης έγκυρα TLS certificates και για τα δύο domains. Αυτό είναι εύκολο να παραβλεφθεί. Το παλιό domain πρέπει ακόμη να εξυπηρετεί HTTPS redirects μετά τη μετεγκατάσταση. Αν λήξει το certificate του, χρήστες και crawlers μπορεί να συναντήσουν προειδοποιήσεις browser πριν φτάσουν ποτέ στο νέο site.

Αν η μετακίνηση επηρεάζει το email, μην το αντιμετωπίσετε ως εκ των υστέρων σκέψη. Οι αλλαγές domain συχνά σπάνε SPF, DKIM, DMARC, MX records, tracking links και transactional mail. Για μια υπενθύμιση σχετικά με τα records που έχουν σημασία, δείτε τον developer-friendly οδηγό μας για MX, SPF, DKIM και DMARC.

Ελέγξτε canonicals, internal links και sitemaps

Μετά το launch, το νέο domain πρέπει να συμπεριφέρεται σαν να ήταν πάντα η canonical βάση του περιεχομένου.

Αυτό σημαίνει:

• Τα canonical tags δείχνουν στα νέα URLs, όχι στο παλιό domain.
• Τα internal links χρησιμοποιούν το νέο domain ή root-relative paths.
• Τα XML sitemaps περιέχουν μόνο τελικά, indexable νέα URLs.
• Τα hreflang annotations, αν χρησιμοποιούνται, αναφέρονται στα νέα URLs.
• Τα Open Graph, structured data και alternate links ενημερώνονται.
• Το Robots.txt δεν αποκλείει σημαντικές ενότητες.

Μη δημοσιεύετε ένα sitemap γεμάτο παλιά URLs περιμένοντας ότι τα redirects θα το καθαρίσουν. Ένα sitemap πρέπει να είναι λίστα URLs που θέλετε να γίνουν indexed. Μετά από μια μετεγκατάσταση, αυτό σημαίνει τελικά URLs στο νέο domain.

Προσέξτε επίσης για αντιφάσεις στα canonicals. Μια σελίδα που κάνει redirect από το παλιό στο νέο αλλά έχει canonical που δείχνει πίσω στο παλιό domain στέλνει ανάμεικτα σήματα. Οι μηχανές αναζήτησης συνήθως μπορούν να διαχειριστούν κάποια ασυνέπεια, αλλά δεν πρέπει να τους το ζητάτε.

Μην αλλάξετε τα πάντα την ημέρα του launch

Μια μετεγκατάσταση είναι ήδη αρκετά μεγάλο γεγονός. Αν είναι δυνατόν, αποφύγετε να τη συνδυάσετε με μεγάλο content pruning, ξαναγράψιμο templates, αλλαγές πλοήγησης, αλλαγές στο JavaScript rendering ή νέο performance profile.

Αυτό δεν είναι δεισιδαιμονία. Είναι πειθαρχία στο debugging. Αν οι κατατάξεις πέσουν μετά το launch, πρέπει να ξέρετε αν η αιτία είναι η αντιστοίχιση redirects, η πρόσβαση για crawl, αλλαγμένο περιεχόμενο, πιο αργό rendering, ελλιπή structured data ή κάτι άλλο.

Κρατήστε το αρχικό launch όσο πιο κοντά στο παλιό site είναι πρακτικά δυνατό. Μόλις το νέο domain σταθεροποιηθεί, κάντε μεγαλύτερες editorial και design αλλαγές σε μικρότερα batches.

Πείτε στις μηχανές αναζήτησης τι άλλαξε

Στο Google Search Console, επαληθεύστε και τα δύο domains, το παλιό και το νέο. Έπειτα χρησιμοποιήστε το εργαλείο Change of Address όταν η μετακίνηση είναι αλλαγή σε επίπεδο domain και το περιεχόμενο μεταφέρεται σε νέο domain. Υποβάλετε το νέο sitemap μετά το launch.

Αυτό δεν αντικαθιστά τα redirects. Τα υποστηρίζει. Οι μηχανές αναζήτησης εξακολουθούν να χρειάζονται crawlable, persistent redirects για να κατανοήσουν την αντιστοίχιση σε επίπεδο URL.

Για το Bing και άλλες μηχανές αναζήτησης, χρησιμοποιήστε τα webmaster tools τους όπου είναι διαθέσιμα. Ενημερώστε επίσης τα σημεία που ελέγχετε: social profiles, business listings, ad destinations, email footers, τεκμηρίωση, partner links και canonical references σε syndicated content.

Δεν θα ενημερωθούν όλα τα εξωτερικά links, και αυτό είναι εντάξει. Αλλά τα πιο σημαντικά πρέπει να ενημερωθούν. Αν ένας σημαντικός partner, app marketplace, documentation portal ή press page συνδέεται με το παλιό domain, ζητήστε ενημέρωση.

Παρακολουθήστε τα σωστά πράγματα μετά το launch

Οι πρώτες ημέρες μετά τη μετεγκατάσταση πρέπει να είναι ενεργή παρακολούθηση, όχι γιορτή.

Ελέγξτε:

• Server logs για crawl activity στα παλιά και νέα domains
• 404s και απρόσμενα 5xx errors
• Redirect chains και loops
• Indexing status στο Search Console
• Sitemap discovery και processing
• Organic landing pages και query patterns
• Conversion paths που εξαρτώνται από παλιά URLs
• Analytics filters και referral exclusions

Να περιμένετε θόρυβο στα reports. Ορισμένα analytics tools αντιμετωπίζουν το νέο domain ως νέα property, εκτός αν ρυθμιστούν σωστά. Ορισμένα dashboards συγκρίνουν traffic παλιού domain με traffic νέου domain και κάνουν τη μετεγκατάσταση να φαίνεται χειρότερη από ό,τι είναι.

Η ορατότητα στην αναζήτηση μπορεί να παρουσιάζει διακυμάνσεις για μερικές εβδομάδες. Αυτό που δεν θέλετε είναι ένα μοτίβο όπου υψηλής αξίας παλιά URLs γίνονται crawl επανειλημμένα αλλά δεν κάνουν σωστό redirect, ή όπου νέες σελίδες ανακαλύπτονται αλλά επισημαίνονται ως duplicates του παλιού domain.

Το performance επίσης δεν πρέπει να αγνοείται. Αν το νέο domain λανσαριστεί με βαρύτερα templates, χαλασμένο caching ή μη βελτιστοποιημένα assets, οι χρήστες μπορεί να νιώσουν τη μετεγκατάσταση ως επιβράδυνση. Αν χρησιμοποιείτε το Lighthouse ως μέρος των ελέγχων σας, διαβάστε το με τις προτεραιότητες κατά νου· το άρθρο μας για το πώς να διαβάζετε ένα Lighthouse report χωρίς πανικό εξηγεί πώς να ξεχωρίζετε τα ουσιαστικά ζητήματα από τον θόρυβο.

Κρατήστε το παλιό domain για μεγάλο διάστημα

Μην αφήσετε το παλιό domain να λήξει αφού η μετεγκατάσταση «δουλέψει». Κρατήστε το registered, κρατήστε τα certificates έγκυρα και διατηρήστε τα redirects ενεργά για όσο το δυνατόν περισσότερο. Στην πράξη, αυτό συχνά σημαίνει χρόνια.

Τα παλιά links συνεχίζουν να υπάρχουν σε blog posts, bookmarks, τεκμηρίωση, PDFs, emails και social posts. Τα redirects είναι η γέφυρα ανάμεσα σε αυτό το ιστορικό αποτύπωμα και το νέο domain. Αν τα απενεργοποιήσετε πολύ νωρίς, σπάτε τις διαδρομές των χρηστών και σπαταλάτε συσσωρευμένα σήματα.

Κρατήστε επίσης ένα αντίγραφο του redirect map και των launch notes σας. Έξι μήνες αργότερα, όταν κάποιος ρωτήσει γιατί ένα legacy URL συμπεριφέρεται με συγκεκριμένο τρόπο, θα χαρείτε που το τεκμηριώσατε.

<!-- tool-cta:start -->

💡 Δοκιμάστε αυτό: Μετά τη μετάβαση, ανιχνεύστε τα παλιά URL σας μέσω του Redirect Checker για να επιβεβαιώσετε ότι το καθένα επιλύεται με ένα μόνο 301 hop στη σωστή νέα σελίδα.

<!-- tool-cta:end -->

Μια λογική checklist μετεγκατάστασης

Πριν από το launch:

• Επαληθεύστε και τα δύο domains στο Search Console.
• Κάντε crawl το τρέχον site και εξαγάγετε σημαντικά URLs.
• Δημιουργήστε ένα one-to-one redirect map.
• Μειώστε τα DNS TTLs.
• Προετοιμάστε TLS certificates για το παλιό και το νέο domain.
• Ενημερώστε canonicals, internal links, hreflang, structured data και sitemaps.
• Δοκιμάστε redirects σε staging ή σε ελεγχόμενο περιβάλλον.

Την ημέρα του launch:

• Κάντε deploy τα redirects.
• Επιβεβαιώστε τη συμπεριφορά HTTP προς HTTPS.
• Δοκιμάστε σημαντικά δείγματα URL από κάθε τύπο template.
• Υποβάλετε το νέο sitemap.
• Χρησιμοποιήστε το εργαλείο Change of Address όπου είναι κατάλληλο.
• Παρακολουθήστε server errors, redirect loops και blocked resources.

Μετά το launch:

• Παρακολουθήστε crawl errors και indexing reports.
• Ενημερώστε σημαντικά εξωτερικά links όπου μπορείτε.
• Συγκρίνετε traffic με βάση την πρόθεση της landing page, όχι μόνο τα συνολικά μεγέθη domain.
• Κρατήστε τα redirects live επ' αόριστον.
• Καθυστερήστε άσχετα redesign ή content experiments μέχρι να σταθεροποιηθεί η μετακίνηση.

Οι μετεγκαταστάσεις domain δεν είναι χωρίς ρίσκο, αλλά είναι διαχειρίσιμες. Οι κατατάξεις συνήθως υποφέρουν όταν η μετεγκατάσταση στέλνει ασαφή σήματα: redirects που λείπουν, αλλαγμένο περιεχόμενο, αντιφατικά canonicals, αποκλεισμένοι crawlers ή ένα ξεχασμένο παλιό domain. Δώστε στις μηχανές αναζήτησης και στους χρήστες έναν καθαρό χάρτη, και η μετακίνηση γίνεται πολύ λιγότερο δραματική.