Mobile-First Indexing: Γιατί το Mobile Site Καθορίζει την Κατάταξη

Η Google δεν βλέπει καν το desktop site σας από το 2018.

Η υπόθεση που κάνουν όλοι, και είναι λάθος εδώ και οκτώ χρόνια

Ρωτήστε έναν ιδιοκτήτη επιχείρησης ποια έκδοση του site του "μετράει περισσότερο" για τη Google, και το 90% θα απαντήσει αυθόρμητα: η desktop. Είναι λογικό: έτσι σχεδιάζουμε, έτσι παρουσιάζουμε το site σε πελάτες, έτσι το βλέπουμε εμείς οι ίδιοι στον υπολογιστή του γραφείου. Η desktop έκδοση είναι το "πραγματικό" site στο μυαλό μας. Το mobile είναι απλώς μια προσαρμογή του, κάτι σαν ελαφρύ αντίγραφο.

Αυτή η διαίσθηση είναι λάθος από το 2018, και παραμένει λάθος με τρόπο που κοστίζει σε πραγματική κατάταξη κάθε μέρα. Η Google δεν κοιτάει το desktop site σας για να αποφασίσει τι θα κατατάξει. Κοιτάει αποκλειστικά τη mobile έκδοση. Αν κάτι υπάρχει μόνο στο desktop (ένα κείμενο, ένα schema markup, ένα σύνολο εσωτερικών links), για τη Google αυτό απλά δεν υπάρχει.

Αυτό δεν είναι μια νέα πολιτική. Είναι η προεπιλεγμένη συμπεριφορά του index εδώ και χρόνια. Το ερώτημα δεν είναι αν σας αφορά. Είναι αν το ξέρατε.

Τι σημαίνει "mobile-first" σε επίπεδο μηχανισμού

Το mobile-first indexing δεν σημαίνει "η Google προτιμά sites που είναι mobile-friendly": αυτό θα ήταν ένας παράγοντας κατάταξης μεταξύ πολλών. Σημαίνει κάτι πιο ριζικό: ο Googlebot Smartphone είναι πλέον το πρωτεύον crawler που επισκέπτεται το site σας, και ό,τι αυτός βλέπει γίνεται η βάση για ολόκληρο το ευρετήριο, ακόμα και για το πώς κατατάσσεστε στην αναζήτηση από desktop συσκευή. Η desktop έκδοση του site σας έγινε, ουσιαστικά, δευτερεύον αντίγραφο για SEO σκοπούς.

Η ψυχολογική παγίδα: το design μας κρύβει πράγματα "για την εμπειρία"

Εδώ είναι το ενδιαφέρον κομμάτι, και είναι περισσότερο ψυχολογία παρά τεχνολογία. Οι σχεδιαστές (σωστά, από πλευράς UX) κρύβουν συχνά περιεχόμενο στο mobile "για να μην κουράσουν" τον χρήστη: accordions κλειστά από προεπιλογή, δευτερεύουσες παραγράφους που αποκόπτονται, tables που μετατρέπονται σε απλοποιημένες λίστες με λιγότερα δεδομένα. Η λογική είναι: "στο κινητό ο χρήστης θέλει λιγότερα, πιο γρήγορα".

Το πρόβλημα είναι ότι ο Googlebot δεν είναι χρήστης με περιορισμένη υπομονή σε μικρή οθόνη. Είναι ένα σύστημα που διαβάζει τον κώδικα. Αν το περιεχόμενο είναι τεχνικά παρόν στο DOM αλλά οπτικά κρυμμένο μέσω display:none επειδή βρίσκεται μέσα σε ένα κλειστό accordion, η Google το θεωρεί κανονικό περιεχόμενο. Αυτό είναι καλά τεκμηριωμένο και ασφαλές. Αλλά αν το περιεχόμενο απλώς δεν αποδίδεται καν στο mobile viewport (π.χ. μια ξεχωριστή, "ελαφριά" mobile έκδοση με λιγότερο HTML), τότε αυτό το περιεχόμενο εξαφανίζεται από το index. Οριστικά.

