Are WordPress core funcții AI pe care trebuie să le dezactivez?

WordPress core, în varianta self-hosted, nu vine cu un asistent de scriere AI, un chatbot sau un generator de imagini activ din start. Panourile AI din editor apar aproape întotdeauna dintr-un plugin instalat, dintr-un plugin injectat de hosting sau dintr-o integrare din panoul de administrare al hostingului. Verifică lista de pluginuri înainte să scrii cod pentru a elimina ceva ce s-ar putea să nici nu existe în core.

Cum opresc Jetpack AI Assistant?

Dezactivează modulul AI Assistant din ecranul de setări Jetpack, nu prin cod. Jetpack este construit din module care se pot opri independent, așa că oprirea acelui modul elimină panoul din editor și lasă restul Jetpack să funcționeze. Dacă nu folosești nicio altă funcție Jetpack, e mai simplu și mai ușor să dezactivezi tot pluginul.

Poate remove_action să dezactiveze o funcție AI dintr-un plugin?

Uneori, dar soluția e fragilă. Funcționează doar dacă știi exact hook-ul, callback-ul și prioritatea cu care s-a înregistrat pluginul, iar o actualizare poate redenumi oricare dintre ele și readuce funcția în tăcere. Folosește setarea proprie a pluginului atunci când există și tratează dezagățarea din hook ca ultimă soluție, pe care o retestezi după fiecare actualizare.

Chiar funcționează blocarea crawlerelor AI din robots.txt?

Doar pentru crawlerele care aleg să îl respecte. Operatori mari precum OpenAI, Anthropic, Google și Apple publică tokenuri de user-agent pe care spun că le onorează, iar blocarea lor merită făcută. Regulile din robots nu sunt o măsură de forță, așa că actorii rău intenționați și cererile pornite de utilizatori le pot ignora. Blocarea la nivel de server este stratul care chiar se aplică.

Care e diferența dintre a bloca un crawler AI și a bloca căutarea AI?

Unii operatori folosesc tokenuri separate pentru antrenare și pentru răspunsul la întrebări în timp real. Blocarea tokenului de antrenare ține conținutul tău în afara antrenării modelului, dar te lasă vizibil în răspunsurile AI, în timp ce blocarea unui token de căutare sau de user-agent te poate scoate din rezultatele generate de AI care altfel te-ar cita și ți-ar da link. Decide ce compromis vrei înainte să le blochezi pe amândouă.

Este llms.txt un standard pe care ar trebui să îl implementez?

Nu, llms.txt este o propunere a comunității, nu un standard ratificat, și niciun operator AI important nu s-a angajat să îl trateze ca mecanism de control al accesului. Adăugarea fișierului este inofensivă și ieftină, dar nu îl considera un înlocuitor pentru directivele din robots.txt sau pentru blocarea la nivel de server. Lucrul la standarde în această zonă este încă în desfășurare.

Cum dezactivezi funcțiile AI din WordPress (core sau plugin, sincer)

Aproape orice funcție AI pe care lumea vrea să o scoată din WordPress vine dintr-un plugin, de la hosting sau de la WordPress.com — nu din core-ul self-hosted. Înainte să lipești un fragment cu remove_action în functions.php, deschide lista de pluginuri și găsește lucrul care chiar afișează acel panou AI, pentru că eliminarea unei funcții pe care core-ul nici nu o livrează înseamnă multă muncă irosită pe un site care deja se poartă ciudat.

Distincția contează pentru că soluțiile sunt complet diferite. O funcție de plugin are un comutator în setări. O funcție injectată de hosting stă în panoul de administrare al hostingului, nu în adminul WordPress. Iar întrebarea separată la care lumea se gândește de fapt când spune „dezactivez AI-ul” — să oprești companiile de AI să se antreneze pe articolele tale — nu ține deloc de o setare din WordPress. Este o problemă de robots și de configurare a serverului.

Ce e core și ce nu e

WordPress core, în varianta self-hosted, nu livrează un asistent de scriere AI, un chatbot AI sau un generator de imagini AI care să pornească din start. Dacă vezi o iconiță AI în editorul de blocuri, ceva a instalat-o.

De unde vin, în realitate, funcțiile AI:

Sursă	Funcție tipică	De unde o oprești
Jetpack	Blocul AI Assistant și panoul din editor	Setări Jetpack, comutatorul de modul
Pluginuri AI de sine stătătoare	Generatoare de conținut, chatboți, scriere de text alternativ	Ecranul de setări al pluginului
Pluginuri SEO	Sugestii AI pentru titlu și descriere	Setările pluginului, de obicei pe fiecare funcție
Page buildere	Generare AI de text și imagini în interfața builderului	Setările builderului sau panoul de cont
Hosturi administrate	Asistenți AI injectați printr-un mu-plugin sau prin panou	Panoul de control al hostingului
WordPress.com	Unelte de scriere AI găzduite	Setările contului WordPress.com, nu ale site-ului tău

Proiectul WordPress are într-adevăr o dezvoltare continuă legată de AI — pluginuri experimentale de tip feature care ar putea ajunge cândva în core. Dacă ești pe o versiune recentă și vezi ceva cu iz de AI pe care nu îl poți atribui unui plugin, verifică mai întâi lista de pluginuri instalate și abia apoi changelogul versiunii tale, în loc să presupui că e o setare implicită din core pe care trebuie să o filtrezi. Prudența e intenționată: afirmațiile legate de o anumită versiune se învechesc repede aici, iar una greșită te pune să editezi fișiere degeaba.

Găsește ce o adaugă cu adevărat

Dezactivează pluginurile în grupuri până când panoul AI dispare. E o metodă brutală, dar îți dă un răspuns clar în loc de o presupunere.

Dacă ai WP-CLI, listează mai întâi tot ce e activ:

wp plugin list --status=active --field=name

Apoi verifică dacă hostingul a injectat cod, pentru că acesta nu apare în ecranul obișnuit de pluginuri:

ls -la wp-content/mu-plugins/

Pluginurile must-use se încarcă automat și nu pot fi dezactivate din admin. Dacă hostingul tău a pus acolo un asistent AI, singura eliminare curată trece prin panoul lor de control — ștergerea fișierului înseamnă, de obicei, că acesta reapare la următoarea actualizare a platformei.

Cum îl oprești corect

Folosește setarea proprie a pluginului. Este răspunsul plictisitor și este cel corect. Jetpack, în special, e construit din module care se opresc independent, așa că poți dezactiva AI Assistant păstrând statisticile, backupurile sau orice altceva folosești. Majoritatea pluginurilor AI de sine stătătoare au o bifă de activare/dezactivare pentru fiecare funcție.

Dacă nu folosești pluginul pentru nimic altceva, dezactivează-l complet. Un plugin AI lăsat instalat, dar „dezactivat” din setări, tot își încarcă codul la fiecare cerere. Dezactivarea completă e mai rapidă, mai sigură și măsurabil mai ușoară decât orice filtru.

Dezagățarea cu remove_action este ultima soluție. Chiar funcționează, dar doar când știi exact numele hook-ului, callback-ul și prioritatea cu care s-a înregistrat pluginul, și doar până când pluginul redenumește vreunul dintre ele:

// Only if you have verified the exact hook, callback and priority.
// Runs late so the plugin has already registered its own hooks.
add_action( 'init', function () {
    remove_action( 'enqueue_block_editor_assets', array( 'Some_Plugin_Class', 'enqueue_ai_panel' ), 10 );
}, 99 );

Costul sincer: soluția se strică în tăcere. O actualizare de plugin schimbă numele clasei, eliminarea ta nu mai potrivește nimic, panoul AI revine și nicio eroare nu te anunță. Dacă mergi pe varianta asta, notează-ți ce ai eliminat și verifică din nou după fiecare actualizare a acelui plugin.

Aceeași prudență se aplică și la dezînregistrarea panourilor de editor din JavaScript. Este o posibilitate reală, dar intri în înregistrarea altui plugin printr-un identificator text, iar acel identificator nu e un contract public.

Nu încerca să blochezi funcțiile AI editând constante din wp-config.php găsite într-o postare de pe forum. Nicio constantă din core nu oprește AI-ul unui plugin terț. Dacă un fragment de cod pretinde altceva și nu poți urmări constanta până în documentația acelui plugin, nu face nimic.

Cealaltă întrebare: cum oprești antrenarea AI pe conținutul tău

Este o chestiune separată și acolo stă cea mai mare parte a îngrijorării reale. Oprirea unui panou din editor nu schimbă absolut nimic legat de cine îți accesează articolele. Controlul acela se face în robots.txt și, dacă vrei să fie și impus, la nivel de server.

