Nessuna categoria di base WPML Guida completa per URL multilingue puliti

Introduzione: cosa significa “WPML senza categorie”

“No category base WPML” significa rimuovere il prefisso di categoria predefinito di WordPress mantenendo corretti gli URL degli archivi di categoria in ogni lingua WPML. Invece di un archivio in inglese comeexample.com/category/news/, puoi usareexample.com/news/Una versione spagnola potrebbe diventareexample.com/es/noticias/piuttosto cheexample.com/es/category/noticias/.

Il risultato sembra semplice. La configurazione, però, non lo è sempre.

WordPress utilizza regole di riscrittura per mappare URL leggibili alle query di tassonomia. WPML aggiunge un ulteriore livello per directory di lingua, domini o parametri URL. Collega inoltre termini di categoria e slug tradotti. Il metodo di rimozione della base, le impostazioni dei permalink, il tema, il plugin SEO, la cache e le regole del server devono concordare sul percorso finale.

Importante:WPML traduce contenuti multilingue e dati di tassonomia, ma non è, di per sé, un interruttore universale per la rimozione della base di categoria. Utilizza un metodo compatibile con WordPress e mantenuto per rimuovere la base, quindi testalo con WPML.

QueueLingo aiuta i team a spostare i lavori di traduzione WPML attraverso code ospitate e motori di traduzione connessi, in modo che i nomi delle categorie, i contenuti correlati e gli aggiornamenti multilingue possano essere gestiti su larga scala.

Crea un account QueueLingo gratuitoOguarda la demoprima di pianificare un'implementazione multilingue completa del sito.

Perché le categorie di base sono importanti per la SEO multilingue

Un archivio di categorie standard di WordPress utilizza spesso questo schema:

• https://example.com/category/news/
• https://example.com/category/tutorials/

La parolacategoryè la base della categoria. Un sito può sostituirla con un'altra base, come ad esempiotopics, ma lasciando vuoto il campo base della categoria inImpostazioni → Collegamenti permanentiNormalmente significa che WordPress utilizza il suo comportamento predefinito. La rimozione completa della base richiede in genere un plugin compatibile, una funzionalità del tema o una logica di riscrittura personalizzata e attentamente gestita.

In una configurazione multilingue, l'URL può contenere anche un segnale di lingua:

• Elenco:example.com/es/category/noticias/
• Dominio linguistico:example.es/category/noticias/
• Parametro:example.com/category/noticias/?lang=es

WPML supporta directory di lingua, diversi domini o sottodomini e parametri di lingua. L'URL di una categoria è quindi definito da tre elementi: formato della lingua, base della categoria e slug del termine tradotto.

Percorsi di esplorazione e archivi tradotti

I motori di ricerca scoprono gli archivi di categoria attraverso menu, breadcrumb, metadati dei post, sitemap e link interni. Rimuovere un segmento del percorso può rendere un URL più facile da leggere, copiare e riconoscere per gli utenti. Tuttavia, non garantisce un miglioramento del posizionamento. Il vantaggio SEO maggiore deriva dall'avere un URL stabile e indicizzabile per ogni archivio utile.

Un archivio di categoria tradotto dovrebbe normalmente fornire:

• Un successo200risposta.
• Contenuto nella lingua prevista.
• Un URL canonico autoreferenziale.
• Lingua alternativa correttahreflangriferimenti.
• Collegamenti interni che utilizzano l'URL finale pulito.
• Inclusione nella corretta sitemap XML quando l'archivio è indicizzabile.

Google descrive la canonizzazione come il processo di selezione di un URL rappresentativo da pagine duplicate o simili. Reindirizzamenti, annotazioni canoniche, URL della sitemap e link interni possono influenzare tale selezione. Per le pagine multilingue, il canonico dovrebbe normalmente puntare all'URL canonico nella stessa lingua, mentrehreflangcollega le versioni linguistiche equivalenti.

Quando la rimozione migliora l'esperienza utente