Η αντιδιαισθητική αλήθεια: η καλύτερη απόφαση design για conversion (λιγότερο κείμενο στο κινητό) μπορεί να είναι η χειρότερη απόφαση για SEO, αν εκτελεστεί λάθος. Η λύση δεν είναι να δείξετε λιγότερο περιεχόμενο στον χρήστη, είναι να κρύψετε οπτικά χωρίς να αφαιρέσετε τεχνικά.

Τα πέντε σημεία όπου χάνεται πραγματικά η κατάταξη

1. Ασύμμετρο περιεχόμενο μεταξύ desktop και mobile

Το πιο κοινό λάθος σε responsive sites που δεν χτίστηκαν με προσοχή: ο developer, υπό πίεση χρόνου, αφαιρεί ένα block κειμένου εντελώς από το mobile layout αντί να το κρύψει CSS-only. Ελέγξτε το με το εργαλείο "URL Inspection" στο Search Console, επιλέγοντας "View Crawled Page". Αν κάτι λείπει εκεί που το βλέπετε στο desktop, το χάσατε από το index.

2. Structured data μόνο στη desktop έκδοση

Αν το schema markup (FAQ, Product, LocalBusiness) φορτώνεται μόνο σε μία εκδοχή του template και η άλλη τρέχει διαφορετικό κώδικα, ο Googlebot Smartphone δεν θα το δει ποτέ. Καθόλου rich results, ανεξάρτητα από το πόσο σωστό είναι το schema στο desktop. Αναλύουμε πλήρως πώς να δομήσετε σωστά αυτά τα δεδομένα, και πώς να επαληθεύσετε ότι υπάρχουν και στις δύο εκδοχές, στον οδηγό schema markup οδηγός.

3. Λιγότερα εσωτερικά links στο mobile menu

Τα mega-menus του desktop συχνά περιέχουν δεκάδες εσωτερικά links προς κατηγορίες, υπηρεσίες, case studies. Το αντίστοιχο mobile hamburger menu, από σχεδιαστική απλότητα, κρατάει μόνο τα 5-6 βασικά. Αν αυτά τα επιπλέον links δεν υπάρχουν πουθενά αλλού στο mobile DOM, οι σελίδες προορισμού τους χάνουν εσωτερικό PageRank ακριβώς επειδή "δεν χωράνε" στο κινητό μενού.

4. Πιο αργό mobile rendering λόγω JavaScript

Ο Googlebot Smartphone προσομοιώνει σύνδεση με μέτριο δίκτυο και μέτρια απόδοση επεξεργαστή, όχι το γρήγορο laptop του γραφείου σας. Αν το site σας εξαρτάται σε μεγάλο βαθμό από client-side JavaScript για να αποδώσει το βασικό περιεχόμενο, το mobile rendering pass μπορεί απλά να λήξει (timeout) πριν προλάβει να δει τα πάντα. Αυτό είναι ένα πολύ συγκεκριμένο υποσύνολο ενός ευρύτερου προβλήματος που αναλύουμε στο javascript seo προβλήματα.

5. Viewport και tap targets που "τιμωρούνται" έμμεσα

Δεν υπάρχει πια ξεχωριστό "mobile-friendly" σήμα κατάταξης όπως το 2016. Έχει απορροφηθεί στα Core Web Vitals και στη γενική εμπειρία χρήστη. Αλλά αν τα κουμπιά είναι πολύ κοντά μεταξύ τους ή το κείμενο απαιτεί zoom, το bounce rate ανεβαίνει, ο χρόνος παραμονής πέφτει, και αυτά τα σήματα συμπεριφοράς επηρεάζουν έμμεσα την κατάταξη μακροπρόθεσμα, ακόμα κι αν η Google δεν σας «τιμωρεί» απευθείας.

Πώς το ελέγχουμε πρακτικά

Το εργαλείο URL Inspection είναι η αλήθεια, όχι η υπόθεση

