Να ένα ερώτημα που οι περισσότεροι ιδιοκτήτες ιστότοπων δεν έχουν σκεφτεί: όταν ένας agent ΤΝ επισκέπτεται το site σας, τι βλέπει πραγματικά;

Όχι αυτό που βλέπει ένας άνθρωπος, μια καθαρή διάταξη, στυλιζαρισμένες επικεφαλίδες, μια μπάρα πλοήγησης. Αυτό που λαμβάνει η μηχανή: έναν τοίχο HTML με μενού πλοήγησης, banners συγκατάθεσης cookies, εικονίδια SVG, πακέτα JavaScript, συνδέσμους υποσέλιδου, scripts παρακολούθησης, και κάπου μέσα σε αυτόν τον θόρυβο, το πραγματικό περιεχόμενο για το οποίο ήρθε ο agent. Σε μια τυπική σελίδα, το 70-80% των tokens που επεξεργάζεται ένα μοντέλο ΤΝ είναι δομικό markup με μηδενική πληροφοριακή αξία.

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

Τι Συνέβη

Τον Φεβρουάριο 2026 η Cloudflare παρουσίασε μια λειτουργία με το όνομα «Markdown for Agents». Η ιδέα είναι κομψή: όταν ένας agent ΤΝ στέλνει αίτημα με Accept: text/markdown στις κεφαλίδες HTTP, ο server απαντά με καθαρό markdown αντί για HTML. Ίδιο URL, ίδιο περιεχόμενο, διαφορετική αναπαράσταση, επιλεγμένη μέσω της τυπικής διαπραγμάτευσης περιεχομένου του HTTP.

Είναι λογική κίνηση. Η Cloudflare βρίσκεται μπροστά από περίπου το 20% της κίνησης του διαδικτύου, και βλέπει τους crawlers ΤΝ να καταναλώνουν εύρος ζώνης σε κλίμακα. Το να δώσεις σε αυτούς τους crawlers μια ελαφριά, δομημένη μορφή μειώνει το φορτίο για όλους: τον server προέλευσης, το CDN, την υπηρεσία ΤΝ που επεξεργάζεται την απόκριση, και τελικά τον χρήστη που περιμένει απάντηση.

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

Υπάρχει μόνο ένα πρόβλημα: πρέπει να χρησιμοποιείς Cloudflare.

Η Διαπραγμάτευση Περιεχομένου Δεν Είναι Εφεύρεση της Cloudflare

Αυτό που έχτισε η Cloudflare είναι έξυπνη μηχανική πάνω σε έναν μηχανισμό που υπάρχει από τότε που προτυποποιήθηκε το HTTP/1.1 το 1997. Η διαπραγμάτευση περιεχομένου, η διαδικασία με την οποία ο πελάτης προσδιορίζει ποια μορφή προτιμά και ο server απαντά αναλόγως, ορίζεται στο RFC 9110, ενότητα 12.

Η κεφαλίδα Accept είναι ο τρόπος με τον οποίο ο browser σας ήδη λέει στους servers ότι θέλει HTML αντί για απλό κείμενο, ή με τον οποίο οι πελάτες API ζητούν JSON αντί για XML. Όταν ένας agent ΤΝ στέλνει Accept: text/markdown, χρησιμοποιεί ακριβώς τον ίδιο μηχανισμό. Οποιοσδήποτε web server μπορεί να ανταποκριθεί. Δεν χρειάζεστε Cloudflare. Δεν χρειάζεστε κανένα συγκεκριμένο CDN. Χρειάζεστε έναν web server που μπορεί να διαβάσει μια κεφαλίδα και να σερβίρει διαφορετικό αρχείο.

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

Πώς το Χτίσαμε

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

Το Στρώμα nginx

Το σημείο εισόδου είναι μια οδηγία map στη ρύθμιση του nginx που εξετάζει την κεφαλίδα Accept:

map $http_accept $wants_markdown {
    default         0;
    "~text/markdown" 1;
}

Αυτό δημιουργεί μια μεταβλητή που τα επόμενα location blocks μπορούν να χρησιμοποιήσουν για τη δρομολόγηση αιτημάτων. Όταν ένας κανονικός browser επισκέπτεται το /en/about.html, παίρνει HTML ως συνήθως. Όταν ένας agent ΤΝ ζητά το ίδιο URL με Accept: text/markdown, το αίτημα ξαναγράφεται προς το API markdown μας:

location /en/ {
    if ($wants_markdown) {
        rewrite ^/en/(.*)\.html$ /api/markdown/page/en/$1 last;
        rewrite ^/en/$ /api/markdown/page/en/index last;
    }
    try_files $uri $uri/ /en/404.html;
}

Ο agent δεν βλέπει ποτέ το rewrite. Ίδιο URL, διαφορετική απόκριση, ακριβώς όπως πρέπει να δουλεύει η διαπραγμάτευση περιεχομένου.

Η Υβριδική Στρατηγική Μετατροπής

Η μετατροπή HTML σε markdown σε πραγματικό χρόνο για κάθε αίτημα θα ήταν σπάταλη. Οι στατικές μας σελίδες, σχετικά, υπηρεσίες, προϊόντα, μελέτες περίπτωσης, αλλάζουν το πολύ λίγες φορές τον μήνα. Η μετατροπή τους σε κάθε επίσκεψη agent θα έκαιγε κύκλους CPU για πανομοιότυπη έξοδο.

Οπότε χωρίσαμε την προσέγγιση:

  • Οι στατικές σελίδες προ-παράγονται ως αρχεία markdown στον δίσκο. Μια νυχτερινή προγραμματισμένη εργασία διατρέχει τον φάκελο του πηγαίου HTML, αφαιρεί τα στοιχεία εκτός περιεχομένου, μετατρέπει το υπόλοιπο σε καθαρό markdown με YAML frontmatter και γράφει τα αποτελέσματα σε γνωστή διαδρομή. Το endpoint του API απλώς σερβίρει αυτά τα αρχεία: χωρίς επεξεργασία, χωρίς μετατροπή, μόνο ανάγνωση αρχείου.
  • Τα άρθρα blog μετατρέπονται σε πραγματικό χρόνο από τη βάση. Επειδή τα άρθρα είναι ήδη αποθηκευμένα ως δομημένο περιεχόμενο HTML (χωρίς πλοήγηση, χωρίς περίβλημα, μόνο το σώμα του άρθρου), η μετατροπή είναι ελαφριά: ανάλυση του HTML, μετατροπή σε markdown, προσθήκη μεταδεδομένων ως frontmatter, και σερβίρισμα.

Η προ-παραγωγή τρέχει καθημερινά στις 02:30 UTC και μπορεί να ενεργοποιηθεί χειροκίνητα μέσω endpoint διαχείρισης. Σήμερα επεξεργάζεται 67 σελίδες και παράγει περίπου 86.000 tokens καθαρού markdown.

Τι Αφαιρείται

Ο αγωγός μετατροπής αφαιρεί ό,τι δεν είναι περιεχόμενο. Συγκεκριμένα:

  • Μπάρες πλοήγησης (<nav>, <header>)
  • Υποσέλιδα
  • Scripts και φύλλα στυλ
  • Στοιχεία SVG και ενσωματωμένα εικονίδια
  • Banners συγκατάθεσης cookies
  • Στοιχεία φορμών
  • Συνδέσμους μετάβασης στο περιεχόμενο και επικαλύψεις προσβασιμότητας
  • Οποιοδήποτε στοιχείο με κλάσεις που ταιριάζουν σε συνήθη μοτίβα εκτός περιεχομένου (cookie, consent, newsletter, popup)

Ό,τι μένει είναι το σημασιολογικό περιεχόμενο: επικεφαλίδες, παράγραφοι, λίστες, σύνδεσμοι, μπλοκ κώδικα, εικόνες με εναλλακτικό κείμενο και πίνακες. Αυτό είναι που πραγματικά χρειάζεται ο agent ΤΝ.

Το Frontmatter

Κάθε απόκριση markdown ξεκινά με YAML frontmatter που περιέχει δομημένα μεταδεδομένα:

---
title: "IT Infrastructure Services"
description: "Enterprise IT architecture, governance, and optimisation"
url: https://iwh.gr/en/services/infrastructure.html
language: en
type: article
generated: "2026-02-22T02:30:14Z"
tokens: 1847
---

