Localizar a marcação de schema para e-commerce significa fazer com que seus dados estruturados falem a língua dos seus clientes e dos mecanismos de busca. Para lojas online internacionais, especialmente aquelas voltadas para regiões diversas como a UE, o Sudeste Asiático ou o Oriente Médio, a localização de schema é fundamental para ajudar os mecanismos de busca a exibir os rich snippets corretos com base no idioma, na região e na moeda do usuário.
Ao localizar os principais tipos de schema, como informações de produto, preços e dados da empresa, você melhora a visibilidade, a confiança e as taxas de conversão em diferentes mercados. Este artigo explora quais elementos de schema localizar, erros comuns a evitar e as melhores práticas para ajudar seu site de e-commerce internacional a ter o melhor desempenho possível.
A importância da localização de schema para o seu e-commerce
A localização de schema garante que os seus dados estruturados estejam alinhados com o idioma, a moeda e o contexto cultural de cada mercado que serve. Isto melhora a sua visibilidade nos resultados de pesquisa local e melhora a experiência do utilizador em diferentes regiões.
- Melhora o SEO local – Quando a marcação de schema usa idioma, moeda e campos específicos da região localizados, os mecanismos de busca podem entender melhor e corresponder seu conteúdo à intenção de busca local.
- Permite a exibição de rich snippets precisos – Rich snippets, como preços, disponibilidade de produtos e avaliações, refletirão o contexto local do usuário, gerando confiança e melhorando as taxas de cliques.
- Melhora a experiência do usuário multilíngue – O schema localizado ajuda a garantir consistência entre o conteúdo visível da página e os dados estruturados por trás dele, evitando confusão para visitantes internacionais.
- Suporta conformidade e expectativas regionais – Diferentes regiões podem ter requisitos específicos de dados (como IVA na UE ou zonas de envio no Sudeste Asiático) que podem ser atendidos através do schema.
- Aumenta as taxas de conversão nos mercados-alvo – Os usuários que veem idioma, moeda e informações de contato familiares nas prévias de pesquisa têm mais probabilidade de confiar e interagir com o seu site.
Principais tipos de schema de e-commerce que exigem localização
Marcação de esquema é um tipo de dados estruturados adicionados ao HTML do seu site que ajudam os motores de busca a compreender o contexto do seu conteúdo. Para o comércio eletrónico, potencia resultados enriquecidos como avaliações de produtos, preços, disponibilidade e muito mais, fazendo com que os seus anúncios se destaquem na pesquisa. Ao direcionar mercados internacionais, simplesmente usar o esquema não é suficiente, também precisa de o localizar.
Abaixo estão os principais tipos de schema que precisam de uma localização cuidadosa para o sucesso do e-commerce global.
Product
O schema de Produto fornece informações estruturadas, como nome do produto, descrição, SKU, marca, imagem e avaliações. Ao localizar este schema, é essencial traduzir os nomes e as descrições dos produtos com precisão, não apenas palavra por palavra, mas de uma forma que ressoe com as normas culturais e linguísticas de cada mercado.
Vários elementos-chave devem ser adaptados a cada mercado-alvo para localizar corretamente o esquema de Produto. Esses elementos vão além da tradução básica — adaptação cultural, conformidade com as expectativas locais e alinhamento com o SEO específico do idioma. Aqui estão os principais aspectos do esquema de Produto que devem ser localizados.
- name: Traduza o nome do produto para preservar o significado e o apelo no idioma local. Evite traduções literais que possam confundir ou induzir o público local ao erro.
- description: Localize as descrições com atenção ao tom, às unidades de medida (por exemplo, polegadas vs. centímetros) e à terminologia familiar aos públicos regionais.
- image: Embora não seja baseada em texto, a imagética localizada pode refletir preferências culturais. Por exemplo, imagens de vestuário em mercados do Oriente Médio podem exigir visuais mais modestos.
- brand: Se a marca tiver nomes diferentes em regiões diferentes, ou se as submarcas forem mais reconhecíveis localmente, certifique-se de que o campo da marca reflete isso.
- sku: Embora muitas vezes seja consistente globalmente, se você usar códigos ou identificadores regionais de produtos, atualize o sku para corresponder ao catálogo local.
- review e aggregateRating: Estes elementos também podem beneficiar da localização. Se as avaliações dos clientes forem incluídas no esquema, certifique-se de que estão escritas no idioma local e refletem o feedback dos clientes específico da região.
- offers (incorporado no Product): Isso inclui preços e disponibilidade, que devem refletir a moeda local, os formatos e os níveis de estoque. Considere também adaptar priceValidUntil aos ciclos de vendas locais.
Por exemplo, um produto “Casaco de Inverno – Série Ártica” em inglês pode ser localizado como “Chaqueta Invernal – Serie Ártica” em espanhol. Nos mercados árabes, não só o nome e a descrição precisam ser traduzidos para o árabe, como também pode ser necessário adaptar as imagens e os destaques das características àquilo que é considerado apelativo ou recatado.
Não localizar o esquema Product pode criar uma discrepância entre o que é apresentado no snippet de pesquisa e o que está na página real do produto, prejudicando a confiança e reduzindo as taxas de cliques. Ao adaptar o seu esquema de produto por localidade, garante consistência, melhor alinhamento de SEO e uma experiência de compra mais fluida.
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "Chaqueta Invernal – Serie Ártica",
"description": "Una chaqueta cálida ideal para el invierno, con capucha desmontable y bolsillos amplios.",
"sku": "ARCTIC-ES",
"image": "https://example.com/es/images/arctic-coat.jpg",
"brand": {
"@type": "Brand",
"name": "FrostWear"
}
}
Aqui está um exemplo de marcação de schema de Produto que aparece online ao pesquisar por um produto.
Preços e moeda
O preço é uma das informações mais sensíveis para os compradores online. O schema Offer, normalmente incorporado no schema Product, inclui campos essenciais como price, priceCurrency e availability. Localizar a moeda e os preços é crucial, especialmente quando o seu site se dirige a regiões que não usam USD, EUR ou outras predefinições padrão.
Por exemplo, se você está vendendo no Oriente Médio, seu schema deve refletir os preços em AED ou SAR usando o código de moeda ISO 4217 apropriado, como “priceCurrency”: “AED”. Além disso, o formato do preço deve seguir as convenções regionais — alguns países usam vírgulas em vez de pontos como separadores decimais, ou colocam o símbolo da moeda depois do valor em vez de antes.
Códigos de moeda incorretos ou genéricos na marcação de esquema podem levar a snippets enriquecidos enganosos, compradores confusos e até mesmo penalizações dos mecanismos de busca por inconsistência de dados. Seu esquema deve estar sincronizado com o que os usuários veem na interface e refletir as taxas de conversão em tempo real ou estratégias de preços localizadas. Adaptar esse esquema por idioma ou subdomínio regional é essencial para garantir uma representação precisa em todo o seu site multilíngue. Elementos-chave no esquema de preços que devem ser localizados.
- price: valor numérico do preço formatado para a região local (por exemplo, 99,99 em vez de 99.99).
- priceCurrency: Use o código de moeda ISO 4217 correto (por exemplo, AED, SAR, JPY, etc.).
- Posicionamento do símbolo da moeda: Adapte o símbolo às convenções locais (por exemplo, “99 ر.س” em vez de “SAR 99”).
- availability: Utilize linguagem ou etiquetas localizadas, se aplicável (por exemplo, "In Stock" → "Disponible" em espanhol).
Aqui está um exemplo de um schema localizado para preços adaptado a um mercado do Oriente Médio.
{
"@context": "https://schema.org/",
"@type": "Offer",
"price": "89.99",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock",
"priceValidUntil": "2025-12-31",
"itemCondition": "https://schema.org/NewCondition",
"url": "https://example.com/es/productos/chaqueta-artica"
}
Eis um exemplo de marcação de esquema de preços e moeda que aparece online ao pesquisar por um produto.
Informações comerciais e de contato
Os schemas Organization e ContactPoint definem a identidade da sua empresa e como os clientes podem contactá-lo. A localização aqui envolve mais do que apenas tradução—requer a adaptação de horários de funcionamento, idiomas de suporte e métodos de contacto para se adequarem às expectativas locais.
Ao localizar o schema de empresa e de contacto, melhora a confiança e ajuda os motores de busca a apresentar dados de contacto precisos nos SERPs (especialmente em dispositivos móveis). Isto também ajuda a pesquisa por voz e os assistentes inteligentes a oferecer respostas comerciais corretas com base na localização. Um schema bem localizado garante que os clientes vejam as opções de contacto certas no momento certo, alinhadas com o seu idioma, região e métodos de comunicação preferidos.
Os principais elementos dos esquemas Organization e ContactPoint a localizar incluem:.
- name: Traduza ou adapte o nome da empresa se você usar uma identidade de marca local em diferentes regiões.
- contactType: Use termos localizados para os tipos de suporte (por exemplo, “servicio al cliente” em espanhol).
- telephone: Inclua números de apoio locais com formatos internacionais adequados.
- areaServed: Especifique a região-alvo usando códigos ISO para garantir relevância geográfica.
- availableLanguage: Indique quais os idiomas que a sua equipa de suporte consegue atender (por exemplo, inglês, árabe, francês).
- contactOption: Adicione métodos de contacto específicos da região, como WhatsApp, WeChat ou ferramentas de chat locais.
- url: Direcione os usuários para páginas de ajuda ou contato localizadas, se disponíveis.
Ao adaptar cada um destes campos para cada região-alvo, o seu schema atenderá às expectativas locais e aumentará as chances de ser exibido em resultados de pesquisa relevantes, especialmente aqueles que dependem de interações móveis ou por voz. A seguir, há um exemplo de aplicação do schema.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "YourBusiness",
"url": "https://www.yourbusiness.com",
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+33-1-23-45-67-89",
"contactType": "customer support",
"areaServed": "FR",
"availableLanguage": ["en", "fr"]
}
}
Detalhes de envio e entrega
As expectativas e regras de entrega variam significativamente de país para país. Ao usar tipos de schema como DeliveryTimeSettings, ShippingDeliveryTime ou OfferShippingDetails específicos de cada região, você pode comunicar não apenas a disponibilidade e os prazos estimados de entrega, mas também as regiões atendidas, as tarifas de envio e os prazos de manuseio — todos os quais devem ser localizados para cada mercado. Os elementos de schema de envio que precisam ser localizados incluem.
- shippingDestination: região ou país servido.
- deliveryTime: tempo estimado de entrega no formato local (por exemplo, 2 dias vs. 5-7 dias úteis).
- Taxa de envio: valor do frete na moeda local.
- transitTimeLabel: rótulo usado para descrever o prazo de entrega (como “Expresso”, “Normal” ou “Entrega em 24 horas”).
- handlingTime: tempo de processamento antes do início da entrega.
Por exemplo, um cliente na Alemanha pode esperar a entrega em até 3 dias úteis, enquanto na Indonésia, uma estimativa típica pode ser de 5 a 7 dias. Se o esquema de envio não for localizado, os usuários podem não obter informações relevantes nos resultados de pesquisa, o que os deixa hesitantes em comprar. Aqui está um exemplo de OfferShippingDetails localizado para o mercado alemão.
{
"@context": "https://schema.org",
"@type": "OfferShippingDetails",
"shippingDestination": {
"@type": "DefinedRegion",
"name": "Germany"
},
"deliveryTime": {
"@type": "ShippingDeliveryTime",
"handlingTime": {
"@type": "QuantitativeValue",
"minValue": 1,
"maxValue": 2,
"unitCode": "d"
},
"shippingRate": {
"@type": "MonetaryAmount",
"value": "5.00",
"currency": "EUR"
}
}
Localização da loja e informações comerciais locais
A exibição precisa das localizações das lojas no Google Search ou no Google Maps depende fortemente de um schema LocalBusiness bem localizado. Especialmente quando os usuários pesquisam no seu idioma ou região local, ter as informações corretas aumenta a visibilidade e gera confiança. Os principais elementos do schema LocalBusiness que precisam de localização incluem:.
- name: o nome da empresa é traduzido se for relevante para o contexto local.
- address: o endereço formatado de acordo com as convenções locais, incluindo addressLocality, addressRegion, postalCode e addressCountry.
- telefone: o número de telefone usando o código do país correto e a formatação local.
- openingHoursSpecification: O horário de funcionamento é ajustado aos fusos horários locais e aos hábitos comerciais.
- geo: coordenadas geográficas (latitude e longitude) da localização da loja.
- areaServed: a região ou área atendida pela empresa.
Por exemplo, aqui está um trecho de schema para uma loja que opera em Berlim, Alemanha.
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Modehaus Berlin",
"address": {
"@type": "PostalAddress",
"addressLocality": "Berlin",
"addressCountry": "DE"
},
"telephone": "+49 30 12345678",
"openingHours": "Mo-Fr 10:00-19:00"
}
O seguinte é um exemplo de um esquema de marcação de empresa local.
Navegação em breadcrumb
O esquema BreadcrumbList ajuda a definir a estrutura de navegação do seu site, mostrando aos usuários (e aos mecanismos de busca) onde eles estão dentro da hierarquia do site. Embora isso possa parecer simples, localizar os breadcrumbs é fundamental em um de e-commerce multilíngue para garantir consistência, melhorar o SEO e aprimorar a experiência do usuário.
Por exemplo, um breadcrumb em inglês, espanhol e árabe
- Início > Moda Homem > Casacos
- “Inicio > Moda Masculina > Chaquetas”,
- “الرئيسية > أزياء الرجال > المعاطف”.
Suponha que o esquema de breadcrumb seja deixado em inglês enquanto o conteúdo da página está em outro idioma. Nesse caso, os usuários podem ficar confusos e os mecanismos de busca podem ter dificuldade para indexar corretamente o conteúdo localizado. Isso também pode prejudicar sua estratégia de links internos, pois os breadcrumbs influenciam como a autoridade de link flui pelo seu site.
Elementos-chave no esquema BreadcrumbList que precisam de localização.
- itemListElement.name: O nome visível de cada nível da trilha de navegação deve ser traduzido.
- itemListElement.item: A URL deve apontar para a versão localizada correta de cada página.
- posição: Reflete o nível na trilha de navegação (geralmente permanece o mesmo, mas deve corresponder à estrutura localizada).
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Inicio",
"item": "https://example.com/es/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Moda Masculina",
"item": "https://example.com/es/moda-masculina"
},
{
"@type": "ListItem",
"position": 3,
"name": "Chaquetas",
"item": "https://example.com/es/moda-masculina/chaquetas"
}
]
}
O seguinte é um exemplo de um esquema de marcação de breadcrumb.
Erros comuns na localização de schema para e-Commerce
As empresas frequentemente encontram problemas críticos, mas evitáveis, ao localizar a marcação de schema para sites de comércio eletrônico. Muitos presumem que a tradução por si só é suficiente, mas os dados estruturados devem ser totalmente adaptados ao idioma, à moeda e às expectativas dos usuários de cada região. Esses descuidos podem levar a rich snippets quebrados, baixa visibilidade nos mecanismos de busca ou confusão para o usuário.
Abaixo estão alguns dos erros mais comuns na localização de schema—e por que evitá-los pode afetar significativamente o desempenho e a experiência do usuário no seu site.
Usar apenas um idioma ou moeda
Um dos erros mais frequentes na localização de schema de e-commerce é manter um único idioma ou moeda em todos os dados estruturados do site — mesmo quando o conteúdo do front-end é traduzido. Essa inconsistência confunde tanto os usuários quanto os mecanismos de busca. Um comprador na França pode ler descrições de produtos em francês, mas ver o schema ainda se referindo a USD em vez de EUR, o que pode gerar problemas de confiança.
O schema localizado deve refletir o conteúdo traduzido e os formatos de moeda local. Por exemplo, “priceCurrency”: “EUR” deve substituir “priceCurrency”: “USD” na versão francesa do site, e os campos “name” e “description” no schema de Product devem aparecer em francês. Sem isso, os mecanismos de busca podem não exibir seus anúncios localizados com precisão nos resultados de pesquisa.
Ignorar a localização de idioma e moeda leva a pré-visualizações de rich snippets de baixa qualidade, reduz as taxas de cliques e pode até violar as diretrizes de precisão de dados estruturados. Sempre adapte seu schema por idioma e região, usando hreflang e subdomínios ou caminhos específicos por região.
Os códigos de moeda não estão a ser atualizados corretamente
Muitos se esquecem de atualizar o código da moeda na marcação de schema mesmo quando os comerciantes usam o símbolo correto da moeda localizada no front end. O Schema.org usa códigos padronizados ISO 4217 (como “USD” para o dólar americano ou “JPY” para o iene japonês), e não refletir esses códigos corretamente em “priceCurrency” leva a resultados enriquecidos quebrados ou enganosos.
Por exemplo, se a sua loja nos Emirados Árabes Unidos mostra preços em dirhams, mas ainda usa “priceCurrency”: “USD” no schema, o Google pode interpretar mal o preço do produto ou optar por não exibi-lo de forma alguma. Pior ainda, um cliente pode presumir que um produto é mais barato ou mais caro devido a um contexto de moeda incorreto, levando a taxas de rejeição ou carrinhos abandonados.
Verifique sempre duas vezes os valores de moeda no seu schema, especialmente em lojas com várias moedas que usam geolocalização ou seletores de moeda. Alinhar as informações visuais e estruturadas de moeda melhora a aparência nos resultados de pesquisa e a confiança do cliente.
Omitir campos de schema específicos da região
Outro erro é usar schema genérico entre regiões sem incorporar elementos específicos da região, como “shippingDestination”, “areaServed” ou “availableAtOrFrom”. Esses campos são críticos para comunicar logística e cobertura de serviço, especialmente em envios internacionais ou suporte ao cliente localizado.
Por exemplo, os compradores na Austrália devem ver estimativas de prazo de envio e opções de entrega com base nos padrões locais (por exemplo, “shippingDestination”: { “@type”: “DefinedRegion”, “name”: “Australia” }). Omitir esses detalhes pode levar os motores de busca a assumir que você não faz envios para lá, afetando a capacidade de descoberta na busca local.
Além disso, campos como “areaServed” e “availableAtOrFrom” ajudam a destacar sua empresa em pesquisas do tipo “perto de mim” ou baseadas em região. Se você não estiver usando esses campos de schema em páginas regionais, provavelmente está perdendo oportunidades de busca localizada.
Ignorar o suporte a idiomas RTL
Idiomas como o árabe e o hebraico são lidos da direita para a esquerda (RTL), e não ajustar a marcação de schema para levar isso em conta pode causar problemas de legibilidade e SEO. Embora o schema não seja renderizado visualmente, ele ainda deve refletir o contexto do idioma para corresponder à experiência na página e ao direcionamento de idioma da pesquisa.
Por exemplo, os campos “name” e “description” no schema do produto em uma página em árabe devem ser traduzidos adequadamente e codificados usando o formato Unicode correto. Além disso, a própria página deve usar lang=”ar” e dir=”rtl” no HTML, e o schema deve corresponder ao mesmo.
Negligenciar o suporte a RTL causa inconsistência entre o conteúdo visual e o estruturado, podendo confundir os usuários e afetar a elegibilidade para resultados avançados. Sempre garanta que tanto o idioma quanto a direção de leitura estejam refletidos na estrutura do schema.
Breadcrumbs traduzidos em falta
Os breadcrumbs servem como auxílios de navegação e contribuem significativamente para a ligação interna e o SEO. Um erro comum na localização de schema é manter o schema de breadcrumb no idioma original, mesmo quando o caminho de navegação visível está traduzido.
Por exemplo, se a sua página mostra “Inicio > Moda Femenina > Vestidos” (espanhol para “Home > Women’s Fashion > Dresses”), o seu esquema BreadcrumbList deve refletir isso exatamente. Usar “name”: “Home” em vez de “Inicio” cria uma desconexão e pode afetar negativamente a forma como o Google interpreta a estrutura do site.
Cada nível de breadcrumb (“name”) deve ser localizado, e o “item” correspondente deve apontar para a URL localizada. Manter tudo alinhado garante consistência para usuários e crawlers, melhorando a visibilidade e a indexação.
Reutilizar o mesmo schema para todos os idiomas
O erro mais prejudicial é usar uma abordagem de schema única para todos os idiomas. Reutilizar os mesmos dados estruturados sem adaptar o conteúdo, a moeda, o idioma e o contexto regional anula todo o propósito da localização.
Cada versão localizada do seu site deve ter o seu schema refletindo o conteúdo e os metadados locais. Por exemplo, se você tem páginas de produto separadas para inglês e francês, o schema Product delas deve ter “name”, “description”, “priceCurrency” traduzidos, e até URLs específicos do idioma.
Negligenciar esta prática pode resultar em sinais de pesquisa conflitantes, baixa qualidade de snippet ou até mesmo ações manuais por dados estruturados enganosos. Uma boa prática é manter esquemas separados para cada subdomínio de idioma ou versão com tag hreflang, garantindo que os dados estruturados correspondam ao idioma e à região atendida.
Melhores práticas para localizar marcação de esquema para e-commerce
A marcação de schema desempenha um papel crucial na forma como os motores de busca interpretam e exibem o seu conteúdo. Quando localizada corretamente, aumenta a sua visibilidade nos SERPs locais, melhora as taxas de cliques e aprimora a experiência de compra para utilizadores em todo o mundo.
Aqui estão as melhores práticas que todo negócio global de comércio eletrônico deve seguir para aproveitar ao máximo a localização.
Use schema específico por idioma em cada página
Cada versão de idioma do seu site deve incluir marcação schema nesse idioma específico. Se você estiver usando subdomínios ou subpastas (por exemplo, example.com/en/ para inglês e example.com/de/ para alemão), cada um deve conter um schema único e adequado ao idioma.
Se a sua página em alemão ainda usar schema em inglês, o Google pode ter dificuldade em compreender o contexto local da página, e os usuários podem achar a experiência inconsistente com as suas expectativas, por exemplo como abaixo.
País | Campo do schema | Valor localizado |
/fr/pagina-do-produto | “nome” | “Veste d'hiver pour homme” |
“description” | “Une veste chaude pour l'hiver français” | |
“emLinguagem” | “fr” |
Localize os nomes e as descrições dos produtos
Nomes e descrições de produtos não devem apenas ser traduzidos e adaptados culturalmente. Frases que soam atraentes em um país podem não ter o mesmo apelo em outro. Use uma linguagem natural para o público local e alinhada ao seu comportamento de compra.
Conte com tradutores nativos ou especialistas locais para evitar frases estranhas ou mensagens pouco claras. Campos como name, description e brand no seu schema devem refletir o idioma e as preferências locais.
Idioma | nome | descrição |
Inglês | “Jaqueta Elegante Masculina” | “Uma jaqueta estilosa perfeita para o inverno” |
japonês | “メンズウィンタージャケット” | “冬に最適なおしゃれなジャケットです。” |
Defina um preço e uma moeda precisos
O preço é um tema sensível no comércio eletrónico. Não se limite a converter moedas visualmente no seu site — certifique-se de que o seu esquema reflete com precisão a moeda correta utilizando o código ISO 4217 no campo priceCurrency. Os preços também devem ser formatados de acordo com as convenções locais, incluindo decimais e separadores de milhares.
Evite exibir apenas USD em todas as versões de idioma, pois isso pode confundir os usuários ou minar a confiança. Se você usar conversão de moeda em tempo real, certifique-se de que seu esquema permaneça sincronizado. Por exemplo.
País | preço | preçoMoeda | Formato Local |
Japão | 4500 | JPY | ¥4,500 |
Arábia Saudita | 180 | SAR | 180 ر.س |
Localize as informações da empresa
As informações de contato comercial, como endereços, números de telefone e horários de funcionamento, devem ser localizadas por região. Use formatos locais para campos como addressLocality, postalCode e addressCountry. Inclua códigos de discagem internacionais nos números de telefone para facilitar o contato dos usuários com você.
Campos como openingHoursSpecification devem refletir os fusos horários locais e as práticas comerciais. Esses detalhes ajudam a estabelecer confiança e melhorar a aparência da sua empresa nos resultados de pesquisa local. Por exemplo.
País | addressLocality | código postal | Formato de horário de funcionamento |
Espanha | Barcelona | 08001 | Segunda a sexta, das 9:00 às 18:00 |
Tailândia | Chiang Mai | 50000 | Segunda a sábado, das 10:00 às 19:00 |
Estrutura do esquema para idiomas RTL
Idiomas como o árabe e o hebraico são escritos da direita para a esquerda (RTL). Embora o próprio JSON-LD não dependa da formatação visual, qualquer campo de esquema que contenha texto visível — como nome, descrição ou breadcrumb — deve refletir o idioma e a direção corretos para evitar inconsistências entre o conteúdo e a marcação.
Se a sua página está em árabe, mas o schema ainda contém valores em inglês ou conteúdo da esquerda para a direita, isso pode causar confusão tanto para os usuários quanto para os mecanismos de busca. Certifique-se sempre de que o HTML inclua lang=”ar” e que os campos de dados estruturados estejam localizados adequadamente.
Campo | Não localizado (LTR/Inglês) | Localizado (RTL/Árabe) |
nome | Casaco de inverno | Casaco de inverno |
descrição | Um casaco quente para o inverno | Casaco quente perfeito para o inverno |
breadcrumb | Página inicial > Vestuário > Jaquetas | Início > Roupas > Casacos |
Automatize a Localização de Schema com o Linguise
Localizar manualmente a marcação de esquema em vários idiomas pode ser complexo, especialmente ao gerenciar centenas de páginas de produtos dinâmicas. O conteúdo visível e os dados estruturados, incluindo os esquemas Product, Offer, BreadcrumbList e LocalBusiness, devem ser traduzidos. Os rich snippets podem não refletir o idioma, a moeda ou a estrutura corretos para cada região sem uma localização adequada.
Linguise oferece uma solução de tradução automática que se estende aos dados estruturados, traduzindo a marcação de schema e o seu conteúdo. Através do seu Live Editor, pode ajustar manualmente o conteúdo do schema, como nomes de produtos, descrições ou valores de marca, para garantir que refletem com precisão o contexto local. Isto é particularmente útil ao localizar campos do schema Product que exigem nuances culturais e adaptação de palavras-chave para SEO regional.
Além disso, o Linguise suporta a tradução de links e mídia, permitindo a localização de URLs de breadcrumbs, links internos e até referências de imagens. Isso garante que todos os elementos, caminhos de navegação, recursos e dados estruturados estejam alinhados com a versão de idioma correta, ajudando os mecanismos de busca a fornecer resultados enriquecidos mais precisos e relevantes para usuários em todo o mundo.
Conclusion
A localização da marcação de schema é crucial para empresas de comércio eletrónico internacionais que pretendem melhorar a visibilidade nos resultados de pesquisa locais, melhorar os rich snippets e proporcionar aos utilizadores uma experiência multilingue perfeita. Desde nomes de produtos e preços até detalhes de envio e informações comerciais, cada elemento de dados estruturados deve estar alinhado com a língua, a cultura e as expectativas de cada mercado-alvo.
Para simplificar este processo, considere usar o Linguise—uma solução de tradução que não só automatiza a tradução de conteúdo, mas também adapta o seu schema markup, links e mídia por idioma. Com recursos como o Live Editor e tradução para URLs e imagens, usar o Linguise pode ajudar todo o seu site—conteúdo visível e dados estruturados igualmente totalmente localizados e prontos para SEO.