Ανοίξτε το Search Console, βάλτε ένα URL, πατήστε "Test Live URL" και μετά "View Tested Page" > "Screenshot" και "HTML". Αυτό που βλέπετε εκεί είναι ακριβώς αυτό που βλέπει ο Googlebot Smartphone. Αν κάτι σημαντικό λείπει από αυτό το screenshot, δεν χρειάζεται εικασία: το βρήκατε.

Σύγκριση DOM μεταξύ desktop και mobile

Ανοίξτε το site σε desktop browser και σε mobile emulation (Chrome DevTools, mode "Toggle device toolbar"), κάντε "inspect" και συγκρίνετε το πλήθος στοιχείων στο DOM. Μια διαφορά μεγαλύτερη από 10-15% σε πλήθος κειμένου ή links αξίζει διερεύνηση.

Core Web Vitals ειδικά για mobile

Το PageSpeed Insights δίνει ξεχωριστό σκορ για mobile και desktop, και το mobile σκορ είναι πάντα το χειρότερο των δύο, και αυτό που μετράει περισσότερο τώρα. Αναλύουμε πλήρως τι σημαίνει κάθε metric και πώς να το βελτιώσετε στον οδηγό core web vitals τι είναι, με ειδική έμφαση στο πώς διαφέρουν οι απαιτήσεις μεταξύ mobile και desktop rendering.

Το σφάλμα που κάνουν ακόμα και τεχνικές ομάδες: ξεχωριστά mobile URLs (m.site.gr)

Αν διαχειρίζεστε ακόμα ξεχωριστό subdomain m.example.gr παράλληλα με το κύριο site, βρίσκεστε ήδη σε αρχιτεκτονική που η Google θεωρεί ξεπερασμένη και προβληματική. Αυτή η δομή απαιτεί σωστή υλοποίηση rel=alternate και rel=canonical μεταξύ των δύο εκδόσεων. Αν λείπει έστω και ένα από τα δύο tags, δημιουργείτε ακούσια duplicate content που μπερδεύει το ποια έκδοση πρέπει να ευρετηριαστεί. Το πώς εντοπίζουμε και διορθώνουμε τέτοιες περιπτώσεις αναλύεται στο duplicate content διόρθωση. Η μακροπρόθεσμη λύση δεν είναι διόρθωση tags: είναι πλήρης μετάβαση σε responsive design με ένα μοναδικό URL ανά σελίδα.

Τι σημαίνει αυτό πρακτικά για το πώς χτίζουμε sites

Στη Distarter δεν σχεδιάζουμε πρώτα το desktop και μετά "συρρικνώνουμε" για mobile. Χτίζουμε πρώτα το mobile layout, με πλήρες περιεχόμενο, πλήρες schema, πλήρη εσωτερικά links, και μετά επεκτείνουμε για τις μεγαλύτερες οθόνες. Αυτό δεν είναι ιδεολογική προτίμηση για minimalism. Είναι απόρροια ενός απλού γεγονότος: αν κάτι δεν λειτουργεί σωστά στο mobile πρώτα, δεν λειτουργεί καθόλου για τη Google, ανεξάρτητα από το πόσο εντυπωσιακό είναι στο desktop.

Αυτό συνδέεται άμεσα με το γιατί επιλέγουμε αρχιτεκτονική βασισμένη σε server-side rendering αντί για βαριά client-side frameworks: το mobile rendering pass της Google είναι πιο ανεκτικό σε στατικά αποδιδόμενο HTML παρά σε JavaScript που πρέπει να εκτελεστεί σε προσομοιωμένη μέτρια σύνδεση. Δείτε τη σχετική ερώτηση στο mobile-first indexing του FAQ μας, όπου εξηγούμε πώς αυτό επηρεάζει άμεσα τις τεχνικές αποφάσεις σε κάθε νέο project.

Η πρακτική λίστα ελέγχου

Πριν κλείσετε αυτό το άρθρο, ελέγξτε τα εξής, με αυτή τη σειρά προτεραιότητας:

Πρώτο, ανοίξτε το Search Console URL Inspection tool για τις 10 πιο σημαντικές σελίδες σας και συγκρίνετε το rendered screenshot με αυτό που βλέπετε στο desktop. Δεύτερο, ελέγξτε αν το structured data σας εμφανίζεται στο "Rich Results Test" όταν δοκιμάζετε το URL, όχι μόνο στο source code που βλέπετε στο desktop. Τρίτο, μετρήστε το πλήθος εσωτερικών links στο mobile menu έναντι του desktop menu. Τέταρτο, τρέξτε PageSpeed Insights ειδικά για mobile και δείτε αν το LCP ξεπερνάει τα 2.5 δευτερόλεπτα.

Αν κάτι από αυτά αποκαλύψει κενό, δεν έχετε ένα "μικρό τεχνικό ζήτημα". Έχετε ένα σημαντικό κομμάτι του site σας που είναι ουσιαστικά αόρατο στη Google, ανεξάρτητα από το πόσο ωραίο φαίνεται στην οθόνη του laptop σας.

Τι δείχνουν τα πραγματικά νούμερα όταν συγκρίνετε mobile και desktop σε πραγματικά sites

Δεν χρειάζεται θεωρία για να πειστείτε ότι το mobile rendering είναι πιο απαιτητικό. Αρκεί να κοιτάξετε τα Lighthouse scores των δικών μας production sites, χτισμένων ρητά με mobile-first αρχιτεκτονική. Στο Kismet Hotel, το desktop performance score είναι 99/100, το mobile 96/100: διαφορά 3 μονάδων. Στο IntelliAgTech, 98 έναντι 95. Στο Armakatone, 99 έναντι 95. Στο Diamond Glass, 99 έναντι 94. Σε επτά ολοκληρωμένα projects που έχουμε παραδώσει, η μέση διαφορά desktop-προς-mobile στο performance score είναι περίπου τρεις με τέσσερις μονάδες, ακόμα και όταν το site χτίστηκε με mobile ως πρώτη προτεραιότητα, με server-side rendering και ελάχιστο client-side JavaScript.

Αυτό το νούμερο δεν είναι τυχαίο, και δεν είναι σφάλμα υλοποίησης. Είναι το αναμενόμενο αποτέλεσμα του πώς η Google προσομοιώνει mobile συνθήκες: throttled CPU, throttled δίκτυο, μικρότερο viewport. Ακόμα και το πιο βελτιστοποιημένο site δεν μπορεί να αγνοήσει τη φυσική του κόσμου. Ένα κινητό επεξεργάζεται JavaScript πιο αργά από ένα desktop, ανεξάρτητα από το πόσο καθαρός είναι ο κώδικας. Το ερώτημα που αξίζει να θέσετε δεν είναι "γιατί υπάρχει διαφορά" αλλά "πόσο μεγάλη είναι η διαφορά στο δικό μου site, και τι κρύβεται πίσω από αυτήν". Αν η διαφορά στο δικό σας site είναι 15-20 μονάδες αντί για 3-5, δεν έχετε φυσικό περιορισμό υλικού. Έχετε αρχιτεκτονικό πρόβλημα που αξίζει διόρθωση, και η πώς να κάνω πιο γρήγορο το site μου λίστα ελέγχου είναι το πρώτο σημείο εκκίνησης.

Το ίδιο μοτίβο επαναλαμβάνεται όταν κοιτάμε projects με πιο σύνθετες απαιτήσεις πολυγλωσσίας ή διαδραστικότητας: στο Eleanna Pitsikaki, με 8 γλώσσες και persistent video background, η διαφορά είναι 4 μονάδες (96 έναντι 92). Περισσότερη πολυπλοκότητα σημαίνει μεγαλύτερο, αλλά ελεγχόμενο, χάσμα, όχι ανεξέλεγκτο. Αυτό είναι το πρακτικό όριο που θέτουμε σε κάθε νέο project: αν η διαφορά mobile-desktop ξεπερνάει τις 8-10 μονάδες, κάτι στην αρχιτεκτονική χρειάζεται επανεξέταση πριν καν συζητήσουμε περιεχόμενο.

