WordPress robots.txt Best Practice sa 2026 (Ano Talaga ang Dapat Ilagay)

Mga limang linya lang ang haba ng magandang robots.txt sa WordPress. Harangin ang /wp-admin/, payagan ang admin-ajax.php, ituro sa mga crawler ang sitemap mo, at tumigil ka na doon — ang malalawak na 40-linyang blocklist na makikita mo sa mga forum ay kadalasang sumisira sa rendering o wala talagang ginagawa. Ito ang buong file:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

Palitan mo ang domain, at kung gumagamit ka ng SEO plugin na siyang humahawak ng sitemap, ituro mo ang linyang Sitemap sa index ng plugin na iyon. Iyon lang. Kung mas mahaba pa rito ang file mo, malamang may kapalit ang mga dagdag na linyang iyon.

May ginagawa nang isa ang WordPress — hanggang sa gumawa ka ng tunay na file

May virtual na robots.txt ang WordPress. Kapag may dumating na request para sa /robots.txt at walang aktuwal na file sa web root mo, sinasalo ng WordPress ang request at nag-iimprenta ito ng tugon sa memorya. Walang isinusulat sa disk. Ang default na output ay ang wp-admin block sa itaas, kasama ang linyang Sitemap: para sa wp-sitemap.xml na inilalabas ng core mula pa noong WordPress 5.5.

Dalawang bagay ang nagpapabago sa output na iyon. Kung naka-check ang Settings → Reading → Discourage search engines from indexing this site, pinapalitan ng WordPress ang buong nilalaman ng Disallow: /, na humaharang sa lahat. Ang checkbox na iyon ang pinakakaraniwang dahilan kung bakit naglalaho ang isang site sa search pagkatapos ng launch. Pangalawa, kayang baguhin ng mga plugin at tema ang virtual na output sa pamamagitan ng robots_txt filter, na siyang paraan ng pagpasok ng SEO plugins sa sariling sitemap lines at panuntunan nila.

Ngayon, ang bahaging sumasayang ng hapon ng mga tao. Tahimik na dinadaig ng pisikal na robots.txt file sa web root mo ang lahat ng iyon. May nahanap na tunay na file sa disk ang web server mo, inihahain nito iyon, at hindi na nalo-load ang WordPress. Hindi tumatakbo ang virtual na generator. Hindi pumuputok ang robots_txt filter. Puwedeng ipakita pa rin sa iyo ng robots.txt editor ng SEO plugin mo ang magandang interface na may tamang panuntunan sa loob, at wala sa mga iyon ang aabot sa crawler.

Saan nakatira ang mga panuntunan	Puwedeng i-edit sa WordPress admin	Nananalo sa aktuwal na request
Virtual (walang file sa disk)	Oo, sa pamamagitan ng robots_txt filter o ng plugin	Kapag lang walang pisikal na file
Pisikal na file sa web root	Kung nagsusulat lang sa disk ang plugin	Palagi

Kaya bago ka mag-debug ng kahit ano: buksan mo ang https://yoursite.com/robots.txt sa browser, tapos kumonekta ka sa SFTP o sa file manager ng host mo at tingnan kung may tunay na robots.txt na nakatabi sa wp-config.php at .htaccess. Kung mayroon, iyon ang robots.txt mo. I-edit mo doon o burahin mo at hayaan mong ang WordPress ang bahala — pero pumili ka ng isa. Ang pagpapatakbo ng pareho ang dahilan kung bakit napupunta ang mga site sa lumang sitemap URL na wala nang makahanap.

Bakit hinaharang ang /wp-admin/ pero pinapayagan ang admin-ajax.php

Nasa /wp-admin/ ang dashboard. Walang silbi ang mga URL na iyon sa search results at nasasayang lang ang crawl budget sa mga pahinang nagre-redirect papunta sa login screen. Walang pagtatalo sa pagharang sa direktoryong ito.

Nasa loob ng direktoryong iyon ang admin-ajax.php pero hindi ito admin page. Ito ang endpoint na ginagamit ng mga plugin at tema para hawakan ang front-end AJAX requests — load-more buttons, na-filter na product grid, calculator, form. Kung hindi ito makukuha ng crawler, hindi nito makikita ang content na nilo-load ng mga feature na iyon, at isasalang ng Google ang pahina mo gaya ng makikita ng bisitang sira ang feature.

Kung kailangan ba talagang kunin ng Google ang admin-ajax.php sa partikular mong site ay nakadepende sa kung ginagamit ito ng front end mo. Tapat na sagot: sa maraming modernong site ay wala talaga itong epekto, dahil REST API sa /wp-json/ ang ginagamit ng tema. Ang linyang Allow ay murang seguro laban sa tunay na paraan ng pagpalya, hindi ranking factor. Panatilihin mo dahil wala naman itong gastos.

Huwag mong harangin ang /wp-content/ o /wp-includes/

Ito ang pinakamasamang payo tungkol sa robots.txt na umiikot pa rin, at galing pa ito sa panahong hindi pa nagsasalang ng pahina ang Google.

Nasa /wp-content/ ang mga tema, plugin, at upload mo — ang stylesheet, script, at larawang nagpapaganda sa mga pahina mo. Nasa /wp-includes/ naman ang core JavaScript na inaasahan ng mga plugin. Isinasalang ng Google ang mga pahina mo gamit ang headless browser bago husgahan. Harangin mo ang mga direktoryong iyon at makukuha ng renderer ang pahinang walang CSS at walang larawan. Ang sinusuri ng Google ay pader ng tekstong walang estilo at sirang layout, na nakakaapekto sa pagkaunawa nito sa content mo at sa iskor mo sa mobile usability.