Για τα άρθρα blog το frontmatter είναι πλουσιότερο, με συγγραφέα, ημερομηνία δημοσίευσης, κατηγορία και ετικέτες. Αυτά τα δομημένα μεταδεδομένα είναι άμεσα χρήσιμα στα μοντέλα ΤΝ χωρίς να χρειάζεται να τα αναλύσουν από meta tags HTML θαμμένα στο <head>.

Τι Βλέπουν Πραγματικά οι Agents ΤΝ

Η διαφορά είναι δραματική. Να πώς μοιάζει μια τυπική σελίδα σε έναν agent ΤΝ που ζητά HTML έναντι markdown.

Απόκριση HTML (απλοποιημένη· η πραγματική είναι χειρότερη):

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>About IWH</title>
  <link rel="stylesheet" href="/assets/css/style.min.css">
  <script src="/assets/js/main.min.js"></script>
  <!-- 40 ακόμη meta tags, OG tags, schema markup... -->
</head>
<body>
  <header>
    <nav>
      <!-- 200+ γραμμές HTML πλοήγησης -->
    </nav>
  </header>
  <main>
    <h1>About IWH</h1>
    <p>Το πραγματικό περιεχόμενο για το οποίο ήρθες.</p>
    <!-- 20-30 γραμμές πραγματικού περιεχομένου -->
  </main>
  <footer>
    <!-- Άλλες 100+ γραμμές -->
  </footer>
  <div class="cookie-consent">...</div>
  <script>/* analytics, consent, animations */</script>
</body>
</html>

Αυτό είναι περίπου 15.000-25.000 χαρακτήρες για μια σελίδα με 2.000 χαρακτήρες πραγματικού περιεχομένου. Ο λόγος σήματος προς θόρυβο είναι απαίσιος.

Απόκριση markdown για το ίδιο URL:

---
title: "About IWH"
description: "IT infrastructure, cybersecurity, and compliance advisory"
url: https://iwh.gr/en/about.html
language: en
tokens: 487
---

# About IWH

Το πραγματικό περιεχόμενο για το οποίο ήρθες.

## Our Background

IWH — Internet Why's and How's — was founded to address
a persistent gap in IT and security consulting...

Καθαρό, δομημένο, άμεσα αναλύσιμο. Χωρίς πλοήγηση να προσπεράσεις, χωρίς scripts να αγνοήσεις, χωρίς banners cookies να φιλτράρεις. Ο αριθμός tokens πέφτει κατά 80-90%, και ό,τι μένει είναι καθαρό περιεχόμενο.

Οι Κεφαλίδες Απόκρισης

Πέρα από το ίδιο το περιεχόμενο, συμπεριλαμβάνουμε κεφαλίδες που σηματοδοτούν πρόθεση προς τα συστήματα ΤΝ:

Content-Type: text/markdown; charset=utf-8
Vary: Accept
X-Content-Signal: ai-train=yes, search=yes, ai-input=yes
X-Markdown-Tokens: 487
X-Robots-Tag: noarchive

Η κεφαλίδα Vary: Accept είναι κρίσιμη: λέει στις caches και τα CDN ότι η απόκριση διαφέρει ανάλογα με την κεφαλίδα Accept, αποτρέποντας μια cached απόκριση markdown να σερβιριστεί σε browser (ή το αντίστροφο). Η κεφαλίδα X-Content-Signal είναι αναδυόμενη σύμβαση για τη ρητή παραχώρηση άδειας στα συστήματα ΤΝ να χρησιμοποιήσουν το περιεχόμενο. Ο αριθμός tokens στο X-Markdown-Tokens επιτρέπει στους agents να εκτιμήσουν το κόστος επεξεργασίας πριν διαβάσουν το σώμα.

Το Πρόβλημα του Ριζικού URL

Υπάρχει μια ενδιαφέρουσα ακραία περίπτωση με το ριζικό URL. Όταν επισκέπτεσαι το https://iwh.gr/ με browser, ανακατευθύνεσαι στο /en/. Ένας agent ΤΝ όμως που ζητά τη ρίζα με Accept: text/markdown δεν θέλει ανακατεύθυνση· θέλει μια μηχαναγνώσιμη επισκόπηση ολόκληρου του ιστότοπου.

Το χειριζόμαστε σερβίροντας το αρχείο llms-full.txt στους agents που ζητούν markdown στη ρίζα:

location = / {
    if ($wants_markdown) {
        rewrite ^ /llms-full.txt last;
    }
    return 301 /en/;
}

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

