Μετακόμιση Website Χωρίς να Χάσετε την Κατάταξή σας

Μια κακοστημένη μετακόμιση website μπορεί να διαγράψει χρόνια οργανικής κατάταξης μέσα σε 48 ώρες.

Γιατί το «απλά αλλάζουμε site» είναι επικίνδυνη φράση

Κανείς δεν λέει «θα ρισκάρουμε την κατάταξή μας» όταν αποφασίζει να αλλάξει CMS, να μετακομίσει σε νέο domain, ή να ξαναχτίσει το site από την αρχή. Το σκέφτονται σαν design project: νέο look, νέα λειτουργικότητα, καλύτερη εμπειρία χρήστη. Το τεχνικό ρίσκο μένει αόρατο μέχρι να συμβεί, γιατί δεν φαίνεται πουθενά στο mockup που εγκρίνει κανείς σε ένα meeting.

Η αλήθεια είναι πιο σκληρή: η Google δεν βλέπει «το ίδιο site με καλύτερο design». Βλέπει, τεχνικά, ένα εντελώς διαφορετικό σύνολο URLs, με πιθανόν διαφορετική δομή, διαφορετικό περιεχόμενο ανά σελίδα, και καμία εγγύηση ότι η παλιά της γνώση για το ποια σελίδα απαντάει σε ποιο ερώτημα εξακολουθεί να ισχύει. Κάθε μετανάστευση είναι, από την οπτική της Google, μια στιγμή μηδενισμού εμπιστοσύνης που πρέπει να ξαναχτιστεί, εκτός αν προσέξετε ρητά να της πείτε τι ακριβώς άλλαξε και πού πήγε το καθετί.

Τι σημαίνει πραγματικά «migration»: τέσσερις διαφορετικές περιπτώσεις

Ο όρος migration καλύπτει τέσσερα εντελώς διαφορετικά σενάρια ρίσκου, και το πρώτο λάθος είναι να τα αντιμετωπίζετε όλα με την ίδια διαδικασία. Αλλαγή domain (π.χ. από παλιό.gr σε νέο.com) είναι το πιο ριψοκίνδυνο, γιατί η Google πρέπει να μεταφέρει ολόκληρη την ιστορία αυθεντίας ενός domain σε άλλο. Αλλαγή CMS ή τεχνολογικής βάσης (π.χ. WordPress σε Next.js) με το ίδιο domain είναι λιγότερο ριψοκίνδυνη σε επίπεδο domain authority, αλλά ιδιαίτερα επικίνδυνη σε επίπεδο δομής URLs, γιατί συχνά αλλάζουν slugs, καταλήξεις, ιεραρχία φακέλων.

Αναδιάρθρωση URLs χωρίς αλλαγή domain ή CMS (π.χ. από /blog/2024/post-title σε /insights/post-title) φαίνεται μικρή αλλαγή αλλά έχει το ίδιο ρίσκο απώλειας αν δεν χαρτογραφηθεί σωστά. Και το τέταρτο, το πιο συχνά παραβλεπόμενο: αλλαγή πρωτοκόλλου ή subdomain: από HTTP σε HTTPS, από www. σε χωρίς www., ή ενοποίηση δύο subdomains σε ένα. Φαίνεται τεχνική λεπτομέρεια, αλλά η Google το αντιμετωπίζει ως διαφορετικό URL, άρα χρειάζεται την ίδια πειθαρχία redirects όπως και μια πλήρης αλλαγή domain.

Το πλήρες πλάνο redirects: η καρδιά κάθε επιτυχημένης μετάβασης

Το ενιαίο πράγμα που καθορίζει αν μια μετανάστευση θα διατηρήσει την κατάταξη είναι ένας πλήρης, ένα-προς-ένα χάρτης 301 redirects από κάθε παλιό URL προς το πιο σχετικό νέο URL. Όχι blanket redirect όλων προς την αρχική σελίδα. Αυτό αντιμετωπίζεται από τη Google ως ένδειξη χαμηλής ποιότητας και προκαλεί απότομη πτώση bounce rate, γιατί ο επισκέπτης περίμενε συγκεκριμένο περιεχόμενο και βρίσκεται αλλού.