Kung may minanang file ka na may ganitong mga linya, burahin mo ang mga ito:

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

Kaya mong kumpirmahin mismo ang pinsala sa URL Inspection tool ng Google Search Console. Magpatakbo ng live test sa kahit anong pahina, tingnan ang naisalang na screenshot, at suriin ang listahan ng page resources para sa mga hinarang na bagay. Kung nakalista ang CSS mo bilang blocked, iyon ang dahilan.

Ang Sitemap na direktiba

Isang linya, absolute na URL, at puwede itong nasaan man sa file — hindi ito nakatali sa isang User-agent group.

Sitemap: https://example.com/wp-sitemap.xml

Gamitin ang URL na talagang bumubukas. Naghahain ang WordPress core ng wp-sitemap.xml. Karamihan sa SEO plugins ay pinapatay ang core sitemaps at naghahain ng sarili nilang index sa ibang path, karaniwan ay sitemap_index.xml. I-load mo ang URL mo sa browser bago mo ito itakda — mas masama ang linyang Sitemap na nakaturo sa 404 kaysa sa walang linya, dahil mukhang tama ito sa isang audit.

Ayos lang maglista ng maraming sitemap, isa kada linya. Sulit pa ring hiwalay na magsumite ng sitemap sa Search Console; ang direktiba sa robots.txt ang paraan ng paghahanap ng mga crawler na hindi naman nakakakita ng Search Console account mo.

Hindi noindex ang robots.txt, at hindi rin ito seguridad

Ang dalawang maling akalang ito ang sanhi ng karamihan sa pinsalang dulot ng robots.txt.

Hindi tinatanggal sa Google ang isang URL kapag hinarang mo ito. Ang pag-crawl ang pinamamahalaan ng robots.txt. Kung may ibang site na nagli-link sa isang hinarang na URL, kaya pa ring i-index ng Google ang URL mismo — makakakuha ka ng resultang puro address lang na may nakasabing walang makuhang impormasyon. At may mas masaklap na bitag: kung may noindex meta tag na ang isang pahina at hinarang mo ito sa robots.txt, hindi ito maka-crawl ng Google, hindi nito makikita ang noindex, at puwedeng manatiling naka-index ang pahina nang walang hanggan. Para maalis ang isang pahina, payagan ang pag-crawl at maghain ng noindex meta robots tag sa head ng pahina o ng X-Robots-Tag HTTP header. Tumigil ang Google sa pagsuporta sa mga direktibang noindex sa loob ng robots.txt noong 2019.

Hindi mo napoprotektahan ang isang path kapag hinarang mo ito. Pampubliko ang robots.txt mo, iyan ang kalikasan nito. Kapag inilista mo ang /private-client-files/, sinasabi mo sa bawat bisita at bawat scanner kung saan eksaktong titingin, at kusang-loob lang ang pagsunod — ginagalang ito ng Google, hindi ng mga masasamang bot. Anumang kailangang protektahan ay nangangailangan ng authentication, IP restriction, o server-level na panuntunan sa .htaccess, hindi ng isang linya sa text file na inaanunsiyo ang target.

Mga panuntunang sulit idagdag, at mga sulit laktawan

Dalawang dagdag ang talagang kapaki-pakinabang sa maraming site. Kapag hinarang mo ang path ng search results, napipigilan mong makabuo ang mga crawler ng walang katapusang mababang halagang URL mula sa internal search mo. Kapag hinarang mo ang cart o checkout path sa WooCommerce, hindi napapasama sa crawl ang mga URL na may session parameter.

Disallow: /?s=
Disallow: /search/

Laktawan mo ang mga ito:

• Crawl-delay — tuluyang binabalewala ito ng Google. Gamitin ang crawl rate controls sa Search Console kung may tunay kang problema sa server load.
• Pagharang sa /feed/ o /trackback/ — walang masamang URL ang mga iyon, at kapaki-pakinabang ang mga feed.
• Mahahabang listahan ng pangalan ng bot — karamihan sa mga bot na sinusubukang harangin ng mga tao ay hindi naman tapat magpakilala.
• Pagharang sa /wp-json/ — baka iyon ang ginagamit ng tema mo para isalang ang content.

Buuin ang file gamit ang WordPress robots.txt generator, na gumagawa ng pinakapayak na tamang bersyon at nagpapahintulot sa iyong idagdag ang mga panuntunan sa search at commerce nang hindi mo kailangang mag-edit ng sintaks nang manu-mano.

Pagkatapos mong baguhin ito

I-load mo mismo ang https://yoursite.com/robots.txt at kumpirmahin na ang mga inihaing byte ang inaasahan mo — hindi ang ipinapakita sa iyo ng editor ng plugin mo. Tapos magpatakbo ng live URL inspection sa Search Console sa isang normal na pahina at tingnan kung walang CSS o JavaScript na resource ang bumabalik bilang blocked. Nagka-cache ang Google ng robots.txt nang mga isang araw, kaya hindi agad tatalab ang pag-aayos, at ganoon din ang pagkakamali. Ang pagkaantalang iyon ang dahilan kung bakit dapat maingat kang magpatunay sa halip na sa production ka mag-test at maghintay.