XML Sitemap & Robots.txt: Τι Χρειάζεται Κάθε Site

Δύο αρχεία κειμένου, μηδέν σχεδιασμό, και καθορίζουν αν η Google βρίσκει καν το site σας.

Δύο αρχεία που όλοι έχουν, και ελάχιστοι καταλαβαίνουν

Κάθε site έχει, θεωρητικά, ένα robots.txt και ένα sitemap.xml. Τα περισσότερα CMS τα δημιουργούν αυτόματα, με προεπιλογές που κανείς δεν έχει ξανακοιτάξει από τη μέρα εγκατάστασης. Αυτό είναι το πρόβλημα: δύο από τα πιο κρίσιμα τεχνικά αρχεία ενός site αντιμετωπίζονται σαν "αυτόματο πράγμα που απλά υπάρχει", ενώ στην πραγματικότητα είναι οι δύο βασικές οδηγίες που δίνετε στη Google για το πώς να αντιμετωπίσει ολόκληρο το site σας.

Η αντιδιαισθητική αλήθεια εδώ: δεν χρειάζεστε πολύπλοκη λογική. Χρειάζεστε σωστή λογική. Ένα robots.txt τριών γραμμών που κάνει το σωστό πράγμα είναι απείρως καλύτερο από ένα robots.txt εκατό γραμμών γεμάτο κανόνες που κανείς δεν έχει ελέγξει αν λειτουργούν όπως νομίζει.

Robots.txt: τι κάνει πραγματικά (και τι δεν κάνει ποτέ)

Δεν είναι μηχανισμός ασφαλείας

Το πρώτο και πιο επικίνδυνο λάθος: πολλοί νομίζουν ότι το Disallow: /admin/ στο robots.txt "κρύβει" έναν φάκελο από τον κόσμο. Δεν κρύβει τίποτα. Λέει απλώς σε ευγενικά bots "μην το επισκεφθείτε" — και τα ευγενικά bots (Googlebot, Bingbot) το σέβονται. Οποιοσδήποτε άνθρωπος ή κακόβουλο bot μπορεί να διαβάσει το ίδιο το robots.txt (είναι δημόσιο αρχείο) και να δει ακριβώς ποιους φακέλους θέλατε να κρύψετε — που συχνά λειτουργεί σαν χάρτης για το πού να ψάξει κανείς πρώτα. Ευαίσθητο περιεχόμενο προστατεύεται με authentication, όχι με robots.txt.

Ελέγχει crawling, όχι ευρετηρίαση

Δεύτερο κρίσιμο σημείο σύγχυσης: το Disallow εμποδίζει τον Googlebot να επισκεφθεί μια σελίδα, αλλά αν η σελίδα έχει ήδη backlinks από αλλού, η Google μπορεί να την κρατήσει στο ευρετήριο χωρίς περιεχόμενο ("Ελάχιστες πληροφορίες διαθέσιμες για αυτή τη σελίδα" στα αποτελέσματα) — γιατί ποτέ δεν είδε τι υπάρχει μέσα για να αποφασίσει να την αφαιρέσει. Αν στόχος σας είναι μια σελίδα να μην εμφανίζεται καθόλου στη Google, το σωστό εργαλείο είναι meta robots noindex, όχι robots.txt disallow. Αναλύουμε αναλυτικά πότε προκύπτει αυτή η σύγχυση και πώς λύνεται στο crawl budget seo.

Ένα πραγματικό παράδειγμα, από το δικό μας site

Αντί να σας δώσουμε γενικές οδηγίες, δείτε ακριβώς το robots.txt configuration που τρέχει στο distarter.com αυτή τη στιγμή:

export default function robots(): MetadataRoute.Robots {
    return {
        rules: [
            {
                userAgent: '*',
                allow: '/',
                disallow: ['/api/', '/checkout/'],
            },
            { userAgent: 'GPTBot', allow: '/' },
            { userAgent: 'Claude-Web', allow: '/' },
            { userAgent: 'anthropic-ai', allow: '/' },
            { userAgent: 'PerplexityBot', allow: '/' },
            { userAgent: 'GoogleOther', allow: '/' },
        ],
        sitemap: `${SITE_URL}/sitemap.xml`,
    };
}