Η διαδικασία ξεκινά πριν αγγίξετε οτιδήποτε: εξάγετε πλήρη λίστα όλων των indexed URLs του παλιού site από το Search Console και από ένα πλήρες crawl με εργαλείο σαν το Screaming Frog. Για κάθε URL, βρίσκετε το ακριβές αντίστοιχο στο νέο site. Αν δεν υπάρχει ακριβές αντίστοιχο, βρίσκετε το πιο σχετικό θεματικά, ποτέ απλά την αρχική σελίδα ως προεπιλογή. Μόνο όταν καμία σχετική σελίδα δεν υπάρχει, η αρχική είναι αποδεκτή τελευταία επιλογή. Αναλύουμε πλήρως τη λογική πίσω από τη σωστή επιλογή 301 έναντι 404 έναντι 410 στο άρθρο broken links διόρθωση, που καλύπτει το ίδιο πρόβλημα σε μικρότερη κλίμακα.

Τι καταγράφουμε πριν αγγίξουμε οτιδήποτε

Το πιο συχνό λάθος δεν συμβαίνει κατά τη μετάβαση. Συμβαίνει πριν, όταν κανείς δεν μπήκε στον κόπο να καταγράψει την υπάρχουσα κατάσταση. Χωρίς αυτή τη φωτογραφία, δεν έχετε τρόπο να μετρήσετε αν κάτι χάθηκε μετά. Καταγράφουμε πάντα: πλήρη λίστα indexed URLs με τα δικά τους metrics επισκεψιμότητας από τους τελευταίους 12 μήνες, τις κορυφαίες σελίδες σε οργανικά backlinks (γιατί αυτές χρειάζονται το πιο προσεκτικό redirect), τις σελίδες που κατατάσσονται για τα πιο εμπορικά σημαντικά keywords, και ένα πλήρες screenshot του Search Console Coverage report ως baseline σύγκρισης.

Αυτή η καταγραφή δεν είναι γραφειοκρατία. Είναι το μόνο εργαλείο που θα έχετε αργότερα για να απαντήσετε στην ερώτηση «χάσαμε κάτι, ή απλά νιώθουμε ανασφάλεια επειδή όλα άλλαξαν;» Χωρίς baseline, κάθε συζήτηση μετά τη μετάβαση γίνεται εικασία.

Η μέρα της μετάβασης: η σωστή σειρά ενεργειών

Η μετάβαση δεν γίνεται ποτέ «στην τύχη» ένα Σάββατο βράδυ χωρίς σχέδιο. Η σωστή σειρά είναι: πρώτα, ενεργοποιείτε το νέο site με πλήρες redirect map ήδη έτοιμο και ελεγμένο σε staging περιβάλλον. Δεύτερο, υποβάλλετε αμέσως το νέο XML sitemap στο Search Console και ζητάτε επανασάρωση. Τρίτο, ελέγχετε δειγματοληπτικά τα 20-30 πιο σημαντικά URLs χειροκίνητα, ανοίγοντας κάθε παλιά διεύθυνση και επιβεβαιώνοντας ότι το redirect οδηγεί στο σωστό, σχετικό νέο URL, όχι απλώς ότι «κάπου» ανακατευθύνει.

Τέταρτο, ενημερώνετε εσωτερικούς συνδέσμους ώστε να δείχνουν κατευθείαν στα νέα URLs, χωρίς να περνάνε μέσα από το redirect. Κάθε redirect που παρακάμπτεται εξοικονομεί crawl budget και χρόνο φόρτωσης. Πέμπτο, ελέγχετε ότι το robots.txt του νέου site δεν μπλοκάρει κατά λάθος τίποτα κρίσιμο. Πρόκειται για ένα εξαιρετικά συχνό λάθος: ένα staging robots.txt με Disallow: / παραμένει κατά λάθος στο production μετά το launch.