Το audit βήμα-βήμα που τρέχουμε σε κάθε νέο πελάτη

Δεν χρειάζεται μαντεία για να μάθετε αν το site σας έχει πρόβλημα mobile-first indexing. Χρειάζεται μια συγκεκριμένη διαδικασία πέντε βημάτων, την οποία επαναλαμβάνουμε σε κάθε technical seo audit πριν αγγίξουμε οτιδήποτε άλλο.

Βήμα πρώτο: καταγραφή του πλήρους desktop περιεχομένου. Ανοίγουμε κάθε βασική σελίδα σε desktop viewport και καταγράφουμε το σύνολο του ορατού και κρυμμένου (αλλά τεχνικά παρόντος) κειμένου, όλα τα schema blocks, όλα τα εσωτερικά links.

Βήμα δεύτερο: το ίδιο σε mobile emulation με throttling ενεργό. Όχι απλή αλλαγή viewport στο DevTools. Ενεργοποιούμε και το network throttling (Slow 4G) και το CPU throttling (4x slowdown), ακριβώς όπως προσομοιώνει ο Googlebot Smartphone. Αν κάτι δεν προλαβαίνει να αποδοθεί μέσα σε λογικό χρόνο υπό αυτές τις συνθήκες, το σημειώνουμε ως ρίσκο.

Βήμα τρίτο: σύγκριση 1-προς-1. Κάθε στοιχείο που καταγράφηκε στο βήμα ένα πρέπει να εμφανίζεται και στο βήμα δύο. Οποιαδήποτε απόκλιση (ένα block κειμένου, ένα schema, ένα link) μπαίνει σε λίστα διόρθωσης με προτεραιότητα ανάλογα με το πόσο σημαντική είναι η σελίδα.

Βήμα τέταρτο: επαλήθευση μέσω Search Console. Χρησιμοποιούμε το URL Inspection tool σε κάθε σελίδα της λίστας για να δούμε τι πραγματικά βλέπει ο Googlebot, όχι τι υποθέτουμε ότι βλέπει βάσει του δικού μας emulation.

Βήμα πέμπτο: μέτρηση Core Web Vitals ειδικά για mobile, χρησιμοποιώντας το PageSpeed Insights, με ιδιαίτερη προσοχή στο LCP και το INP, τα δύο metrics που επηρεάζονται περισσότερο από τους περιορισμούς επεξεργασίας ενός μέτριου κινητού.

Αυτή η διαδικασία παίρνει 2-3 ώρες για ένα μεσαίου μεγέθους site με 20-30 βασικές σελίδες. Δεν είναι πολύπλοκη. Είναι απλώς σχολαστική. Και η σχολαστικότητα είναι ακριβώς αυτό που λείπει από τα περισσότερα "γρήγορα" audits που βασίζονται μόνο σε αυτοματοποιημένα εργαλεία χωρίς ανθρώπινη επαλήθευση κάθε ευρήματος.

Τα πέντε λάθη που κάνουν ακόμα έμπειρες ομάδες

Πρώτο, δοκιμάζουν αποκλειστικά σε desktop browser με "responsive mode". Το responsive mode του Chrome DevTools αλλάζει μόνο το viewport μέγεθος, όχι την ταχύτητα επεξεργασίας ή το δίκτυο. Μια ομάδα που ελέγχει έτσι βλέπει ένα site που "φαίνεται καλά σε κινητό" χωρίς ποτέ να δει πώς πραγματικά συμπεριφέρεται υπό πραγματικές συνθήκες throttling.

Δεύτερο, υποθέτουν ότι responsive design ισοδυναμεί με mobile-first. Δεν ισοδυναμεί. Ένα site μπορεί να είναι πλήρως responsive (να προσαρμόζεται οπτικά τέλεια σε κάθε μέγεθος οθόνης) και ταυτόχρονα να κρύβει περιεχόμενο τεχνικά στο DOM στη μικρότερη έκδοσή του, μέσω conditional rendering στο JavaScript. Η οπτική προσαρμογή δεν εγγυάται τεχνική ισοδυναμία περιεχομένου.

