Is It WP? Verifica indizi WordPress

Esamina indizi WordPress pubblici, discovery REST e file visibili di temi e plugin senza dichiarare certezze sul server.

Come usarlo

Esamina indizi WordPress pubblici, discovery REST e file visibili di temi e plugin senza dichiarare certezze sul server.

Passaggio 1

Scegli una pagina pubblica

Esempio illustrativo, non un risultato in tempo realehttps://clocktools.app/

Controlla solo destinazioni autorizzate. I parametri dell’URL iniziale vengono rimossi; non inviare segreti.

Passaggio 2

Confronta gli indizi

Esempio illustrativo, non un risultato in tempo realewp/v2 · wp-content

Esamina namespace REST, generatore e percorsi dei file. Un accesso fallito non prova l’assenza.

Passaggio 3

Conserva le prove

Esempio illustrativo, non un risultato in tempo realeJSON

Esporta il rapporto datato per migrazioni e passaggi di gestione. I nomi visibili non sono un inventario completo.

Usi pratici

Preparare una migrazione

Prima di preventivare una migrazione, controlla separatamente homepage e pagina pubblica rappresentativa. Registra URL finale, REST, temi e slug dei plugin. Chiedi poi inventario reale e modalità di distribuzione. Gli indizi orientano domande su moduli e contenuti, senza stabilire sforzo o tutte le dipendenze server.

Indagare sulla cache

Dopo un cambio di tema o plugin, una pagina può citare vecchi file. Esporta un rapporto datato e confrontalo con configurazione e cache correnti. Apri la stessa pagina anonimamente prima di eliminare qualcosa. Generator o stylesheet vecchi descrivono la risposta servita, non una necessità di reinstallare WordPress.

Passare al supporto

Per il supporto conserva JSON, non solo punteggio. Risposta, prove fallite e percorsi di esempio spiegano gli indizi. Rimuovi URL sensibili dai ticket. Condividere prepara un’altra ispezione senza inviare la sessione o riprodurre automaticamente i risultati precedenti.

Contesto e funzionamento

Rapporto sugli indizi WordPress per wordpress.org
Il rapporto di wordpress.org elenca indizi pubblici di WordPress e dati della risposta. Gli indizi supportano il rilevamento, ma non rivelano la configurazione privata del sito.

Scoprire è meglio che indovinare una cartella

WordPress documenta la relazione https://api.w.org/ nell’HTML o nell’intestazione HTTP Link. Permette di trovare la radice API anche per installazioni in sottocartelle. Il controllo cerca i namespace del nucleo.

wp/v2 è un indizio significativo, ma una richiesta fallita non prova l’assenza di WordPress. Firewall, restrizioni e architetture disaccoppiate possono nasconderlo. Il punteggio somma pesi fino a 100; non è una probabilità statistica. Guida WordPress alla discovery REST.

Visibile non significa installato o completo

Il percorso di un tema può rivelarne l’identificatore; l’intestazione pubblica di style.css può indicare nome, versione o tema genitore. I valori possono essere modificati o obsoleti. Un tema figlio non equivale al genitore.

I percorsi dei plugin mostrano solo riferimenti nella risposta esaminata. Plugin lato server, file raggruppati e cartelle rinominate possono non lasciare tracce riconoscibili. Una versione non prova sicurezza, licenza o completezza dell’inventario. Documentazione WordPress sui fogli di stile.

Esempio: esportazione statica con tracce WordPress

La pagina mostra un generatore WordPress e immagini wp-content, ma l’API risponde 404. Potrebbe essere un’esportazione, una cache o un’API protetta. Chiedi al proprietario come viene generata e servita la pagina; non considerare dimostrato un server WordPress attivo.

Generatore
Indizio visibile
REST HTTP 404
Namespace del nucleo non osservato
Passo successivo
Confermare l’origine con il proprietario

Leggere le prove prima del verdetto

Ogni segnale è trovato, non trovato o non disponibile. Non trovato significa assenza dell’indizio nella risposta esaminata; non disponibile indica richiesta o risposta inutilizzabile. Se un firewall serve una pagina di errore, la mancanza di un tema dice poco sulla pagina reale dei visitatori. La vista compatta mostra le prime sei righe di segnali e i campi principali. Esporta JSON per l’elenco completo e i metadati restituiti dallo stylesheet, inclusi gli indizi non presenti nella vista compatta.

I pesi sono espliciti: nucleo REST 45, generator WordPress 35, discovery 25, percorsi content e includes 20 ciascuno, script riconoscibili 15, prefissi cookie 12, discovery di pubblicazione 10 e pingback 8. La somma è limitata a 100. Dieci riferimenti a un plugin non sono dieci segnali indipendenti; conteggio di risorse e peso rispondono a domande diverse.