Οι πρώτες δύο εβδομάδες: τι παρακολουθούμε καθημερινά

Η δουλειά δεν τελειώνει με το launch. Μόλις αρχίζει. Τις πρώτες δύο εβδομάδες παρακολουθούμε καθημερινά το Coverage report στο Search Console για απότομη αύξηση σε errors, το ποσοστό των παλιών URLs που έχουν πλέον καταγραφεί ως redirected στο ίδιο εργαλείο, και την οργανική επισκεψιμότητα σε ημερήσια βάση συγκρινόμενη με το ίδιο διάστημα πριν τη μετάβαση.

Μια μικρή, προσωρινή πτώση επισκεψιμότητας 5-15% τις πρώτες ημέρες είναι φυσιολογική και αναμενόμενη: η Google χρειάζεται χρόνο να επανασαρώσει και να μεταφέρει σήματα. Μια πτώση πάνω από 30%, ή που δεν ανακάμπτει μέσα σε δύο-τρεις εβδομάδες, σημαίνει ότι κάτι στο redirect map ή στο rendering του νέου site έχει πρόβλημα, και χρειάζεται άμεση διερεύνηση, όχι αναμονή.

Πέντε λάθη που βλέπουμε συχνότερα σε αποτυχημένες μεταναστεύσεις

Πρώτο: redirect chains, όπου παλιό URL ανακατευθύνει σε ενδιάμεσο URL που ανακατευθύνει σε τελικό. Κάθε επιπλέον hop προσθέτει καθυστέρηση και σε ακραίες περιπτώσεις η Google σταματάει να ακολουθεί την αλυσίδα μετά από ένα όριο. Δεύτερο: redirect προς σελίδα με διαφορετικό, μη σχετικό περιεχόμενο. Τεχνικά «λειτουργεί» το redirect, αλλά η Google δεν μεταφέρει την ίδια αξία σε ένα άσχετο θέμα.

Τρίτο, ιδιαίτερα συχνό σε αλλαγές CMS: το νέο site χτίζεται με διαφορετικό rendering μοντέλο από το παλιό, συχνά πιο εξαρτημένο από client-side JavaScript, χωρίς κανείς να το προσέξει γιατί οπτικά η σελίδα φαίνεται κανονική. Αναλύουμε πλήρως πώς να ελέγξετε αυτό ακριβώς το ρίσκο στο ssr vs csr seo. Τέταρτο: canonical tags που δείχνουν ακόμα στο παλιό domain μετά τη μετάβαση, μπερδεύοντας τη Google σχετικά με ποιο URL είναι η «πραγματική» σελίδα. Πέμπτο: robots.txt ή meta noindex tags που έμειναν από το staging περιβάλλον και κρύβουν κατά λάθος ολόκληρο το νέο site από την ευρετηρίαση, εντελώς αθόρυβα, μέχρι κάποιος να το προσέξει εβδομάδες μετά.

Το edge case: αλλαγή domain ΚΑΙ CMS ταυτόχρονα

Το πιο ριψοκίνδυνο σενάριο που αναλαμβάνουμε είναι όταν μια επιχείρηση θέλει να αλλάξει domain και CMS στην ίδια στιγμή, συνήθως γιατί το rebranding και το τεχνικό rebuild συμπίπτουν χρονικά από επιχειρηματική ανάγκη. Η σύστασή μας σχεδόν πάντα: διαχωρίστε τα δύο γεγονότα χρονικά, ακόμα κι αν αυτό σημαίνει ένα ενδιάμεσο, προσωρινό βήμα. Αλλάξτε πρώτα το CMS στο ίδιο domain, αφήστε δύο έως τέσσερις εβδομάδες σταθεροποίησης, και μετά προχωρήστε στην αλλαγή domain. Ο λόγος είναι απλός: αν κάτι πάει στραβά, θέλετε να ξέρετε ποιο από τα δύο ταυτόχρονα γεγονότα το προκάλεσε, όχι να ψάχνετε ανάμεσα σε δύο πιθανές αιτίες ταυτόχρονα ενώ η επισκεψιμότητα πέφτει.