Rimuovere la base della categoria è più utile quando le categorie sono un livello di navigazione chiave e i loro slug sono univoci. Una pubblicazione può utilizzare/en/insights/,/de/einblicke/, E/fr/analyses/Questi percorsi sono concisi. Tuttavia, una base visibile può prevenire ambiguità. Un URL come/topics/security/Comunica immediatamente al lettore che la pagina è un archivio tematico. Non rimuovere la base solo perché una struttura più breve sembra "più SEO friendly". Scegli la struttura più chiara e facile da gestire.

Per una revisione più ampia del targeting linguistico, vedere ilGuida SEO multilingue.

Come WPML gestisce gli URL delle categorie

WPML separa il formato URL della lingua dalla traduzione dei termini di tassonomia. Comprendere questa separazione rende la risoluzione dei problemi molto più rapida.

Formati URL della lingua

In WPML → Lingue → Formato URL della linguaWPML supporta tre modelli comuni:

1. Directory: example.com/es/noticias/
2. Domini o sottodomini: example.es/noticias/Oes.example.com/noticias/
3. Un parametro linguistico: example.com/noticias/?lang=es

Le directory sono comuni perché ogni lingua rimane sotto un unico dominio. Domini diversi richiedono DNS e mappatura dei server corretti. I parametri in genere richiedono meno modifiche al server, ma molti proprietari di siti preferiscono URL basati su percorsi per la navigazione pubblica.

Le directory delle lingue WPML sono virtuali. Non creare directory fisiche/es/ or /de/cartelle o forzare le richieste al loro interno.

Termini e slug tradotti

Una categoria ha un nome visualizzato e uno slug. Ad esempio:

• Nome inglese: News; slug:news
• Nome spagnolo: Noticias; slug:noticias
• Nome tedesco: Nachrichten; lumaca:nachrichten

WPML può tradurre categorie, tag e tassonomie personalizzate di WordPress. Le tassonomie devono essere impostate come traducibili inWPML → Impostazioni → Traduzione delle tassonomieÈ possibile rivedere le traduzioni dei termini inWPML → Traduzione della tassonomiae sincronizzare i cambiamenti gerarchici quando cambiano le strutture padre-figlio.

Una base di tassonomia personalizzata può anche includere traduzioni specifiche per lingua. Questo è un aspetto distinto dalla rimozione della base di categorie standard di WordPress. Se il tuo sito non ha una base di categorie, lo slug del termine tradotto diventa il segmento di percorso visibile, il che rende ancora più importante la pianificazione di slug univoci.

Permalink e regole di riscrittura

WordPress non memorizza ogni URL formattato come file fisico. Confronta ogni richiesta con le regole di riscrittura e converte i percorsi corrispondenti in query. Un metodo di rimozione della base modifica queste regole. WPML filtra quindi gli URL e le query in base alla lingua attiva.

Possono verificarsi conflitti quando anche un altro componente modifica il percorso. Le cause più comuni includono:

• Plugin SEO o permalink.
• Reindirizzare i manager.
• Tipi di post personalizzati con slug di riscrittura sovrapposti.
• Temi che registrano tassonomie o percorsi.
• Regole NGINX o Apache a livello di server.
• Reindirizzamenti edge della CDN o risposte di errore memorizzate nella cache.

Testa l'intera infrastruttura, non solo la schermata delle impostazioni di WordPress. Un URL può apparire corretto nell'area di amministrazione, ma restituire la lingua o lo stato errati sul sito.

Vantaggi e svantaggi dell'assenza di una base di categorie in WPML

La decisione non è "gli URL puliti sono buoni e gli URL di base sono cattivi". Si tratta di un compromesso di routing.

Percorsi duplicati

Alcune soluzioni di rimozione della base reindirizzano/category/news/A/news/. Altri fanno caricare entrambe le versioni. Se entrambe restituiscono200I motori di ricerca e i sistemi di analisi potrebbero rilevare percorsi duplicati. Seleziona una versione preferita, reindirizza gli URL obsoleti, utilizza i tag canonici autoreferenziali nelle pagine finali e aggiorna i link interni e le sitemap.