Παρατηρήστε τι ΔΕΝ κάνουμε: δεν μπλοκάρουμε δεκάδες φακέλους "για κάθε ενδεχόμενο". Μπλοκάρουμε ακριβώς δύο πράγματα που δεν έχουν κανένα λόγο να ευρετηριαστούν — τα εσωτερικά API endpoints (/api/) και τη ροή πληρωμής (/checkout/), που είναι λειτουργικά τμήματα του site, όχι περιεχόμενο για αναζήτηση. Όλα τα υπόλοιπα είναι ανοιχτά.

Και παρατηρήστε τι κάνουμε ξεχωριστά: δίνουμε ρητή, ονομαστική άδεια σε συγκεκριμένα AI crawlers — GPTBot (OpenAI), Claude-Web και anthropic-ai (Anthropic), PerplexityBot, και GoogleOther (το bot που η Google χρησιμοποιεί για πειραματικά προϊόντα, ξεχωριστό από τον κύριο Googlebot). Αυτό δεν είναι απλώς "άσε τα όλα μπουν" — είναι συνειδητή απόφαση ορατότητας σε AI αναζητήσεις, ένα θέμα που αναλύουμε σε πλήρες βάθος στο robots.txt ai bots, με τη λογική πίσω από το ποια bots αξίζει να επιτρέψετε ρητά και ποια όχι.

XML Sitemap: ο χάρτης, όχι η πρόσκληση

Το sitemap δεν εγγυάται ευρετηρίαση

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

Αυτόματη δημιουργία αντί για χειροκίνητη συντήρηση

Το χειρότερο μοτίβο που βλέπουμε: sitemap.xml αρχεία που ενημερώθηκαν χειροκίνητα μία φορά, τη μέρα που παραδόθηκε το site, και ποτέ ξανά. Έξι μήνες αργότερα λείπουν 40 νέα άρθρα και περιλαμβάνονται 10 σελίδες που έχουν διαγραφεί. Η μόνη βιώσιμη προσέγγιση είναι το sitemap να παράγεται δυναμικά, απευθείας από την πηγή δεδομένων του site, ώστε να είναι πάντα, αυτόματα, ακριβές.

Έτσι δουλεύει το δικό μας: το sitemap σαρώνει προγραμματιστικά τα routes της εφαρμογής, τα δεδομένα υπηρεσιών, τα δεδομένα portfolio, και όλα τα άρθρα Insights κατευθείαν από τον φάκελο περιεχομένου:

// 4. Insights (from content/insights/*.md)
const insightRoutes = getAllInsightSlugs().flatMap((slug) =>
    localizedEntries(`/insights/${slug}`, 'monthly', 0.6)
);

Αυτό σημαίνει ότι το άρθρο που διαβάζετε αυτή τη στιγμή προστέθηκε αυτόματα στο sitemap τη στιγμή που το αρχείο του δημιουργήθηκε στον φάκελο περιεχομένου — χωρίς κανείς να χρειαστεί να αγγίξει το ίδιο το sitemap. Αν χτίζετε πάνω σε ένα σύστημα (CMS, framework) που δεν κάνει αυτό αυτόματα, αυτό είναι το πρώτο πράγμα που αξίζει να διορθώσετε πριν ανησυχήσετε για οτιδήποτε άλλο τεχνικό.

Priority και changeFrequency: μικρά σήματα, όχι μαγικοί αριθμοί