Αν η επιχείρηση επιμένει να γίνουν ταυτόχρονα λόγω πραγματικού επιχειρηματικού περιορισμού, το ελάχιστο που απαιτούμε είναι διπλάσιος χρόνος προετοιμασίας στο redirect mapping και καθημερινή παρακολούθηση τις πρώτες τρεις εβδομάδες αντί για δύο.

Υπάρχει και μια λιγότερο προφανής συνέπεια που ελάχιστες ομάδες σκέφτονται: μια μετανάστευση δεν επηρεάζει μόνο πώς σας βλέπει η Google, επηρεάζει και πώς σας «διαβάζουν» τα AI εργαλεία που κάνουν retrieval σε πραγματικό χρόνο. Αν το llms.txt σας ή το structured data αναφέρουν ακόμα το παλιό domain ή παλιά URLs μετά τη μετάβαση, ένα μοντέλο μπορεί να παραθέσει έναν σύνδεσμο που πλέον δεν οδηγεί πουθενά σωστά. Το ελέγχουμε πάντα ρητά ως μέρος της ίδιας διαδικασίας, όπως εξηγούμε στο llms.txt τι είναι.

Πόσο καιρό παίρνει να «σταθεροποιηθεί» η κατάταξη

Με σωστό redirect mapping και καθαρό rendering, μια τυπική μετανάστευση δείχνει πλήρη ανάκαμψη επισκεψιμότητας μέσα σε 4 έως 8 εβδομάδες: το διάστημα που χρειάζεται η Google να επανασαρώσει το μεγαλύτερο μέρος του site και να μεταφέρει πλήρως τα σήματα αυθεντίας στα νέα URLs. Χωρίς σωστό redirect mapping, η εικόνα είναι πολύ διαφορετική: έχουμε δει περιπτώσεις όπου το 70-90% της οργανικής επισκεψιμότητας χάθηκε μέσα σε δύο εβδομάδες και ποτέ δεν ανακτήθηκε πλήρως, γιατί οι σελίδες που κατατάσσονταν απλά έπαψαν να υπάρχουν, χωρίς κανένα σήμα προς τη Google για το πού πήγε το περιεχόμενό τους.

Η διαφορά ανάμεσα σε αυτά τα δύο σενάρια δεν είναι τύχη ή αλγοριθμική ιδιοτροπία. Είναι το αν κάποιος έκανε τη δουλειά καταγραφής και χαρτογράφησης πριν πατήσει το κουμπί «go live», ή αν το θεώρησε λεπτομέρεια που «θα την κοιτάξουμε μετά».

Η λίστα ελέγχου σε μία σελίδα

Πριν: πλήρης καταγραφή indexed URLs, backlinks, top keywords, baseline Coverage screenshot. Κατά τη μετάβαση: πλήρες 301 redirect map ελεγμένο σε staging, XML sitemap υποβολή άμεση, δειγματοληπτικός χειροκίνητος έλεγχος 20-30 URLs, εσωτερικοί σύνδεσμοι ενημερωμένοι, robots.txt καθαρό από ρυθμίσεις staging. Μετά: καθημερινή παρακολούθηση Coverage και επισκεψιμότητας για δύο εβδομάδες, άμεση διερεύνηση αν η πτώση ξεπεράσει το 20-30% ή δεν ανακάμψει σε τρεις εβδομάδες.

Το πρακτικό συμπέρασμα

Μια μετανάστευση website δεν είναι επικίνδυνη επειδή αλλάζει η τεχνολογία. Είναι επικίνδυνη επειδή η σχέση ανάμεσα σε ένα παλιό URL και ένα νέο σπάει σιωπηλά, εκτός αν κάποιος τη χαρτογραφήσει ρητά, ένα-προς-ένα, πριν συμβεί οτιδήποτε. Αν σχεδιάζετε μια μετάβαση τους επόμενους μήνες, το πρώτο βήμα δεν είναι να διαλέξετε νέο design. Είναι να ζητήσετε από όποιον την αναλαμβάνει να σας δείξει το redirect map πριν καν εγκρίνετε ημερομηνία launch. Αν δεν υπάρχει τέτοιο έγγραφο, δεν έχετε σχέδιο μετάβασης, έχετε ελπίδα.