Collisioni di lumache

Senza uno spazio dei nomi come/category/, uno slug di categoria compete nel percorso radice. Immagina che tutti questi vogliano/guides/:

• Una pagina denominata Guide.
• Una categoria denominata Guide.
• Archivio di tipi di post personalizzati.
• Un termine tradotto che diventaguides.

WordPress potrebbe risolvere un percorso e nasconderne un altro, oppure un plugin potrebbe forzare un reindirizzamento. Crea un registro di slug multilingue prima del lancio. Includi pagine, articoli, categorie, tag, tassonomie personalizzate, basi di autori e archivi di tipi di post personalizzati.

Come impostare una base senza categorie con WPML

Utilizza prima una copia di staging. Le modifiche agli URL possono influire su ogni archivio di categoria, collegamento interno, voce della mappa del sito, canonico e reindirizzamento memorizzato nella cache.

1. Eseguire il backup del sito

Crea un backup ripristinabile del database e dei file. Registra le versioni di WordPress, WPML, del tema, del plugin di routing, della cache e del server. Esporta i reindirizzamenti esistenti.

2. Inventariare gli URL esistenti

Esporta ogni archivio di categoria in ogni lingua. Per ogni URL, registra:

• Lingua.
• Nome della categoria e ID del termine.
• Slug corrente.
• Categoria principale, se presente.
• Attuale canonico.
• URL pulito previsto.
• Destinazione di reindirizzamento richiesta.

Eseguite anche una scansione di pagine, articoli, tipi di post personalizzati e archivi di tassonomie per individuare eventuali conflitti. Fatelo prima di modificare il comportamento di riscrittura.

3. Rivedi i permalink di WordPress

AprireImpostazioni → Collegamenti permanentiVerifica che il sito utilizzi una struttura di permalink ben formattata anziché semplici URL di query. Esamina il campo facoltativo "Categoria base", ma ricorda che un campo vuoto non significa necessariamente "rimuovi la categoria base". Potrebbe semplicemente utilizzare il percorso predefinito di WordPress per le categorie.

Scegliete un metodo consolidato per la rimozione della base. Può trattarsi di una funzionalità di permalink compatibile o di codice personalizzato gestito dal vostro team di sviluppo. Evitate di utilizzare contemporaneamente due strumenti che rimuovono entrambi la base.

4. Conferma la configurazione della lingua di WPML

AprireWPML → LingueVerifica il formato URL attivo. Prima di continuare, testa le lingue predefinita e secondaria. Se utilizzi le directory, conferma che il server gestisca i percorsi delle lingue virtuali. Se utilizzi domini separati, verifica DNS, certificati TLS e la stessa mappatura dell'installazione di WordPress.

5. Mappare e tradurre i termini della categoria

In WPML → Impostazioni, rendi le categorie traducibili. Quindi apriWPML → Traduzione della tassonomiae rivedi ogni traduzione. Utilizza slug naturali e unici anziché copiare ciecamente lo slug originale.

Per le categorie gerarchiche, verificare che gli elementi figli tradotti abbiano i corrispondenti elementi genitori tradotti. Sincronizzare le modifiche alla gerarchia ove necessario. Salvare la mappa degli slug come documentazione di rilascio.

6. Abilitare il metodo di rimozione della base e le regole di svuotamento una volta

Attiva il metodo selezionato nell'ambiente di staging. Quindi rigenera le regole di riscrittura. L'azione normale dell'amministratore è aprireImpostazioni → Collegamenti permanentie salvare le impostazioni una volta. I team che utilizzano WP-CLI possono utilizzare l'apposito comando rewrite flush in una distribuzione controllata.

WordPress avverte che l'aggiornamento delle regole di riscrittura è un'operazione dispendiosa. Non eseguirla a ogni richiesta di pagina o con un hook frequente. Attivala solo quando le regole cambiano effettivamente.

7. Testa ogni lingua e ogni modello

Eseguire un test su un set rappresentativo che includa:

• Categorie di primo livello e categorie secondarie.
• Categorie con termini tradotti e non tradotti.
• Archivi impaginati, come/news/page/2/.
• Feed, se il tuo sito li pubblica.
• Richieste di accesso e disconnessione.
• Ogni directory o dominio della lingua configurato.

Per ogni URL finale, controlla il codice di stato, il titolo della pagina, l'intestazione dell'archivio, il linguaggio del corpo, il canonico,hreflang, breadcrumb, voce della mappa del sito e link interni.

8. Aggiungi i reindirizzamenti e distribuisci con attenzione

Crea reindirizzamenti permanenti uno a uno da ogni vecchio URL di categoria al suo nuovo equivalente esatto. Evita di inviare ogni vecchia categoria alla home page. Google consiglia reindirizzamenti permanenti lato server, come301 or 308quando un URL è stato spostato in modo permanente.

Aggiorna i collegamenti interni, i menu, le breadcrumb, gli URL della sitemap, i canonici ehreflangValori da utilizzare per i nuovi percorsi. Eseguire il deployment durante una finestra di monitoraggio, svuotare le cache una volta e mantenere un piano di rollback.

Problemi comuni e soluzioni

Le pagine di categoria tradotte restituiscono un errore 404.

Prima salvaImpostazioni → Collegamenti permanentiuna volta per rigenerare le regole. Quindi conferma che la traduzione della categoria esiste, la sua tassonomia è traducibile e la sua gerarchia padre è valida. Disabilita un solo livello di routing sospetto alla volta nell'ambiente di staging. Se l'origine restituisce200ma l'URL pubblico restituisce404, ispeziona la cache CDN o proxy.

Cicli di reindirizzamento dopo la modifica dei permalink

Un loop spesso significa che due sistemi stanno normalizzando lo stesso URL in modi opposti. Controlla i plugin di reindirizzamento di WordPress, i reindirizzamenti canonici SEO,.htaccesso regole NGINX, reindirizzamenti di lingua WPML e regole edge CDN. Traccia la catena di reindirizzamento completa. L'URL finale dovrebbe restituire200, non reindirizzare a un hop precedente.

Viene visualizzata la categoria di lingua errata

Verifica che ogni termine sia collegato alla traduzione WPML corretta e che la richiesta contenga il contesto linguistico previsto. Controlla i menu e i link del tema codificati. Nei siti con cache, assicurati che la chiave della cache vari in base al meccanismo di selezione della lingua di WPML. Una cache che ignora la directory della lingua, il dominio, il parametro o il cookie può servire l'archivio sbagliato.

I conflitti tra slug nelle lingue

Confronta lo slug problematico con pagine, post, percorsi di allegati multimediali, archivi di tipi di post personalizzati, tag e altre tassonomie. Rinomina un percorso con uno slug chiaro specifico per la lingua. Quindi aggiorna la mappa di reindirizzamento, i collegamenti interni, il canonico,hreflange mappa del sito.

Le regole CDN o di cache mantengono il vecchio comportamento

Svuota la cache delle pagine di WordPress, la cache degli oggetti (ove pertinente), il proxy inverso e la CDN. Rivedi la cache301risposte perché i browser e le reti edge potrebbero conservarle. Testa l'origine separatamente dalla CDN, quindi testa una sessione browser pulita.

Google Search Console segnala la copertura o gli avvisi canonici

Ispeziona sia il vecchio che il nuovo URL. Verifica che il vecchio URL reindirizzi permanentemente al sostituto esatto e che il nuovo URL restituisca200Verifica che il nuovo archivio abbia un record canonico auto-canonico, non sia bloccato dalle regole robots e appaia nella sitemap prevista. Controlla se Google ha selezionato un record canonico diverso. Dopo le correzioni, richiedi la convalida o una nuova scansione tramite il flusso di lavoro di Search Console appropriato.

Flusso di lavoro QueueLingo per la traduzione scalabile di WPML