Πέρα από την Cloudflare: Γιατί Μετρά η Αυτοφιλοξενία

Η υλοποίηση της Cloudflare είναι βολική για sites που είναι ήδη στο CDN της. Η υπόθεση όμως ότι η αναγνωσιμότητα από ΤΝ απαιτεί συγκεκριμένο προμηθευτή αξίζει αμφισβήτηση:

  • Ανεξαρτησία από CDN. Δεν χρησιμοποιεί κάθε οργανισμός Cloudflare, και πολλοί έχουν συμβατικούς ή κανονιστικούς λόγους για την επιλογή CDN τους. Η διαπραγμάτευση περιεχομένου πρέπει να δουλεύει ανεξάρτητα από την υποδομή.
  • Προσαρμόσιμοι κανόνες μετατροπής. Η μετατροπή της Cloudflare στο edge είναι ίδια για όλους. Η αυτοφιλοξενούμενη μετατροπή σας επιτρέπει να ελέγχετε ακριβώς τι αφαιρείται, ποια μεταδεδομένα συμπεριλαμβάνονται και πώς δομείται η έξοδος για το δικό σας περιεχόμενο.
  • Κυριαρχία δεδομένων. Η μετατροπή γίνεται στη δική σας υποδομή. Το περιεχόμενο δεν περνά ποτέ από στρώμα μετατροπής τρίτου.
  • Αποδοτικότητα προ-παραγωγής. Η Cloudflare μετατρέπει σε κάθε αίτημα στο edge. Η προ-παραγωγή στατικού περιεχομένου σημαίνει μηδενική επιβάρυνση μετατροπής τη στιγμή του αιτήματος: ο server διαβάζει και στέλνει ένα αρχείο, τίποτα άλλο.
  • Blog και δυναμικό περιεχόμενο. Η Cloudflare μετατρέπει ολόκληρη τη σελίδα HTML. Η προσέγγισή μας μετατρέπει μόνο το περιεχόμενο από τη βάση, παρακάμπτοντας εντελώς το template. Το αποτέλεσμα είναι καθαρότερο επειδή το πηγαίο υλικό είναι καθαρότερο.

Αυτό δεν είναι επιχείρημα κατά της Cloudflare· η υλοποίησή της είναι καλά σχεδιασμένη και κατάλληλη για πολλά sites. Είναι επιχείρημα κατά της υπόθεσης ότι μια λειτουργία CDN είναι ο μόνος τρόπος να λυθεί αυτό το πρόβλημα.

llms.txt: Το Συμπληρωματικό Κομμάτι

Η διαπραγμάτευση περιεχομένου μέσω Accept: text/markdown δίνει στους agents ΤΝ καθαρή έκδοση οποιασδήποτε συγκεκριμένης σελίδας ζητήσουν. Δεν βοηθά όμως έναν agent που συναντά τον ιστότοπό σας για πρώτη φορά και πρέπει να καταλάβει τι είναι διαθέσιμο.

Εκεί μπαίνει το llms.txt. Προτεινόμενο από τον Jeremy Howard και με αυξανόμενη απήχηση στο διαδίκτυο, το llms.txt είναι σύμβαση (παρόμοια με το robots.txt ή το sitemap.xml) με την οποία τα sites παρέχουν μηχαναγνώσιμη επισκόπηση σε γνωστή διαδρομή. Η υλοποίησή μας περιλαμβάνει δύο αρχεία:

  • /llms.txt: συνοπτική περίληψη: ποιοι είμαστε, τι κάνουμε, και σύνδεσμοι σε βασικές ενότητες
  • /llms-full.txt: πλήρες έγγραφο που καλύπτει όλες τις σελίδες, υπηρεσίες, προϊόντα και περιεχόμενο αναλυτικά

Μαζί με τη διαπραγμάτευση περιεχομένου markdown, δημιουργούν ένα πλήρες στρώμα αναγνωσιμότητας από ΤΝ: llms.txt για ανακάλυψη, αποκρίσεις markdown για κατανάλωση. Ένας agent ΤΝ μπορεί να διαβάσει το llms.txt μας για να καταλάβει τη δομή του ιστότοπου, και μετά να ζητήσει συγκεκριμένες σελίδες ως markdown για να πάρει το περιεχόμενο που χρειάζεται, όλα χωρίς να αναλύσει ούτε ένα tag HTML.