Τρίτο, δεν ελέγχουν ξανά μετά από κάθε redesign. Ένα site που πέρασε το τεστ mobile-parity πριν δύο χρόνια δεν είναι εγγυημένα εντάξει σήμερα, ειδικά αν προστέθηκαν νέα components ή marketing banners χωρίς σχολαστικό έλεγχο cross-device.

Τέταρτο, εμπιστεύονται τυφλά CMS plugins που ισχυρίζονται "mobile optimization". Πολλά plugins WordPress που υπόσχονται mobile βελτιστοποίηση απλά κρύβουν στοιχεία με CSS media queries χωρίς να αγγίζουν το υποκείμενο HTML: τεχνικά ασφαλές. Άλλα όμως φορτώνουν εντελώς διαφορετικό, ελαφρύτερο template για mobile user agents, κάτι που είναι ακριβώς η παγίδα που περιγράψαμε παραπάνω.

Πέμπτο, αγνοούν το πρόβλημα επειδή "το site φαίνεται γρήγορο όταν το δοκιμάζω εγώ". Το δικό σας κινητό, με γρήγορο 5G και σύγχρονο επεξεργαστή, δεν αντιπροσωπεύει τις συνθήκες που προσομοιώνει ο Googlebot. Η υποκειμενική εντύπωση ταχύτητας είναι ο χειρότερος δείκτης πραγματικής τεχνικής υγείας ενός site.

Πέντε μύθοι για το mobile-first indexing που αξίζει να ξεχάσετε

Μύθος 1: "Έχω responsive design, άρα είμαι εντάξει." Όπως εξηγήσαμε παραπάνω, η οπτική προσαρμογή δεν εγγυάται τεχνική ισοδυναμία περιεχομένου. Χιλιάδες responsive sites κρύβουν ακόμα περιεχόμενο τεχνικά στη μικρότερη έκδοσή τους.

Μύθος 2: "Το mobile-first indexing επηρεάζει μόνο την κατάταξη σε αναζητήσεις από κινητό." Λάθος, και αυτή η παρανόηση κοστίζει περισσότερο από όλες τις άλλες μαζί. Η Google χρησιμοποιεί το ίδιο ευρετήριο (αυτό που χτίστηκε βάσει mobile crawling) για ΟΛΕΣ τις αναζητήσεις, ανεξάρτητα από τη συσκευή του χρήστη που αναζητά. Αν κάτι λείπει από το mobile ευρετήριο, λείπει και από τα αποτελέσματα desktop αναζήτησης.

Μύθος 3: "Χρειάζομαι ξεχωριστή AMP έκδοση για να είμαι mobile-first." Το AMP ήταν ένα ξεχωριστό πρότυπο με δικό του σκοπό (ταχύτητα σε news feeds), όχι προαπαιτούμενο για mobile-first indexing. Η Google σταμάτησε να δίνει προνομιακή μεταχείριση σε AMP σελίδες στα αποτελέσματα εδώ και χρόνια. Ένα καλά βελτιστοποιημένο, κανονικό responsive site πετυχαίνει τα ίδια αποτελέσματα χωρίς την επιπλέον πολυπλοκότητα συντήρησης δύο εκδόσεων.

Μύθος 4: "Αν έχω σωστό rel=alternate/rel=canonical στο m.site.gr, είμαι ασφαλής." Τεχνικά σωστό, αλλά ρίσκο-γεμάτο στην πράξη. Κάθε επιπλέον στρώμα πολυπλοκότητας (δύο ξεχωριστά templates, δύο ξεχωριστές διαδικασίες ενημέρωσης περιεχομένου) είναι ένα επιπλέον σημείο όπου κάτι μπορεί να ξεσυγχρονιστεί. Η απλότητα ενός μοναδικού responsive URL ανά σελίδα παραμένει η πιο ανθεκτική αρχιτεκτονική.