Le operazioni di ingegneria URL e di traduzione dovrebbero supportarsi a vicenda. Uno sviluppatore può fare/es/noticias/Il problema è stato risolto correttamente, ma la categoria necessita ancora di un nome, uno slug, una descrizione, contenuti collegati e uno stato di revisione precisi.

Un flusso di lavoro scalabile con QueueLingo può seguire queste fasi:

1. Preparare WPML:definire le lingue, le impostazioni di traduzione della tassonomia e la mappa degli slug approvati.
2. Crea offerte di lavoro per traduttori:Invia i contenuti WPML idonei e il relativo testo di tassonomia alle code di traduzione gestite.
3. Seleziona un motore:Indirizza il lavoro a Google Traduttore, Edge Traduttore o ai motori di traduzione LLM supportati in base alle integrazioni configurate dalla tua organizzazione, alla coppia linguistica, al tipo di contenuto, al budget e alle policy sui dati.
4. Risultati della revisione:Verifica la terminologia, i nomi delle categorie, la lunghezza dello slug, l'intento, l'integrità HTML e la formulazione specifica per il mercato locale.
5. Rispondi e pubblica:restituisci le traduzioni approvate a WPML, quindi esegui URL, canonico ehreflangcontrolli.

L'automazione delle code può ridurre il lavoro ripetitivo di esportazione, assegnazione, monitoraggio dello stato e riscrittura. La revisione umana rimane comunque importante, perché una singola traduzione errata della tassonomia può influire sulla navigazione e su molti URL dei post.

Scopri l'hosting di traduzione WPML,guarda una demo, OInizia una prova gratuita.

Lista di controllo per l'implementazione e migliori pratiche

Prima del lancio:

• Eseguire il backup dei file e del database e verificare l'accesso al ripristino.
• Verifica la modifica nell'ambiente di staging con il plugin e lo stack del server di produzione.
• Esporta tutti gli URL delle categorie in ogni lingua.
• Mappa i vecchi URL agli URL finali tradotti.
• Riserva slug di categoria univoci per tutti i tipi di contenuto pubblico.
• Conferma le traduzioni delle categorie e le relazioni padre-figlio in WPML.
• Scegli un metodo di rimozione della base e documenta il proprietario.
• Verifica le directory, i domini o i parametri in base alle impostazioni di WPML.
• Preparare il porro301 or 308reindirizzamenti.
• Aggiorna i collegamenti interni, i canonici,hreflang, breadcrumb e sitemap.

Dopo il lancio:

• Analizza i vecchi e i nuovi set di URL.
• Controlla404, morbido404, 5xx, cicli e lunghe catene di reindirizzamento.
• Analizza il comportamento di Origin, WordPress, CDN e della cache del browser.
• Monitora i log del server e i report di Google Search Console.
• Mantieni attivi i reindirizzamenti.
• Eseguire nuovamente il test dopo gli aggiornamenti di WordPress, WPML, del tema, del plugin di routing o del server.
• Procedure di ripristino dei documenti, gestione dei dati, conservazione delle traduzioni, controllo degli accessi e requisiti di conformità.

Il lancio WPML più sicuro senza base di categoria non è quello con la regola di riscrittura più sofisticata. È quello con una mappa URL completa, slug tradotti univoci, un percorso preferito per ogni archivio e test ripetibili.

Pronti a semplificare il processo di traduzione?Prova QueueLingo gratuitamenteOcontattare le venditeper un flusso di lavoro WordPress multilingue più ampio.

Riferimenti ufficiali

• WPML: Opzioni di formato URL per la lingua —Aprire la documentazione ufficiale
• WPML: Traduzione di categorie di post, tag e tassonomie personalizzate —Aprire la documentazione ufficiale
• Risorse per sviluppatori WordPress:flush_rewrite_rules()—Aprire la documentazione ufficiale
• Google Search Central: Gestire siti multilingue e multiregionali —Aprire la documentazione ufficiale
• Google Search Central: Canonicalizzazione —Aprire la documentazione ufficiale
• Google Search Central: Reindirizzamenti e Ricerca Google —Aprire la documentazione ufficiale