Πολλοί ξοδεύουν χρόνο βελτιστοποιώντας τις τιμές priority (0.0 έως 1.0) σαν να είναι κρίσιμος παράγοντας κατάταξης. Η Google το έχει πει ξεκάθαρα: αυτά τα πεδία είναι ελαφριές υποδείξεις, όχι δεσμευτικές οδηγίες. Στο δικό μας sitemap, δίνουμε στην αρχική σελίδα priority 1, σε υπηρεσίες και portfolio 0.7, και σε άρθρα Insights 0.6 — μια λογική ιεράρχηση της σχετικής σημασίας κάθε τύπου σελίδας, αλλά χωρίς αυταπάτη ότι αυτός ο αριθμός θα αλλάξει δραματικά την κατάταξη. Το πραγματικό σήμα προτεραιότητας είναι τα εσωτερικά links — κάτι που αναλύουμε στο δικό του άρθρο για την εσωτερική διασύνδεση.

Το κομμάτι που ελάχιστα sites κάνουν σωστά: hreflang σε πολυγλωσσικό sitemap

Αν το site σας υπάρχει σε πολλαπλές γλώσσες, το sitemap πρέπει να δηλώνει ρητά ποια εκδοχή κάθε σελίδας αντιστοιχεί σε ποια γλώσσα-στόχο, μέσω hreflang alternates. Χωρίς αυτό, η Google μπορεί να αντιμετωπίσει τις γλωσσικές εκδοχές ως ανταγωνιστικό, αντί για συμπληρωματικό περιεχόμενο — ακριβώς το πρόβλημα duplicate content που αναλύουμε στο duplicate content διόρθωση.

Στο δικό μας sitemap, κάθε route δεν παράγει μία εγγραφή αλλά μία ανά υποστηριζόμενη γλώσσα, με πλήρη σύνολο εναλλακτικών:

function localizedEntries(
    route: string,
    changeFrequency: MetadataRoute.Sitemap[number]['changeFrequency'],
    priority: number,
): MetadataRoute.Sitemap {
    const href = route === '' ? '/' : route;
    const languages: Record<string, string> = {};
    for (const locale of routing.locales) {
        languages[locale] = `${SITE_URL}${getPathname({ href, locale })}`;
    }
    languages['x-default'] = `${SITE_URL}${getPathname({ href, locale: routing.defaultLocale })}`;

    return routing.locales.map((locale) => ({
        url: `${SITE_URL}${getPathname({ href, locale })}`,
        lastModified: new Date(),
        changeFrequency,
        priority: route === '' ? 1 : priority,
        alternates: { languages },
    }));
}

Κάθε γλωσσική εκδοχή μιας σελίδας "ξέρει" πού βρίσκονται όλες οι αδερφές εκδοχές της, συμπεριλαμβανομένου ενός ρητού x-default για επισκέπτες χωρίς σαφή γλωσσική προτίμηση. Αυτό είναι το ίδιο πρόβλημα, στην ίδια λύση, που εφαρμόσαμε πρώτη φορά σε πραγματικό project για μια καλλιτέχνιδα με site σε οκτώ γλώσσες — δείτε πώς λειτούργησε στην πράξη στο πολυγλωσσικό website next-intl. Η πλήρης τεχνική εξήγηση του hreflang, με τα συχνά λάθη υλοποίησης, βρίσκεται στο hreflang οδηγός.

Πότε ξαναχτίζετε και τα δύο αρχεία από την αρχή

Αν αλλάζετε πλατφόρμα, domain, ή αναδιοργανώνετε ολόκληρη τη δομή URLs του site σας, το robots.txt και το sitemap δεν πρέπει απλώς να "ακολουθήσουν" — πρέπει να είναι μέρος του πλάνου μετάβασης από την πρώτη μέρα, ώστε η Google να ανακαλύψει τη νέα δομή γρήγορα αντί να την ανακαλύψει τυχαία μέσα σε μήνες. Το πλήρες πλάνο βημάτων για μια μετάβαση χωρίς απώλεια κατάταξης βρίσκεται στο migration website seo.

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