Η ένσταση: «Θα το τρέξουμε πρώτα σε staging, άρα είμαστε ασφαλείς»

Το ακούμε συχνά από τεχνικές ομάδες, και είναι μισή αλήθεια που κρύβει ένα πλήρες ρίσκο. Το staging περιβάλλον είναι εξαιρετικό για να πιάσετε λειτουργικά προβλήματα: σπασμένα forms, layout bugs, αργή φόρτωση εικόνων. Δεν είναι καθόλου χρήσιμο για να πιάσετε το πραγματικό SEO ρίσκο μιας μετάβασης, για έναν απλό λόγο: η Google δεν βλέπει ποτέ το staging περιβάλλον σας. Δεν το σαρώνει, δεν έχει καμία ιστορία γι' αυτό, και δεν μπορεί να επιβεβαιώσει αν το redirect map λειτουργεί σωστά σε πραγματικές συνθήκες crawl budget, πραγματικά backlinks που χτυπάνε πραγματικά URLs.

Το πρόβλημα εμφανίζεται συχνά σε ένα συγκεκριμένο σημείο: η ομάδα ελέγχει το redirect map χειροκίνητα σε staging, ανοίγοντας 10-15 URLs και επιβεβαιώνοντας ότι «λειτουργεί». Αυτό επιβεβαιώνει ότι ο μηχανισμός redirect λειτουργεί τεχνικά. Δεν επιβεβαιώνει ότι το redirect map είναι πλήρες: ότι κάθε ένα από τα, ας πούμε, 340 indexed URLs του παλιού site έχει πράγματι έναν προορισμό. Ένα ελλιπές redirect map περνάει εντελώς απαρατήρητο σε staging, γιατί κανείς δεν δοκιμάζει το URL #287 που δεν θυμάται καν κανείς ότι υπήρχε, μέχρι να πέσει η επισκεψιμότητα μετά το launch.

Η σωστή χρήση του staging είναι συμπληρωματική, όχι υποκατάστατη: επιβεβαιώνει ότι ο μηχανισμός redirect δουλεύει τεχνικά πριν το launch, αλλά η πληρότητα του redirect map ελέγχεται πάντα ενάντια στην πλήρη λίστα indexed URLs που εξάγατε από το Search Console -το βήμα που περιγράψαμε νωρίτερα σε αυτό το άρθρο- όχι ενάντια σε μια τυχαία δειγματοληψία που «φαίνεται» αντιπροσωπευτική. Αν η ερώτηση «πόσα URLs έχει το redirect map σε σχέση με πόσα indexed URLs είχε το παλιό site» δεν έχει ξεκάθαρη αριθμητική απάντηση πριν το launch, το staging test δεν σας προστατεύει από τίποτα σοβαρό.

301 εναντίον 302 εναντίον redirect μέσω JavaScript: γιατί η επιλογή καθορίζει το αποτέλεσμα

Δεν είναι όλα τα redirects ίδια, παρόλο που οπτικά φαίνονται πανομοιότυπα στον επισκέπτη, και οι τρεις τύποι τον οδηγούν στο ίδιο σημείο. Η διαφορά είναι αόρατη στον άνθρωπο και κρίσιμη για τη Google. Το 301 redirect λέει ρητά «αυτό το URL μετακόμισε μόνιμα, μεταφέρετε την αξία κατάταξης στο νέο URL». Είναι ο μόνος τύπος redirect που η Google αντιμετωπίζει ως πλήρη μεταφορά σήματος αυθεντίας. Σε μια μετανάστευση, είναι σχεδόν πάντα ο σωστός τύπος.