Conta anche la pagina principale. Errore, troncamento o risposta non HTML restano inconcludenti malgrado indizi. Con HTML utilizzabile, REST core più un altro segnale, oppure almeno tre segnali per 55 punti, danno prove forti. Altrimenti 30 o più possono dare probabile; piccoli valori positivi restano inconcludenti. Sono regole del motore, non probabilità né accesso al backend.

Esempi fissi, non rilevamenti in tempo reale
Indizi osservatiPuntiInterpretazione
Solo wp-content20Inconcludente: un percorso è prova limitata.
Solo generator35Probabile con HTML utilizzabile, non prova del backend.
wp/v2 e discovery70Prove pubbliche forti con HTML utilizzabile.
Più indizi su pagina HTTP 403Secondo gli indiziInconcludente: pagina prevista non tutta ispezionata.
Nessun indizio in HTML utilizzabile0Nessun segnale pubblico, non zero per cento di probabilità.

Perché pagine diverse espongono API diverse

Il controllo preferisce l’URL discovery pubblicato in Link o HTML. In assenza ricava un candidato wp-json/ da percorsi content visibili o origine della pagina. Non cerca ogni directory. Una pubblicazione sotto /news/ può differire da una homepage di altro sistema, specie se questa non espone una relazione utile.

La documentazione di discovery REST definisce https://api.w.org/. Qui conta inoltre che il candidato restituisca namespace o rotte core riconoscibili. Link API e indice utilizzabile sono prove distinte: un collegamento pubblicato non conferma il funzionamento dell’endpoint durante il test.

Namespace personalizzati sono utili ma non inventario automatico: tema o codice proprio possono registrare rotte. RSD, Windows Live Writer e X-Pingback aggiungono pesi minori. ClockTools osserva riferimenti senza richieste di pubblicazione o test di credenziali. Un’interfaccia disattivata cambia gli indizi senza necessariamente cambiare CMS.

Usare i percorsi per chiarire l’inventario

Un asset in /wp-content/themes/atelier/ rivela uno slug di directory. Il candidato principale ha più riferimenti, con ordine alfabetico in parità; non è la selezione autenticata del tema attivo. Si può leggere style.css convenzionale e campi pubblici. Senza nome, lo slug resta slug, non un prodotto inventato.

Due directory richiedono approfondimento, non allarme automatico. Nel modello di tema figlio, Template indica la directory padre. Con atelier-child e atelier, chiedi dove stanno personalizzazioni e file padre. Cache o risorse indipendenti spiegano anch’essi un secondo slug. Conferma nell’amministrazione prima di aggiornare.

Percorsi /wp-content/plugins/ e /wp-content/mu-plugins/ sono raggruppati per slug e riferimenti. La documentazione dei plugin must-use spiega il caricamento particolare, ma un percorso visibile non svela tutto. Una pagina contatti può caricare moduli assenti nella homepage. Ispezionala separatamente per la migrazione e confronta con inventario attivo e must-use del proprietario.

Plugin solo server, bundle, percorsi propri e riscritture CDN restano talvolta invisibili; una cache può conservare vecchi riferimenti. Una versione del tema riguarda il tema; ?ver= arbitrario non identifica il core. La versione WordPress viene letta solo da generator esplicito. Un campo vuoto può quindi essere corretto.

Theme Name è il nome visualizzato pubblicato; Author e Theme URI sono attribuzioni dichiarate. Text Domain identifica il dominio di traduzione, non l’host del sito. Questi campi aiutano a trovare documentazione, ma sono testo modificabile. Non autenticano proprietà, diritto di licenza o disponibilità di aggiornamenti per i file distribuiti.

Separare produzione dei contenuti e distribuzione

Un sito tradizionale serve HTML WordPress, una cache una copia precedente. Un export statico conserva markup e percorsi senza eseguire WordPress a ogni visita. Un frontend headless usa contenuti da servizio privato o distinto senza pubblicare percorsi familiari. Si osserva la distribuzione, non ogni sistema della produzione.

Questo spiega entrambe le sorprese. Punteggio alto su export può descrivere bene gli indizi, mentre affermare backend attivo sarebbe sbagliato. Nessun segnale su headless può essere corretto anche se la redazione usa WordPress. Chiedi dove si scrive, costruisce e serve il contenuto: sono risposte più utili di una disputa sull’etichetta.

Nell’esempio fisso, generator e wp-content sommano 55 senza REST core utilizzabile. Due indizi non soddisfano la regola dei tre per prove forti; con HTML valido può apparire probabile. Se la pagina è bloccata o troncata resta inconcludente. Altri indizi copiati possono aumentare il punteggio senza provare un backend in esecuzione.

Indagare risultati inattesi senza pagine private