Μύθος 5: "Η Google θα προσαρμοστεί τελικά και θα σταματήσει να με τιμωρεί για αυτό." Δεν πρόκειται για τιμωρία που μπορεί να αρθεί. Είναι απλή απουσία δεδομένων. Η Google δεν "τιμωρεί" ένα site που έχει κρυμμένο περιεχόμενο στο mobile. Απλώς δεν το βλέπει ποτέ, άρα δεν μπορεί ποτέ να το κατατάξει. Δεν υπάρχει "συγγνώμη" να ζητηθεί, μόνο διόρθωση να γίνει.

Η ειδική περίπτωση: PWAs, dynamic serving, και legacy AMP

Υπάρχουν τρεις πιο σπάνιες αρχιτεκτονικές που δημιουργούν ειδικές παγίδες στο mobile-first indexing, και αξίζει να τις ξέρετε αν το site σας εμπίπτει σε κάποια από αυτές.

Οι Progressive Web Apps (PWA) συχνά φορτώνουν το αρχικό περιεχόμενο μέσω service worker και client-side hydration, κάτι που μπορεί να καθυστερήσει σημαντικά τη στιγμή που το βασικό κείμενο γίνεται ορατό στο DOM. Αν αυτή η καθυστέρηση ξεπερνάει το χρονικό όριο που θέτει ο Googlebot Smartphone για rendering, το περιεχόμενο απλά δεν προλαβαίνει να καταγραφεί, ανεξάρτητα από το πόσο άψογη είναι η εμπειρία για έναν πραγματικό χρήστη που περιμένει λίγα δευτερόλεπτα παραπάνω.

Το dynamic serving (η πρακτική να επιστρέφετε διαφορετικό HTML ανάλογα με το User-Agent header, χρησιμοποιώντας τον κατάλληλο Vary header) ήταν κάποτε αποδεκτή εναλλακτική στο responsive design. Σήμερα είναι ρίσκο χωρίς ουσιαστικό όφελος: αν ο server εντοπίσει λάθος τον Googlebot Smartphone ως "desktop" user agent (κάτι σπάνιο αλλά όχι αδύνατο σε λάθος ρυθμισμένα συστήματα ανίχνευσης), το bot λαμβάνει τη λάθος έκδοση του site, με απρόβλεπτα αποτελέσματα στο ευρετήριο.

Το legacy AMP, για sites που το κράτησαν από παλιά εποχή, δημιουργεί ένα ακόμα σημείο ασυμφωνίας: αν το AMP template ενημερώνεται σε διαφορετικό κύκλο από το κύριο site (κάτι πολύ συχνό όταν η ομάδα content δεν γνωρίζει καν ότι υπάρχει ξεχωριστό AMP template), το ευρετήριο μπορεί να δείχνει παλιά εκδοχή περιεχομένου για μήνες, χωρίς κανείς να το προσέξει μέχρι να πέσει η επισκεψιμότητα.

Η κοινή συμβουλή και στις τρεις περιπτώσεις είναι η ίδια: όσο πιο πολλές παράλληλες εκδόσεις του ίδιου περιεχομένου διαχειρίζεστε, τόσο μεγαλύτερη η πιθανότητα να ξεσυγχρονιστούν. Η απλότητα δεν είναι αισθητική προτίμηση εδώ: είναι το μόνο αξιόπιστο άμυνα ενάντια σε αυτού του είδους τα σφάλματα.

Το τελικό σημείο

Η ερώτηση "πόσο καλά φαίνεται το site μας στο κινητό;" είναι λάθος ερώτηση. Δεν αφορά αισθητική. Η σωστή ερώτηση είναι: "τι ακριβώς βλέπει ο Googlebot όταν προσποιείται ότι είναι ένα μέτριο κινητό με μέτρια σύνδεση;" Επειδή αυτή η απάντηση, κυριολεκτικά, καθορίζει αν θα βρεθείτε ποτέ στο πρώτο αποτέλεσμα αναζήτησης, από οποιαδήποτε συσκευή.