Το 302 redirect λέει το αντίθετο: «αυτό είναι προσωρινό, η αρχική σελίδα θα επιστρέψει σύντομα, μην μεταφέρεις τίποτα ακόμα». Χρησιμοποιείται σωστά για πραγματικά προσωρινές καταστάσεις -π.χ. μια σελίδα προϊόντος εκτός αποθέματος για δύο εβδομάδες- αλλά είναι το πιο συχνό τεχνικό λάθος που βλέπουμε σε μεταναστεύσεις: ένας developer ρυθμίζει redirects βιαστικά, το framework προεπιλέγει σε 302, και κανείς δεν το προσέχει γιατί ο επισκέπτης καταλήγει ακριβώς εκεί που έπρεπε. Η Google, όμως, δεν μεταφέρει authority σε ένα 302 -περιμένει, θεωρώντας τη μετάβαση προσωρινή- και το αποτέλεσμα είναι ακριβώς η αργή, ατελής ανάκαμψη κατάταξης που περιγράψαμε νωρίτερα, χωρίς καμία εμφανή αιτία στα επιφανειακά εργαλεία ελέγχου.

Το redirect μέσω JavaScript (client-side, π.χ. window.location.href) είναι το χειρότερο από τα τρία σε μια μετανάστευση, γιατί εξαρτάται πλήρως από το αν ο crawler εκτελεί JavaScript πριν ακολουθήσει το redirect: κάτι που η Google κάνει ασυνεπώς και με σημαντική καθυστέρηση σε σχέση με τον αρχικό crawl. Ένα site που βασίζεται σε JS redirects για τη μετάβαση κινδυνεύει η Google να ευρετηριάσει το παλιό URL ως κενή σελίδα-φάντασμα για εβδομάδες, πριν καν προλάβει να ακολουθήσει το redirect. Ο πρακτικός κανόνας: κάθε redirect μιας πραγματικής μετανάστευσης πρέπει να είναι 301, να ρυθμίζεται στο επίπεδο του server ή του framework routing (όχι σε επίπεδο client-side script), και να ελέγχεται ρητά με εργαλείο που βλέπει το HTTP status code, όχι μόνο το πού καταλήγει οπτικά ο επισκέπτης.

Ένα παράδειγμα με νούμερα: μια μετανάστευση με 1.240 URLs

Ας δούμε πώς μοιάζει όλο αυτό σε πραγματική κλίμακα. Ένα ενημερωτικό site με 1.240 indexed URLs μετακόμισε από WordPress σε νέα τεχνολογική βάση, διατηρώντας το ίδιο domain. Η προετοιμασία περιλάμβανε πλήρη εξαγωγή της λίστας από το Search Console (1.240 URLs), crawl επιβεβαίωσης με Screaming Frog (1.198 URLs εντοπίστηκαν ενεργά, η διαφορά ήταν ήδη 404 σελίδες παλαιότερα), και χειροκίνητη αντιστοίχιση κάθε ενός από τα 1.198 URLs σε νέο προορισμό, δουλειά που πήρε τρεις εργάσιμες μέρες για δύο ανθρώπους.

Το redirect map είχε τελικά 1.198 εγγραφές: 1.050 ένα-προς-ένα σε αντίστοιχη νέα σελίδα με το ίδιο θέμα, 130 σε θεματικά σχετική σελίδα όπου η ακριβής αντιστοιχία δεν υπήρχε πια, και 18 προς την αρχική σελίδα ως έσχατη λύση, για περιεχόμενο που είχε πραγματικά καταργηθεί χωρίς αντικαταστάτη. Αυτό το τελευταίο νούμερο -18 στα 1.198, δηλαδή 1,5%- είναι το σημείο αναφοράς που χρησιμοποιούμε: αν πάνω από 5% των redirects καταλήγουν στην αρχική σελίδα, το redirect map δεν έγινε με αρκετή προσοχή.