Parti da URL inserito e finale. Un redirect può portare a host diverso, traduzione o challenge. Confronta stato e byte ispezionati prima dei componenti. HTML troncato può lasciare fuori indizi successivi, quindi la lista non è completa. Verifica quale risposta pubblica è stata realmente letta.

L’ispezione è anonima e limitata: una pagina, un candidato REST ed eventualmente uno stylesheet. Non esegue JavaScript. La query iniziale viene rimossa; pagine dipendenti da parametri possono differire dal browser. Non aggirarlo con link firmati o di login. Usa percorsi pubblici normali e controlla pagine autenticate localmente.

Per API bloccata o limite conserva la riga non disponibile, riprova più tardi e rivedi proprie regole se opportuno. Non togliere protezioni per migliorare il punteggio. Controlla versioni e aggiornamenti nell’amministrazione: qui non si confrontano vulnerabilità. Una correzione utile richiede URL sicuro, ora, indizio atteso e risposta pubblica, non solo un numero contestato.

Metodologia

Si ispezionano HTML pubblico anonimo limitato, un candidato REST e stylesheet disponibile, con destinazioni pubbliche validate e redirect limitati. Sessione e JavaScript non vengono usati. Trovato, non trovato e non disponibile restano separati. I componenti sono riferimenti esposti; cronologia e JSON non sono inventari autenticati.

Limiti

Indizi forti non sono certezza. Contenuti possono essere copiati, memorizzati nella cache o ingannevoli. L’assenza di indizi non esclude un WordPress nascosto. Non è una scansione delle vulnerabilità, un inventario dei plugin o un’ispezione autenticata.

Correzioni

Segnala un problema riproducibile tramite la pagina dei contatti, indicando l’URL dello strumento, un input non riservato, l’ora del controllo, il risultato atteso e le prove della fonte. Allega se possibile la risposta pubblica, senza dati dell’account né link segreti. Una fonte cambiata non implica necessariamente un errore di calcolo. Confronta prima lo stesso nome, pagina e momento.

MetodologiaCorrezioni

Domande frequenti

Il punteggio è una probabilità di installazione di WordPress?

No. Somma pesi espliciti con limite e considera HTML utilizzabile per il verdetto. Leggi prove e risposta. Zero può corrispondere a headless; un valore alto a copia o cache. Nessuno è una probabilità misurata.

Perché resta inconcludente pur con indizi WordPress?

La pagina può essere bloccata, troncata, non HTML o in errore. Gli indizi conservati non rendono significative le assenze. Salva il rapporto, verifica URL e stato e usa una pagina pubblica normale invece di forzare sì o no.

Un sito statico può sembrare WordPress?

Sì. Generator, asset e discovery possono sopravvivere a export o cache. Il risultato descrive gli indizi. Chiedi come vengono costruite e servite le pagine per distinguere export e applicazione; la pipeline privata non è visibile qui.

Il tema riportato deve essere attivo?

No. Si sceglie tra directory pubblicamente referenziate, non nell’amministrazione. Tema figlio, padre, cache o risorsa aggiuntiva possono mostrare più slug. Leggi metadati e conferma il sistema prima di installare, acquistare o aggiornare temi simili.

Sono elencati tutti i plugin installati?

No. Si raggruppano risorse riconoscibili della pagina. Un modulo compare magari solo nei contatti, un plugin server mai. I namespace REST restano indizi API, non dichiarazioni automatiche di plugin.

Perché manca la versione nonostante valori ?ver=?

Possono indicare plugin, tema o cache invece del core. Non si usano per indovinare WordPress. Un generator esplicito può fornire un indizio; senza di esso controlla l’amministrazione anziché usare un numero di asset.

REST 404 o 403 prova che non è WordPress?

No. Il candidato può essere limitato, indisponibile o inadatto all’installazione. Discovery e core utilizzabile sono distinti. Guarda anche HTML e, sul tuo sito, percorso e accesso previsti senza rimuovere protezioni per il rilevatore.

Il controllo stabilisce la sicurezza del sito?

No. Lo strumento non verifica gli accessi, non enumera gli utenti, non tenta di sfruttare vulnerabilità dei componenti e non confronta le versioni con una banca dati delle vulnerabilità. I nomi visibili aiutano a esaminare le informazioni esposte pubblicamente, ma non a valutare la sicurezza dell’intero sito. Per questo servono un inventario consultato con accesso autenticato e una valutazione di sicurezza separata e autorizzata.

Perché differisce dal mio browser autenticato?

Cookie e autorizzazione non passano, JavaScript non gira e la query iniziale è rimossa. Il browser può ricevere contenuti personalizzati, cache diversa o API autenticata. Confronta lo stesso percorso anonimamente e conserva URL finale e ora.