A Humble Robots.txt fájl gyakran csendesen ül a WordPress webhely hátterében, de az alapértelmezés kissé alapvető a dobozból, és természetesen nem járul hozzá a testreszabott irányelvekhez, amelyeket érdemes elfogadni.
Nincs több intro szükséglet – merüljünk bele azzal, amit még be lehet vonni annak javítására.
(Egy kis megjegyzés hozzáadása: Ez a bejegyzés csak a WordPress telepítéséhez hasznos, csak egy domain vagy aldomain gyökérkönyvtárában, pl. Domain.com vagy példa.domain.com.)
Pontosan hol van a WordPress robots.txt fájl?
Alapértelmezés szerint a WordPress virtuális robots.txt fájlt generál. A telepítés /robots.txt webhelyen láthatja, például:
https://yoursite.com/robots.txt
Ez az alapértelmezett fájl csak a memóriában létezik, és a kiszolgálón nem ábrázolja.
Ha egyedi robots.txt fájlt szeretne használni, akkor csak annyit kell tennie, hogy feltölt egy telepítés gyökérmappájába.
Ezt megteheti FTP alkalmazás vagy plugin, például a Yoast SEO (SEO → Eszközök → Fájlszerkesztő), amely tartalmaz egy robot.txt szerkesztőt, amelyhez hozzáférhet a WordPress admin területén.
Az alapértelmezett WordPress robots.txt (és miért nem elég)
Ha nem hoz létre manuálisan robot.txt fájlt, akkor a WordPress ‘alapértelmezett kimenet így néz ki:
User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php
Bár ez biztonságos, ez nem optimális. Menjünk tovább.
Mindig adja meg az XML webhelytérképét
Győződjön meg arról, hogy az összes XML webhelytérképet kifejezetten felsorolják, mivel ez segít a keresőmotoroknak az összes releváns URL felfedezésében.
Sitemap: https://example.com/sitemap_index.xml Sitemap: https://example.com/sitemap2.xml
Néhány dolog, amit nem lehet blokkolni
Jelenleg keltezett javaslatok vannak arra, hogy tiltsák meg néhány alapvető WordPress könyvtárat, például a/WP-beleértve/,/wp-content/plugins/, vagy akár/wp-content/feltöltés/. Ne!
Ezért nem szabad blokkolni őket:
- A Google elég okos ahhoz, hogy figyelmen kívül hagyja a irreleváns fájlokat. A CSS és a JavaScript blokkolása károsíthatja a megjeleníthetőséget és indexelési problémákat okozhat.
- Nem szándékosan blokkolhatja az értékes képeket/videókat/egyéb adathordozókat, különösen a/WP-Content/Uploads/-ból betöltött médiumokat, amelyek tartalmazzák az összes feltöltött médiát, amelyet feltétlenül szeretnének mászni.
Ehelyett hagyja, hogy a rugók a CSS -t, a JavaScriptet és a megfelelő megjelenítéshez szükséges képeket kapják.
Átmeneti helyek kezelése
Javasoljuk annak biztosítása, hogy a rendező helyek nem másznak -e mind SEO, mind általános biztonsági célokra.
Mindig azt tanácsolom, hogy engedje el az egész webhelyet.
Még mindig használja a NoIndex Meta címkét, de annak biztosítása érdekében, hogy egy másik réteg lefedje, továbbra is tanácsos mindkettőt megtenni.
Ha navigálsz Beállítások> OlvasásJelölheti a „Keresőmotorok visszatartása a webhely indexelésétől” lehetőséget, amely a következőket teszi a robots.txt fájlban (vagy ezt hozzáadhatja önmagában).
User-agent: * Disallow: /
A Google továbbra is indexelheti az oldalakat, ha másutt felfedezi a linkeket (általában a termelésből származó színpadi hívások okozzák, amikor a migráció nem tökéletes).
Fontos: Amikor a termelésre költözik, ügyeljen arra, hogy újra ellenőrizze ezt a beállítást, hogy megbizonyosodjon arról, hogy visszaállítja a tiltást vagy a noindexing-et.
Tisztítsa meg néhány nem alapvető Core WordPress utat
Nem mindent el kell blokkolni, de sok alapértelmezett útvonal nem ad hozzá SEO -értéket, például az alábbiak:
Disallow: /trackback/ Disallow: /comments/feed/ Disallow: */embed/ Disallow: /cgi-bin/ Disallow: /wp-login.php
Tiltja meg a konkrét lekérdezési paramétereket
Időnként meg kell állítania a keresőmotorokat az ismert, alacsony értékű lekérdezési paraméterekkel, mint például a nyomkövetési paraméterek, a megjegyzésválaszok vagy a nyomtatási verziók nyomkövetése.
Íme egy példa:
User-agent: * Disallow: /*?*replytocom= Disallow: /*?*print=
Használhatja a Google Search Console URL-paraméterek eszközét a paraméter-vezérelt indexelési minták megfigyelésére, és eldöntheti, hogy a további tilalmak méltóak-e a hozzáadásra.
Az alacsony értékű taxonómiák és a SERP-k tiltása
Ha a WordPress webhelye tartalmazza a Tag -archívumokat vagy a belső keresési eredményeket, amelyek nem adnak hozzáadott értéket, akkor is blokkolhatja őket:
User-agent: * Disallow: /tag/ Disallow: /page/ Disallow: /?s=
Mint mindig, mérlegelje ezt az adott tartalmi stratégiájával.
Ha a Tag taxonómia oldalakat használja a tartalom részeként, indexelt és mászni szeretne, akkor hagyja figyelmen kívül ezt, de általában nem ad hozzá előnyeit.
Ezenkívül győződjön meg arról, hogy a belső összekötő struktúra támogatja -e döntését, és minimalizálja a belső kapcsolatokat olyan területekkel, amelyekben nem szándékozik indexelni vagy mászni.
Figyelje a feltérképezés statisztikáit
Miután a robotok.txt a helyén van, figyelje a feltérképezés statisztikáit a Google Search Console -on:
- Nézze meg a feltérképezés statisztikáit a beállítások alatt, hogy megnézze, vajon a robotok pazarolják -e az erőforrásokat.
- Használja az URL -ellenőrző eszközt annak megerősítéséhez, hogy a blokkolt URL indexel -e vagy sem.
- Ellenőrizze a webhelytérképeket, és győződjön meg arról, hogy csak a mászás és az indexelt oldalak referencia oldalaikat.
Ezenkívül néhány szerverkezelő eszköz, például a Plesk, a CPanel és a CloudFlare, rendkívül részletes feltérképezési statisztikákat nyújthat a Google -on.
Végül használja a Screaming Frog konfigurációjának felülbírálását a változások szimulálásához és a Yoast SEO feltérképezésének optimalizálási funkcióinak újraértékeléséhez, amelyek közül néhány megoldja a fentieket.
Végső gondolatok
Noha a WordPress nagyszerű CMS, nem állítja be a legideálisabb alapértelmezett robots.txt -et, vagy nem állítja be a feltérképezés optimalizálását.
Mindössze néhány sor kód és kevesebb, mint 30 perc ideje több ezer szükségtelen feltérképezési kérelmet takaríthat meg a webhelyére, amelyek egyáltalán nem érdemesek azonosítani, és a jövőben potenciális méretezési kérdés biztosítása.