Πρέπει να το Κάνετε;

Ειλικρινής αποτίμηση: εξαρτάται.

Μάλλον δεν αξίζει αν:

  • Έχετε site παρουσίασης 5 σελίδων με στατικό περιεχόμενο που σπάνια αλλάζει. Η προσπάθεια ξεπερνά το όφελος.
  • Είστε ήδη στη Cloudflare και η υλοποίησή της καλύπτει τις ανάγκες σας. Μην ξαναεφευρίσκετε ό,τι δουλεύει.
  • Το περιεχόμενό σας δεν είναι του είδους που πιθανόν να καταναλώσουν agents ΤΝ (αμιγώς συναλλακτικά sites, εφαρμογές, dashboards).

Μάλλον αξίζει αν:

  • Τρέχετε site με πολύ περιεχόμενο: blog, βάση γνώσης, πύλη τεκμηρίωσης ή ειδησεογραφική έκδοση. Οι agents ΤΝ ήδη καταναλώνουν το περιεχόμενό σας· εσείς πρέπει να ελέγχετε το πώς.
  • Θέλετε ανεξαρτησία από CDN. Οι επιλογές υποδομής σας δεν πρέπει να υπαγορεύουν τη στρατηγική αναγνωσιμότητας από ΤΝ.
  • Σερβίρετε ρυθμιζόμενο ή ευαίσθητο περιεχόμενο όπου μετρά η κυριαρχία δεδομένων. Η μετατροπή περιεχομένου πρέπει να γίνεται στη δική σας υποδομή.
  • Σας νοιάζει το αναδυόμενο οικοσύστημα ΤΝ. Τα sites που διαβάζονται εύκολα από agents ΤΝ θα έχουν πλεονέκτημα στην αναζήτηση, τις παραπομπές και τις συστάσεις με ΤΝ.

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

Η Λίστα Ελέγχου Υλοποίησης

Αν αποφασίσετε να το υλοποιήσετε, να η πρακτική σειρά:

  1. Προσθέστε πρώτα llms.txt. Είναι το ευκολότερο βήμα και κάνει αμέσως τον ιστότοπό σας πιο ανακαλύψιμο από συστήματα ΤΝ. Ακόμη και ένα απλό αρχείο κειμένου με τις βασικές σελίδες σας και το τι περιέχουν έχει αξία.
  2. Υλοποιήστε διαπραγμάτευση περιεχομένου Accept: text/markdown. Ξεκινήστε από τις σημαντικότερες σελίδες περιεχομένου σας. Χρησιμοποιήστε map + if στο nginx για δρομολόγηση, και μια ελαφριά υπηρεσία μετατροπής πίσω του.
  3. Προ-παραγάγετε όπου γίνεται. Το στατικό περιεχόμενο πρέπει να προ-μετατρέπεται, όχι να υπολογίζεται σε κάθε αίτημα. Προγραμματίστε την αναπαραγωγή με βάση τη συχνότητα ενημέρωσης του περιεχομένου σας.
  4. Χειριστείτε το δυναμικό περιεχόμενο ξεχωριστά. Άρθρα blog, λίστες προϊόντων και συχνά ενημερωμένο περιεχόμενο πρέπει να μετατρέπονται σε πραγματικό χρόνο από τα πηγαία δεδομένα, όχι από το αποδομένο HTML.
  5. Ορίστε σωστές κεφαλίδες. Το Vary: Accept είναι αδιαπραγμάτευτο. X-Content-Signal για σηματοδότηση αδειών. Αριθμοί tokens για εκτίμηση κόστους.
  6. Δοκιμάστε με πραγματικούς agents. Το curl -H "Accept: text/markdown" είναι φίλος σας. Επαληθεύστε ότι κάθε διαδρομή περιεχομένου επιστρέφει καθαρό, χρήσιμο markdown.

Χτίσαμε το AgentReady για να βοηθήσουμε οργανισμούς να υλοποιήσουν παράδοση περιεχομένου αναγνώσιμου από ΤΝ χωρίς δέσμευση σε CDN. Αν σας ενδιαφέρει να κάνετε τον ιστότοπό σας να μιλά τη γλώσσα που πραγματικά μιλούν οι agents ΤΝ, ας μιλήσουμε.