Τις πρώτες δύο εβδομάδες μετά το launch, η οργανική επισκεψιμότητα έπεσε κατά 9% -μέσα στο αναμενόμενο εύρος 5-15% που περιγράψαμε νωρίτερα- και ανέκαμψε πλήρως στις 5 εβδομάδες, με 96% των URLs να εμφανίζονται ξανά ως «Ευρετηριασμένες» στο Coverage report μέσα στις πρώτες τρεις εβδομάδες. Το κόστος της προετοιμασίας -τρεις ανθρωποημέρες πριν καν αγγιχτεί ο κώδικας- ήταν μικρότερο από το κόστος μίας εβδομάδας χαμένης επισκεψιμότητας σε ένα site αυτού του μεγέθους, πόσο μάλλον από το ρίσκο μόνιμης απώλειας που περιγράψαμε στην αρχή του άρθρου. Ο αριθμός που αξίζει να κρατήσετε από αυτό το παράδειγμα δεν είναι το ποσοστό ανάκαμψης, είναι η αναλογία: τρεις ανθρωποημέρες προετοιμασίας για 1.198 URLs, περίπου 15 λεπτά ανά URL όταν η δουλειά γίνεται συστηματικά αντί βιαστικά.

Τι αλλάζει όταν μεταναστεύει ένα e-shop με 50.000 προϊόντα

Η χειροκίνητη αντιστοίχιση URL-προς-URL που περιγράψαμε παραπάνω λειτουργεί άψογα σε ένα site με 1.000-1.500 σελίδες. Καταρρέει εντελώς σε ένα e-shop με 50.000 προϊόντα, γιατί καμία ομάδα δεν έχει τον χρόνο να αντιστοιχίσει χειροκίνητα 50.000 μεμονωμένες εγγραφές μέσα σε ρεαλιστικό χρονοδιάγραμμα. Η λογική πρέπει να αλλάξει από «ανά URL» σε «ανά μοτίβο».

Σε αυτή την κλίμακα, η δουλειά ξεκινάει με ομαδοποίηση URLs σε κατηγορίες βάσει δομής -π.χ. όλα τα URLs τύπου /product/{id}/{slug} προς νέα δομή /proionta/{slug}- και τη ρύθμιση redirect κανόνων (pattern-based rules) που καλύπτουν χιλιάδες URLs με μία γραμμή κώδικα, αντί για χιλιάδες ξεχωριστές εγγραφές. Το ρίσκο εδώ είναι διαφορετικό από τη μικρή κλίμακα: δεν είναι η παράλειψη ενός URL, είναι το λάθος σε έναν κανόνα που επηρεάζει ταυτόχρονα χιλιάδες σελίδες. Ένα λάθος regex στο redirect rule μπορεί να στείλει 8.000 προϊόντα σε λάθος κατηγορία ταυτόχρονα, αντί ένα.

Το δεύτερο πράγμα που αλλάζει είναι η προτεραιοποίηση. Δεν μπορείτε να ελέγξετε χειροκίνητα 50.000 redirects πριν το launch, οπότε ελέγχετε δειγματοληπτικά, αλλά με στρατηγική δειγματοληψία -όχι τυχαία 30 URLs, αλλά τα top 200 σε επισκεψιμότητα και backlinks (που καλύπτουν συνήθως το 60-70% της συνολικής αξίας του καταλόγου), plus ένα τυχαίο δείγμα 100 URLs από τη «μακριά ουρά» για να πιάσετε συστηματικά προβλήματα στα pattern rules.

Το τρίτο, ειδικό σε e-shops: τα προϊόντα εξαντλούνται ή καταργούνται μόνιμα, με πραγματική συχνότητα, ανεξάρτητα από τη μετανάστευση. Ο κανόνας διαφέρει από το «θεματικά σχετική σελίδα» των μικρών sites: για καταργημένα προϊόντα χωρίς αντικαταστάτη, το redirect πρέπει να πηγαίνει στην κατηγορία-γονέα, ποτέ στην αρχική σελίδα του eshop -η κατηγορία διατηρεί το θεματικό πλαίσιο που η αρχική σελίδα καταστρέφει εντελώς.