Ανοίξτε το yourdomain.gr/robots.txt αυτή τη στιγμή. Ελέγξτε: υπάρχει γραμμή Sitemap: στο τέλος που δείχνει στο σωστό, τρέχον sitemap; Δεν μπλοκάρεται κατά λάθος κάτι που θέλετε ευρετηριασμένο (ελέγξτε ιδιαίτερα wildcard κανόνες όπως Disallow: /*?* που μπορούν ακούσια να μπλοκάρουν όλα τα URLs με παραμέτρους); Υπάρχουν ρητοί κανόνες για τα σύγχρονα AI crawlers ή απλά δεν αναφέρονται καθόλου;

Μετά ανοίξτε το yourdomain.gr/sitemap.xml. Μετρήστε πόσα URLs περιέχει και συγκρίνετέ το νοερά με το πραγματικό πλήθος σελίδων του site σας. Αν η διαφορά είναι μεγάλη προς οποιαδήποτε κατεύθυνση — πολύ λιγότερα (λείπει περιεχόμενο) ή πολύ περισσότερα (περιλαμβάνει σελίδες που δεν έπρεπε) — βρήκατε το πρώτο σας τεχνικό ζήτημα προτεραιότητας.

Δύο αρχεία, μερικές γραμμές λογικής, μηδέν σχεδιασμού. Και καθορίζουν αν η Google βρίσκει το site σας μέσα σε ώρες ή το ανακαλύπτει τυχαία, αργά, μερικώς, σε έξι μήνες.

Το λάθος που ακυρώνει το ίδιο σας το sitemap

Υπάρχει ένα λάθος που βλέπουμε σε σχεδόν έναν στους τρεις ελέγχους που κάνουμε, και είναι τόσο βασικό που φαίνεται απίθανο: σελίδες με meta robots noindex να εμφανίζονται μέσα στο ίδιο sitemap.xml. Η λογική σύγκρουση είναι προφανής μόλις τη δεις γραμμένη: το sitemap λέει στη Google "ευρετηρίασε αυτή τη σελίδα, είναι σημαντική", ενώ η ίδια η σελίδα λέει "μην με ευρετηριάσεις καθόλου". Η Google δεν παγώνει μπερδεμένη — απλά αγνοεί το sitemap ως αναξιόπιστη πηγή για εκείνο το URL, και σταδιακά χάνει την εμπιστοσύνη της σε ολόκληρο το αρχείο.

Πώς συμβαίνει αυτό στην πράξη; Συνήθως όχι από απροσεξία σχεδιασμού, αλλά από ασυγχρονισμό μεταξύ δύο συστημάτων. Το CMS παράγει το sitemap αυτόματα από όλα τα δημοσιευμένα άρθρα. Ξεχωριστά, κάποιος προσθέτει noindex σε παλιές, ξεπερασμένες σελίδες — π.χ. προσφορές που έληξαν, ή διπλότυπο περιεχόμενο κατηγορίας — χωρίς να ενημερώσει τη λογική παραγωγής του sitemap ώστε να τις εξαιρέσει αυτόματα. Τα δύο συστήματα δεν μιλάνε μεταξύ τους, και το αποτέλεσμα είναι ένα sitemap γεμάτο αντιφάσεις που κανείς δεν βλέπει, γιατί κανείς δεν το διαβάζει γραμμή προς γραμμή.

Ο έλεγχος είναι απλός και παίρνει λιγότερο από δέκα λεπτά: πάρτε τη λίστα URLs από το sitemap.xml, τρέξτε την μέσα από οποιοδήποτε crawler (ακόμα και δωρεάν εργαλείο με όριο 500 σελίδων αρκεί για τα περισσότερα μικρά sites), και φιλτράρετε για meta robots noindex. Αν βρείτε έστω και μία αντιστοιχία, έχετε βρει ένα σήμα ασυνέπειας που η Google καταγράφει αθόρυβα κάθε φορά που ξανακατεβάζει το αρχείο. Η διόρθωση δεν είναι να αφαιρέσετε το noindex — είναι να αφαιρέσετε το URL από το sitemap, γιατί η πρόθεσή σας ήταν ήδη ξεκάθαρη στη σελίδα.

Το όριο των 50.000 URLs: πότε χρειάζεστε sitemap index

Ελάχιστοι ιδιοκτήτες site μαθαίνουν ποτέ αυτόν τον αριθμό, μέχρι να τον χτυπήσουν: ένα μεμονωμένο αρχείο sitemap.xml δεν επιτρέπεται να περιέχει πάνω από 50.000 URLs, ούτε να ξεπερνά τα 50MB μη συμπιεσμένο μέγεθος. Για ένα blog με 200 άρθρα, αυτό το όριο είναι αφηρημένο και άσχετο. Για ένα e-commerce με 80.000 προϊόντα, ή ένα real estate site που παράγει σελίδα ανά ακίνητο, είναι ζήτημα που θα εμφανιστεί σίγουρα, όχι ίσως.

Η λύση δεν είναι να κόψετε το sitemap στη μέση και να ελπίζετε. Είναι το πρότυπο sitemap index: ένα κεντρικό αρχείο sitemap.xml που δεν περιέχει URLs σελίδων, αλλά αναφορές σε άλλα, μικρότερα αρχεία sitemap — π.χ. sitemap-products-1.xml, sitemap-products-2.xml, sitemap-blog.xml — καθένα κάτω από το όριο. Η Google διαβάζει πρώτα το index, μετά κατεβάζει καθένα από τα επιμέρους αρχεία ξεχωριστά. Είναι ακριβώς η ίδια λογική με το πώς οργανώνουμε το δικό μας sitemap ανά τύπο περιεχομένου (υπηρεσίες, portfolio, insights) αλλά σε μεγαλύτερη κλίμακα, με διαχωρισμό όχι μόνο ανά τύπο αλλά και ανά πλήθος.

Το πρακτικό όφελος πέρα από τη συμμόρφωση με το όριο: μπορείτε να παρακολουθείτε την απόδοση ευρετηρίασης ξεχωριστά ανά κατηγορία μέσα στο Search Console. Αν το sitemap-products-3.xml δείχνει ότι μόνο 40% των URLs του έχουν ευρετηριαστεί ενώ το sitemap-blog.xml δείχνει 95%, ξέρετε ακριβώς πού είναι το πρόβλημα ποιότητας περιεχομένου, χωρίς να ψάχνετε σε μια αδιαφοροποίητη λίστα 80.000 γραμμών. Το σπάσιμο σε επιμέρους αρχεία δεν είναι μόνο τεχνική αναγκαιότητα στην κλίμακα — είναι δωρεάν διαγνωστικό εργαλείο, αν το οργανώσετε σωστά εξαρχής.

Η ερώτηση που ακούμε συχνά: "Χρειάζομαι καν robots.txt αν δεν έχω τίποτα να κρύψω;"

Η ερώτηση που ακούμε συχνότερα από ιδιοκτήτες μικρών sites: "Δεν έχω admin panel εκτεθειμένο, δεν έχω checkout, δεν έχω τίποτα ευαίσθητο — χρειάζομαι καν robots.txt;" Η διαισθητική απάντηση είναι "όχι, τι να μπλοκάρεις". Η σωστή απάντηση είναι διαφορετική: ένα robots.txt με μηδέν κανόνες disallow είναι ακόμα απολύτως απαραίτητο, όχι για να μπλοκάρει κάτι, αλλά για να δηλώσει τη θέση του sitemap.

Χωρίς robots.txt, η Google δεν έχει έναν σταθερό, προβλέψιμο τρόπο να ανακαλύψει πού βρίσκεται το sitemap.xml σας, εκτός αν το υποβάλετε χειροκίνητα στο Search Console — κάτι που οι περισσότεροι κάνουν μία φορά και ξεχνούν, ενώ το robots.txt δηλώνει τη διεύθυνση κάθε φορά που ένα οποιοδήποτε bot επισκέπτεται το site, ανεξάρτητα αν έχετε ξαναϋποβάλει τίποτα. Ένα άδειο, καθαρό robots.txt με μία μόνο γραμμή Sitemap: και allow: '/' παντού είναι το ελάχιστο, σωστό default — όχι το να μην έχετε καθόλου αρχείο.

Υπάρχει και δεύτερος λόγος, λιγότερο προφανής: η απουσία robots.txt επιστρέφει σφάλμα 404 σε κάθε bot που το ζητάει — και μερικά bots, ιδιαίτερα αυστηρά ρυθμισμένα crawlers, ερμηνεύουν την απουσία του αρχείου ως αβεβαιότητα και μειώνουν συντηρητικά τον ρυθμό crawling μέχρι να βεβαιωθούν ότι δεν υπάρχουν περιορισμοί. Ένα σαφές, έστω κενό, robots.txt αφαιρεί αυτή την αβεβαιότητα άμεσα. Το κόστος δημιουργίας του είναι τρία λεπτά. Το κόστος της απουσίας του είναι αόρατο, αργό, και δύσκολο να συνδεθεί αιτιωδώς με τίποτα συγκεκριμένο — που είναι ακριβώς ο λόγος που κανείς δεν το προτεραιοποιεί, μέχρι να το ελέγξει κάποιος συστηματικά. Το πλήρες πλαίσιο για το τι πρέπει να ελέγχεται συστηματικά, και με ποια συχνότητα, βρίσκεται στο πόσο συχνά χρειάζεστε SEO audit.

robots.txt disallow, meta noindex, ή canonical: ποιο εργαλείο για ποιο πρόβλημα

Τρία εργαλεία, τρεις εντελώς διαφορετικές δουλειές, και η σύγχυση μεταξύ τους είναι υπεύθυνη για τα περισσότερα τεχνικά λάθη ευρετηρίασης που βλέπουμε. Το robots.txt disallow σταματάει το crawling — η Google δεν επισκέπτεται καν τη σελίδα. Χρησιμοποιήστε το μόνο για σελίδες που δεν έχουν κανένα λόγο να δει bot ποτέ: εσωτερικά API endpoints, admin panels, staging περιβάλλοντα.

Το meta robots noindex επιτρέπει το crawling αλλά απαγορεύει την ευρετηρίαση — η Google επισκέπτεται τη σελίδα, τη διαβάζει, αλλά δεν την εμφανίζει ποτέ στα αποτελέσματα. Χρησιμοποιήστε το για σελίδες που υπάρχουν λειτουργικά (φόρμες επιβεβαίωσης, σελίδες "ευχαριστούμε" μετά από φόρμα, φιλτραρισμένες προβολές με χαμηλή αξία) αλλά δεν πρέπει ποτέ να εμφανιστούν σε αναζήτηση.

Το rel=canonical δεν σταματάει τίποτα — λέει στη Google "αυτή η σελίδα υπάρχει, αλλά η κύρια, οριστική εκδοχή αυτού του περιεχομένου είναι αλλού". Χρησιμοποιήστε το για διπλότυπο ή σχεδόν-διπλότυπο περιεχόμενο: παραλλαγές προϊόντος με ίδια περιγραφή, σελίδες με UTM παραμέτρους, ή print-friendly εκδοχές του ίδιου άρθρου.

Το πρακτικό τεστ που χρησιμοποιούμε: ρωτήστε "θέλω το bot να δει καν αυτό;" — αν όχι, disallow. Αν ναι, αλλά "θέλω να εμφανιστεί ποτέ σε αναζήτηση;" — αν όχι, noindex. Αν ναι σε αναζήτηση αλλά "υπάρχει ήδη πανομοιότυπο περιεχόμενο αλλού που προτιμώ;" — canonical. Το πιο συχνό λάθος συνδυασμού: βάζετε disallow ΚΑΙ noindex μαζί στην ίδια σελίδα, νομίζοντας ότι είναι "διπλή ασφάλεια". Στην πραγματικότητα ακυρώνει το noindex — αφού η Google δεν επιτρέπεται να επισκεφθεί τη σελίδα λόγω του disallow, δεν βλέπει ποτέ το tag noindex μέσα σε αυτήν, οπότε δεν μπορεί να το εφαρμόσει. Αν η σελίδα έχει ήδη backlinks, μπορεί να παραμείνει ευρετηριασμένη χωρίς περιεχόμενο επ' αόριστον — το ακριβώς αντίθετο αποτέλεσμα από αυτό που θέλατε.

Το λάθος με το lastmod: γιατί "σήμερα" παντού καταστρέφει την εμπιστοσύνη

Υπάρχει ένα τεχνικό λάθος τόσο συνηθισμένο που τα περισσότερα CMS το κάνουν ως προεπιλογή, χωρίς κανείς να το αμφισβητήσει: το πεδίο lastmod σε κάθε εγγραφή sitemap ρυθμίζεται αυτόματα στην τρέχουσα ημερομηνία και ώρα, κάθε φορά που το sitemap παράγεται ξανά — ανεξάρτητα από το αν η συγκεκριμένη σελίδα άλλαξε πραγματικά. Το αποτέλεσμα είναι ένα sitemap όπου όλα τα URLs, ακόμα και μια σελίδα "Σχετικά με εμάς" που δεν έχει αγγιχτεί εδώ και τρία χρόνια, δείχνουν σαν να τροποποιήθηκαν σήμερα το πρωί.

Το αντιδιαισθητικό εδώ είναι ότι αυτό φαίνεται αβλαβές — τι κακό μπορεί να κάνει μια λάθος ημερομηνία; Στην πραγματικότητα, το lastmod είναι ένα από τα σήματα που χρησιμοποιεί η Google για να αποφασίσει πού να διαθέσει το περιορισμένο crawl budget της: σελίδες που δηλώνονται ως πρόσφατα ενημερωμένες παίρνουν προτεραιότητα επανεπίσκεψης, γιατί η λογική είναι ότι μπορεί να έχουν νέο, χρήσιμο περιεχόμενο. Αν κάθε σελίδα του site σας διεκδικεί την ίδια "φρεσκάδα", η Google δεν έχει πλέον κανέναν τρόπο να ξεχωρίσει ποιες σελίδες πραγματικά αξίζουν άμεση επανεπίσκεψη από ποιες απλά ενημερώθηκε το timestamp επειδή το CMS ξαναδημιούργησε το αρχείο.

Με τον καιρό, η Google μαθαίνει ότι το lastmod του συγκεκριμένου site σας είναι αναξιόπιστο σήμα — έχει ήδη δει αρκετές φορές ότι "τροποποιήθηκε σήμερα" δεν σήμαινε τίποτα πραγματικό — και απλά το αγνοεί εντελώς, επιστρέφοντας σε δικούς της, πιο αργούς κανόνες ανίχνευσης αλλαγών. Χάνετε ακριβώς το πλεονέκτημα που το σωστά χρησιμοποιημένο lastmod θα σας έδινε: γρήγορη ανίχνευση πραγματικά νέου περιεχομένου.

Η διόρθωση είναι τεχνικά απλή αλλά απαιτεί προσοχή στην πηγή δεδομένων: το lastmod πρέπει να αντλείται από το πραγματικό πεδίο "τελευταία τροποποίηση" της βάσης δεδομένων ή του CMS σας — το ίδιο πεδίο που ενημερώνεται όταν κάποιος πραγματικά επεξεργάζεται το περιεχόμενο, όχι όταν απλά τρέχει η προγραμματισμένη εργασία παραγωγής sitemap. Στο δικό μας sitemap, κάθε άρθρο Insights παίρνει το lastmod του από την ημερομηνία τροποποίησης του ίδιου του αρχείου περιεχομένου, όχι από τη στιγμή που η εφαρμογή τυχαίνει να τρέχει. Ο έλεγχος για το δικό σας site παίρνει πέντε λεπτά: ανοίξτε το sitemap.xml, δείτε αν δύο τυχαίες σελίδες που σίγουρα δεν άλλαξαν πρόσφατα έχουν διαφορετικό lastmod μεταξύ τους ή αν όλες δείχνουν ακριβώς τη σημερινή ημερομηνία — αν είναι το δεύτερο, βρήκατε το πρόβλημα.

Image και video sitemap: το κομμάτι που ξεχνούν σχεδόν όλοι

Το βασικό sitemap.xml λέει στη Google "αυτές οι σελίδες υπάρχουν". Δεν λέει τίποτα ρητά για το περιεχόμενο εικόνων μέσα σε αυτές τις σελίδες, εκτός αν το δηλώσετε ξεχωριστά μέσω επέκτασης εικόνας (image sitemap extension). Για τους περισσότερους ιστότοπους κειμένου αυτό δεν έχει μεγάλη σημασία — η Google ανακαλύπτει τις εικόνες όπως κι αλλιώς μέσα από το κανονικό crawling της σελίδας. Για ιστότοπους όπου η εικόνα είναι το ίδιο το προϊόν —ξενοδοχεία, portfolio αρχιτεκτόνων, κατασκευές γυαλιού και αλουμινίου— η απουσία ρητής δήλωσης εικόνων στο sitemap είναι χαμένη ευκαιρία ορατότητας σε ένα ολόκληρο κανάλι αναζήτησης: το Google Images.

Η αναζήτηση εικόνων δεν είναι δευτερεύον κανάλι για αυτούς τους κλάδους. Κάποιος που ψάχνει "δωμάτιο ξενοδοχείο θέα θάλασσα Κρήτη" στο Google Images και βρίσκει τη φωτογραφία του δικού σας δωματίου κάνει κλικ κατευθείαν στη σελίδα σας, με ήδη διαμορφωμένη οπτική προσδοκία — μια μορφή επισκεψιμότητας με υψηλότερη πρόθεση από την τυπική αναζήτηση κειμένου, γιατί η απόφαση "μου αρέσει αυτό που βλέπω" έχει ήδη ληφθεί πριν καν φτάσει στο site.

Η τεχνική υλοποίηση προσθέτει, μέσα στην ίδια εγγραφή URL του κανονικού sitemap, ετικέτες <image:image> με <image:loc> (τη διεύθυνση της εικόνας) και προαιρετικά <image:caption> και <image:title> — σύντομη, περιγραφική λεζάντα, όχι γενικό όνομα αρχείου σαν IMG_4521.jpg. Κάθε σελίδα μπορεί να περιλαμβάνει πολλαπλές εικόνες στην ίδια εγγραφή, κάτι ιδανικό για μια σελίδα portfolio με δέκα φωτογραφίες ενός έργου. Αντίστοιχη λογική ισχύει για video sitemap αν έχετε βίντεο περιήγησης ή παρουσίασης έργου — ιδιαίτερα χρήσιμο σε τη λογική "image first" που περιγράφουμε στις κατασκευές γυαλιού, όπου η εικόνα δεν συνοδεύει απλά το περιεχόμενο, είναι το ίδιο το επιχείρημα πώλησης.

Ο έλεγχος για να δείτε αν σας αφορά είναι άμεσος: ανοίξτε το Google Search Console, πηγαίνετε στην αναφορά επισκεψιμότητας, και φιλτράρετε ανά τύπο αναζήτησης — αν η κατηγορία "Image" εμφανίζει μηδενικά ή σχεδόν μηδενικά κλικ ενώ το site σας είναι οπτικά βαρύ, πιθανότατα δεν εκμεταλλεύεστε καθόλου αυτό το κανάλι, και η προσθήκη image sitemap είναι από τις φθηνότερες τεχνικές βελτιώσεις που μπορείτε να κάνετε σε ώρες, όχι μέρες.