WordPress servește un robots.txt virtual, atâta timp cât nu există un fișier real în rădăcina site-ului. Dacă există un fișier fizic, WordPress se dă complet la o parte și acel fișier ajunge la crawlere. Ca să îl editezi pe cel virtual, folosește un filtru:

add_filter( 'robots_txt', function ( $output ) {
    $output .= "\nUser-agent: GPTBot\nDisallow: /\n";
    return $output;
}, 10 );

Construirea regulilor de mână e locul unde apar greșelile — un token scris greșit nu blochează nimic, iar un Disallow: / rătăcit pe agentul nepotrivit te poate scoate din căutarea obișnuită. Generatorul de robots.txt asamblează blocurile pentru crawlerele AI împreună cu directivele tale normale de căutare, ca să vezi tot fișierul înainte să ajungă live.

Tokenuri publicate de operatorii mari, pe care aceștia spun că le respectă:

Token	Operator	Ce acoperă
GPTBot	OpenAI	Accesarea conținutului pentru antrenarea modelelor
ChatGPT-User	OpenAI	Cereri pornite de la o solicitare a unui utilizator
ClaudeBot	Anthropic	Accesarea conținutului
Google-Extended	Google	Folosirea conținutului tău pentru antrenarea Gemini, nu accesarea în sine
Applebot-Extended	Apple	Folosirea pentru antrenarea modelelor generative Apple
PerplexityBot	Perplexity	Accesarea conținutului
CCBot	Common Crawl	Arhiva masivă pe care se antrenează multe modele

Două avertismente sincere. Primul: robots.txt este voluntar. Operatorii serioși îl respectă; orice vrea să îl ignore o va face. Al doilea: blocarea nu e gratuită. Unele dintre aceste tokenuri decid dacă apari în răspunsurile generate de AI care te citează și îți dau link. Le blochezi pe toate și pierzi acea sursă de trafic odată cu expunerea la antrenare. Decide care dintre ele chiar te interesează.

Pentru o măsură care se impune, nu o simplă rugăminte, blochează la nivel de server. În .htaccess pe Apache:

<IfModule mod_setenvif.c>
  SetEnvIfNoCase User-Agent "GPTBot|CCBot|ClaudeBot|PerplexityBot" ai_bot
  <RequireAll>
    Require all granted
    Require not env ai_bot
  </RequireAll>
</IfModule>

Șirurile de user-agent se falsifică banal de ușor, așa că asta oprește traficul onest, dar nedorit, nu un scraper hotărât. Blocarea după intervale de IP verificate la nivel de CDN sau firewall e mai puternică, iar majoritatea CDN-urilor oferă acum o regulă anti-boți AI cu un singur clic, mai ușor de întreținut decât o listă scrisă de mână.

Ce nu funcționează

llms.txt este o propunere, nu un standard. Este un fișier markdown sugerat, care îți descrie site-ul pentru modelele de limbaj. Niciun operator important nu s-a angajat să îl trateze ca pe un control de acces. Adăugarea lui nu costă nimic și poate ajuta la felul în care modelele te citesc, dar nu blochează nimic.

Metatagurile noai și noimageai sunt respectate de aproape nimeni. Au apărut din politica unei singure platforme, nu dintr-un acord la nivel de industrie. Nu strică să le adaugi; strică să te aștepți să funcționeze.

Un plugin care promite să „blocheze AI-ul” de obicei doar scrie reguli de robots. E în regulă, și e exact ce poți face și tu singur în zece rânduri. Nu e o barieră juridică sau tehnică și niciun plugin nu o poate transforma în așa ceva.

Blocarea crawlerelor AI nu scoate conținutul deja intrat într-un model antrenat. Nimic din ce adaugi azi nu îți retrage retroactiv articolele dintr-un model lansat anul trecut. Regulile din robots privesc doar înainte.

Dacă tot vezi un panou AI

Dacă toate pluginurile sunt oprite și panoul persistă, verifică din nou wp-content/mu-plugins/, apoi panoul hostingului, apoi dacă nu cumva ești pe WordPress.com în loc de self-hosted — acolo comutatoarele stau în setările contului, nu în adminul site-ului. Iar dacă funcția reapare după o actualizare de plugin, aceea e semnătura unui fragment de dezagățare care a încetat să mai potrivească, nu a unei setări implicite din core.