Construindo um Mecanismo de Busca de Compatibilidade do Zero

Se você vende peças que precisam se encaixar em algo -- veículos, máquinas, eletrodomésticos, barcos, equipamentos industriais -- você tem um problema de compatibilidade. Seus clientes precisam responder uma pergunta antes de comprar: "Esta peça se encaixa na minha coisa?" E se seu site não conseguir responder essa pergunta rápido e com precisão, eles vão para alguém que consegue.

Construí sistemas de busca de compatibilidade para lojas de peças automotivas, fornecedores de equipamentos marinhos e até uma empresa vendendo peças de reposição para equipamentos de cozinha comercial. A arquitetura subjacente é surpreendentemente similar em todos eles. A indústria automotiva simplesmente chegou lá primeiro com os padrões de dados ACES/PIES, mas o padrão funciona em todos os lugares.

Vamos quebrar como construir um mecanismo de busca de compatibilidade do zero -- a modelagem de dados, os padrões de UX, a pilha tecnológica e as armadilhas que vão te morder se você não tiver cuidado.

Índice

O que Busca de Compatibilidade Realmente É

Busca de compatibilidade é um sistema de lookup de compatibilidade. Ele mapeia peças para as coisas que se encaixam. Na indústria automotiva, isso é a cascata clássica Ano → Marca → Modelo → Submodelo → Motor. Mas o conceito é universal: é um filtro hierárquico que estreita um universo de peças para as que funcionam para uma aplicação específica.

A interação principal se parece com isso:

  1. Usuário seleciona uma categoria de nível superior (ano, marca, tipo de equipamento)
  2. Cada seleção estreita as opções do próximo dropdown
  3. Após seleções suficientes, o sistema retorna peças compatíveis
  4. Opcional: o usuário pode filtrar ainda mais por tipo de peça, marca, preço, etc.

Isso é fundamentalmente diferente da busca de texto. Um cliente buscando "filtro de óleo" obtém milhares de resultados. Um cliente que seleciona "2019 → Toyota → Camry → 2.5L" e então busca "filtro de óleo" obtém exatamente os três que se encaixam. Essa precisão é o que converte navegadores em compradores.

Por Que Isso Não É Apenas uma Coisa Automotiva

A indústria automotiva padronizou dados de compatibilidade décadas atrás através de ACES (Aftermarket Catalog Exchange Standard) e PIES (Product Information Exchange Standard). Mas o problema de compatibilidade existe em todos os lugares onde peças são vendidas.

Aqui estão indústrias que desperadamente precisam de busca de compatibilidade:

Indústria Exemplo de Hierarquia Tamanho Típico de Catálogo
Automotiva Ano → Marca → Modelo → Motor 500K - 5M+ SKUs
Marinha/Barcos Ano → Fabricante → Modelo → Tipo de Motor 50K - 500K SKUs
Powersports (ATV/UTV) Ano → Marca → Modelo → CC 100K - 1M SKUs
HVAC Marca → Tipo de Unidade → Modelo → Tonelagem 20K - 200K SKUs
Cozinha Comercial Fabricante → Equipamento → Modelo → Série 10K - 100K SKUs
Equipamento Agrícola Ano → Fabricante → Modelo → Configuração 50K - 300K SKUs
Motor Pequeno / Energia ao Ar Livre Marca → Tipo de Equipamento → Modelo → Motor 30K - 200K SKUs
Máquinas Industriais OEM → Série de Máquina → Modelo → Revisão Varia muito

O padrão é idêntico. Apenas os rótulos e a profundidade da hierarquia mudam. Se você está em qualquer uma dessas indústrias e ainda está fazendo clientes rolar por catálogos planos ou usar busca de palavra-chave, você está deixando dinheiro na mesa.

Modelagem de Dados: A Fundação em Que Tudo Repousa

É aqui que projetos de compatibilidade têm sucesso ou falham. Não no frontend. Não na API. No modelo de dados.

A Hierarquia de Equipamento

Você precisa de uma hierarquia flexível que represente a coisa em que uma peça se encaixa. Na indústria automotiva, isso é bem definido. Para outras indústrias, você precisará projetar você mesmo.

Aqui está um esquema generalizado:

-- A "coisa" em que peças se encaixam
CREATE TABLE equipment (
  id UUID PRIMARY KEY,
  level_1 VARCHAR(100), -- p.ex., Ano, Marca
  level_2 VARCHAR(100), -- p.ex., Marca, Tipo de Equipamento
  level_3 VARCHAR(100), -- p.ex., Modelo
  level_4 VARCHAR(100), -- p.ex., Submodelo, Motor, Série
  level_5 VARCHAR(100), -- p.ex., Tamanho do motor, configuração
  created_at TIMESTAMP DEFAULT NOW()
);

-- Índice para lookups em cascata
CREATE INDEX idx_equipment_cascade 
  ON equipment (level_1, level_2, level_3, level_4);

Mas honestamente, prefiro uma abordagem mais flexível para casos de uso não-automotivos:

CREATE TABLE equipment_hierarchy (
  id UUID PRIMARY KEY,
  parent_id UUID REFERENCES equipment_hierarchy(id),
  level_name VARCHAR(50) NOT NULL, -- 'year', 'make', 'model', etc.
  level_value VARCHAR(200) NOT NULL,
  sort_order INT DEFAULT 0,
  is_leaf BOOLEAN DEFAULT FALSE
);

CREATE INDEX idx_hierarchy_parent ON equipment_hierarchy(parent_id);
CREATE INDEX idx_hierarchy_level ON equipment_hierarchy(level_name, level_value);

Este modelo de lista de adjacências permite que você tenha diferentes profundidades de hierarquia para diferentes linhas de produtos. Um motor de barco pode precisar de 4 níveis enquanto um reboque de barco apenas precisa de 3.

O Mapa de Compatibilidade

Esta é a tabela de junção que conecta peças a equipamentos:

CREATE TABLE fitment (
  id UUID PRIMARY KEY,
  part_id UUID NOT NULL REFERENCES parts(id),
  equipment_id UUID NOT NULL REFERENCES equipment_hierarchy(id),
  fitment_notes TEXT, -- "Requer modificação para modelos após junho de 2023"
  position VARCHAR(50), -- 'front', 'rear', 'left', 'right'
  quantity_required INT DEFAULT 1,
  verified BOOLEAN DEFAULT FALSE,
  source VARCHAR(100), -- de onde estes dados de compatibilidade vieram
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE UNIQUE INDEX idx_fitment_unique ON fitment(part_id, equipment_id, position);

Os campos fitment_notes e position são críticos. Um pastilha de freio se encaixa em um Toyota Camry 2020, mas você precisa saber se é para a frente ou trás. Um vedante pode se encaixar em um motor específico mas apenas em modelos fabricados antes de uma certa data.

Por Que Tabelas Planas Vencem EAV Aqui

Tenho visto equipes chegarem a modelos Entity-Attribute-Value para dados de compatibilidade porque parece mais flexível. Não faça isso. EAV torna consultas lentas e complexas. Para busca de compatibilidade, você está fazendo o mesmo padrão de consulta em cascata milhões de vezes. Você quer que seja rápido e previsível. Um modelo plano ou de lista de adjacências com índices apropriados vai superar EAV por 10-50x em lookups típicos de compatibilidade.

Projetando a UX de Dropdown em Cascata

O dropdown ano-marca-modelo é um dos padrões de UI mais reconhecíveis em e-commerce. Funciona porque estreita progressivamente as escolhas, reduzindo carga cognitiva em cada passo.

O Padrão Principal

  1. Primeiro dropdown carrega imediatamente com todas as opções de nível superior
  2. Dropdowns subsequentes estão desabilitados até que seu pai seja selecionado
  3. Cada seleção dispara uma chamada API que popula o próximo dropdown
  4. Seleções são reversíveis -- mudar um dropdown anterior reseta todos os posteriores
  5. Seleção final dispara uma busca ou redireciona para uma página de catálogo filtrada

Considerações Móveis

Dropdowns em cascata no mobile são dolorosos. Seriamente. Elementos <select> nativos no iOS abrem uma roda de scroll que é decente, mas no Android a experiência varia muito por navegador.

Padrões melhores para mobile:

  • Seleção passo-a-passo em tela cheia -- mostre uma escolha por vez com alvos de toque grandes
  • Busca-conforme-você-digita em cada nível -- especialmente importante quando você tem 50+ marcas ou modelos
  • Equipamento recente/salvo -- deixe usuários recorrentes pular a cascata inteiramente

Recurso Garage / Meu Equipamento

Esta é a melhor melhoria de UX que você pode fazer. Deixe usuários salvar seu equipamento (sua "garagem" na gíria de peças de carros) e filtre automaticamente o site inteiro. RockAuto, AutoZone e O'Reilly todos fazem isso. Funciona assim tão bem para um proprietário de barco que quer marcar um livro com seu "2018 Yamaha 242X E-Series" e ter cada página mostrando apenas peças compatíveis.

Armazene em localStorage para usuários anônimos e no banco de dados para os logados. Sincronize-os no login.

Pilha Tecnológica e Arquitetura

Aqui está o que eu buscaria em 2025 para um mecanismo de busca de compatibilidade:

Frontend

Next.js é meu padrão para e-commerce de peças. Você obtém SSR para SEO (crítico -- essas páginas de compatibilidade precisam rankear), excelente experiência do desenvolvedor, e o App Router lida com os padrões de roteamento complexos que a busca de compatibilidade cria. Construímos várias lojas habilitadas para compatibilidade usando nossas capacidades de desenvolvimento Next.js.

Para catálogos menores (menos de 50K SKUs), Astro é surpreendentemente eficaz. Você pode pré-renderizar páginas de compatibilidade no tempo de compilação e elas carregarão instantaneamente. Veja o que é possível com desenvolvimento Astro para catálogos de peças com muito conteúdo.

Backend / API

  • PostgreSQL para os dados de compatibilidade (o modelo relacional é um encaixe natural)
  • Redis para cache de respostas de dropdown em cascata (estas são altamente cacheáveis)
  • Meilisearch ou Typesense para busca de texto completo dentro dos resultados de compatibilidade

Integração CMS

Empresas de peças quase sempre precisam de um CMS headless para gerenciar conteúdo não-compatibilidade: guias de instalação, notas de compatibilidade, posts de blog, descrições de categorias. Os dados de compatibilidade em si devem viver em um banco de dados apropriado, não em um CMS.

A Arquitetura na Prática

┌──────────────┐     ┌───────────────┐     ┌──────────────┐
│   Next.js    │────▶│  Fitment API  │────▶│  PostgreSQL  │
│   Frontend   │     │  (REST/GraphQL)│     │  + Redis     │
└──────────────┘     └───────────────┘     └──────────────┘
       │                     │
       │              ┌──────┴──────┐
       │              │  Meilisearch │
       │              │  (text search)│
       │              └─────────────┘
       │
       ▼
┌──────────────┐
│  Headless CMS │
│  (content)    │
└──────────────┘

Construindo a Camada API

A API de compatibilidade precisa ser rápida. Usuários estão clicando por dropdowns rapidamente, e qualquer lag mata a experiência. Aqui está como construir corretamente.

Endpoints de Lookup em Cascata

// GET /api/fitment/levels?level=1
// Retorna todos os valores level_1 únicos (p.ex., anos)

// GET /api/fitment/levels?level=2&level_1=2024
// Retorna todos os valores level_2 onde level_1 = 2024

// GET /api/fitment/parts?equipment_id=abc-123&part_type=oil-filter
// Retorna peças compatíveis para um equipamento específico

import { NextRequest, NextResponse } from 'next/server';
import { db } from '@/lib/database';
import { redis } from '@/lib/redis';

export async function GET(request: NextRequest) {
  const { searchParams } = new URL(request.url);
  const parentId = searchParams.get('parent_id');
  
  // Verifique o cache primeiro
  const cacheKey = `fitment:children:${parentId || 'root'}`;
  const cached = await redis.get(cacheKey);
  if (cached) return NextResponse.json(JSON.parse(cached));
  
  // Consulte o banco de dados
  const children = await db.query(
    `SELECT id, level_name, level_value, is_leaf 
     FROM equipment_hierarchy 
     WHERE parent_id = $1 
     ORDER BY sort_order, level_value`,
    [parentId]
  );
  
  // Cache por 1 hora (dados de compatibilidade não mudam frequentemente)
  await redis.setex(cacheKey, 3600, JSON.stringify(children.rows));
  
  return NextResponse.json(children.rows);
}

Alvos de Tempo de Resposta

Endpoint Alvo Aceitável
População de dropdown em cascata < 50ms < 150ms
Busca de peça com filtro de compatibilidade < 200ms < 500ms
Catálogo completo com contexto de compatibilidade < 300ms < 800ms

Com cache de Redis, os dropdowns em cascata devem consistentemente atingir menos de 50ms. A busca de peças é onde você vai gastar tempo em otimização.

Lookup de Compatibilidade Reversa

Não esqueça o lookup reverso -- "No que esta peça se encaixa?" Isto é essencial para páginas de detalhe de produto:

SELECT eh.* FROM equipment_hierarchy eh
JOIN fitment f ON f.equipment_id = eh.id
WHERE f.part_id = $1
ORDER BY eh.level_value;

Exiba isso como uma tabela de compatibilidade na página do produto. É ótimo para SEO e ajuda clientes a verificar compatibilidade.

Implementação Frontend

Aqui está um componente React para o seletor de compatibilidade em cascata que usei como ponto de partida em múltiplos projetos:

import { useState, useEffect } from 'react';

interface FitmentLevel {
  id: string;
  level_name: string;
  level_value: string;
  is_leaf: boolean;
}

export function FitmentSelector({ onComplete }: { onComplete: (id: string) => void }) {
  const [selections, setSelections] = useState<FitmentLevel[]>([]);
  const [currentOptions, setCurrentOptions] = useState<FitmentLevel[]>([]);
  const [loading, setLoading] = useState(false);

  useEffect(() => {
    // Carregue o nível raiz na montagem
    fetchChildren(null);
  }, []);

  async function fetchChildren(parentId: string | null) {
    setLoading(true);
    const url = parentId 
      ? `/api/fitment/levels?parent_id=${parentId}`
      : '/api/fitment/levels';
    const res = await fetch(url);
    const data = await res.json();
    setCurrentOptions(data);
    setLoading(false);
  }

  function handleSelect(option: FitmentLevel) {
    const newSelections = [...selections, option];
    setSelections(newSelections);
    
    if (option.is_leaf) {
      onComplete(option.id);
    } else {
      fetchChildren(option.id);
    }
  }

  function handleReset(index: number) {
    const newSelections = selections.slice(0, index);
    setSelections(newSelections);
    const parentId = index > 0 ? newSelections[index - 1].id : null;
    fetchChildren(parentId);
  }

  return (
    <div className="fitment-selector">
      {selections.map((sel, i) => (
        <button key={i} onClick={() => handleReset(i)} className="fitment-breadcrumb">
          {sel.level_value} ×
        </button>
      ))}
      
      {!selections[selections.length - 1]?.is_leaf && (
        <select 
          onChange={(e) => {
            const option = currentOptions.find(o => o.id === e.target.value);
            if (option) handleSelect(option);
          }}
          disabled={loading}
          defaultValue=""
        >
          <option value="" disabled>
            {loading ? 'Carregando...' : `Selecione ${currentOptions[0]?.level_name || '...'}`}
          </option>
          {currentOptions.map(opt => (
            <option key={opt.id} value={opt.id}>{opt.level_value}</option>
          ))}
        </select>
      )}
    </div>
  );
}

Isto é intencionalmente simples. Em produção, você adicionaria navegação de teclado, rótulos ARIA, estados de carregamento, tratamento de erros e visualizações otimizadas para mobile. Mas o padrão principal é sólido.

Desempenho de Busca e Otimização

Páginas de Compatibilidade Pré-computadas

Para SEO, você quer páginas indexáveis para combinações de compatibilidade populares. "Filtros de óleo Toyota Camry 2024" deveria ser uma página real que o Google pode rastrear, não apenas um resultado de busca renderizado com JavaScript.

Com Next.js, use rotas dinâmicas com ISR (Incremental Static Regeneration):

// app/parts/[...fitment]/page.tsx
export async function generateStaticParams() {
  // Gere páginas para o equipamento mais popular
  const popular = await db.query(
    `SELECT id, level_1, level_2, level_3 
     FROM equipment 
     ORDER BY search_count DESC 
     LIMIT 10000`
  );
  return popular.rows.map(row => ({
    fitment: [row.level_1, row.level_2, row.level_3].map(slugify)
  }));
}

Isso gera páginas estáticas para suas 10.000 combinações de compatibilidade principais. O resto renderiza sob demanda e fica em cache.

Otimização de Banco de Dados

Para catálogos com mais de 1M registros de compatibilidade:

  • Particione a tabela fitment por categoria de nível superior (intervalo de ano para automotivo)
  • Visualizações materializadas para consultas de referência cruzada populares
  • Índices compostos que correspondem aos seus padrões de consulta exatos
  • Pool de conexões com PgBouncer -- lookups de compatibilidade criam muitas consultas de curta duração
-- Visualização materializada para contagens rápidas de peças por equipamento
CREATE MATERIALIZED VIEW equipment_part_counts AS
SELECT 
  equipment_id,
  COUNT(DISTINCT part_id) as part_count,
  array_agg(DISTINCT p.category) as available_categories
FROM fitment f
JOIN parts p ON p.id = f.part_id
GROUP BY equipment_id;

-- Atualize nightly ou na importação de dados
REFRESH MATERIALIZED VIEW CONCURRENTLY equipment_part_counts;

Tratando Casos Extremos e Qualidade de Dados

É aqui que vive o trabalho real. Construir a UI de busca leva algumas semanas. Limpar e manter dados de compatibilidade é um trabalho infinito.

Problemas Comuns de Qualidade de Dados

  • Entradas de equipamento duplicadas com nomes ligeiramente diferentes ("Chevy" vs "Chevrolet")
  • Mapeamentos de compatibilidade ausentes que causam peças não aparecerem onde deveriam
  • Compatibilidade incorreta que causa devoluções e clientes furiosos
  • Lacunas de intervalo de ano onde uma peça se encaixa em 2018-2020 e 2022+ mas alguém esqueceu de 2021
  • Dados de referência cruzada que estão desatualizados dos fornecedores

Pipeline de Ingestão de Dados

Construa um pipeline de validação para dados de compatibilidade recebidos:

async function validateFitmentImport(records: FitmentRecord[]) {
  const errors: ValidationError[] = [];
  
  for (const record of records) {
    // Verifique se o equipamento existe
    const equipment = await findEquipment(record.equipmentRef);
    if (!equipment) {
      errors.push({ type: 'UNKNOWN_EQUIPMENT', record });
      continue;
    }
    
    // Verifique duplicatas
    const existing = await findFitment(record.partId, equipment.id);
    if (existing) {
      errors.push({ type: 'DUPLICATE', record, existing });
      continue;
    }
    
    // Validação de referência cruzada
    const similar = await findSimilarParts(record.partId);
    if (similar.length > 0 && !similar.some(s => s.fitsEquipment(equipment.id))) {
      errors.push({ type: 'SUSPICIOUS_FITMENT', record, similar });
    }
  }
  
  return errors;
}

Sinalize registros suspeitos para revisão manual em vez de importar tudo automaticamente. Dados de compatibilidade ruins custam dinheiro real em devoluções e perda de confiança.

Expectativas Reais de Custo e Cronograma

Vamos ser honestos sobre o que isso custa para construir propriamente:

Componente Cronograma Intervalo de Custo (2025)
Modelagem de dados + design de esquema 1-2 semanas $3.000 - $8.000
Migração de dados / pipeline de importação 2-4 semanas $5.000 - $15.000
Camada API com cache 2-3 semanas $5.000 - $12.000
Seletor de compatibilidade frontend + busca 3-4 semanas $8.000 - $20.000
Páginas de destino de SEO (SSR/ISR) 1-2 semanas $3.000 - $8.000
Recurso Garage / equipamento salvo 1 semana $2.000 - $5.000
Testes + validação de dados 2-3 semanas $4.000 - $10.000
MVP Total 10-16 semanas $30.000 - $78.000

Sim, não é barato. Mas considere que uma busca de compatibilidade bem construída aumenta as taxas de conversão em 15-35% para empresas de peças (baseado no que medimos em projetos de clientes). Para um negócio fazendo $500K/ano em vendas de peças, mesmo um aumento de 15% paga a construção em menos de um ano.

Se você quer conversar especificamente para seu negócio de peças, verifique nosso preço ou entre em contato diretamente. Construímos isso o suficiente que geralmente conseguimos dar uma estimativa sólida após uma conversa.

Alternativas Prontas para Usar

Antes de construir personalizado, considere estas:

  • Shopify + aplicativos Part Finder -- Decente para catálogos pequenos (< 10K SKUs). Quebra rapidamente com hierarquias complexas.
  • BigCommerce + integração ACES -- Melhor para automotivo especificamente. Limitado para outras indústrias.
  • WooCommerce + plugin WPF -- Barato mas frágil. Desempenho degrada mal acima de 50K registros de compatibilidade.
  • Build headless personalizado -- O que estamos descrevendo neste artigo. Melhor para negócios de peças sérios.

As opções prontas funcionam se seu catálogo é pequeno e você está em automotivo. Para tudo mais, personalizado é geralmente a chamada correta.

FAQ

Qual formato de dados devo usar para dados de compatibilidade?

Para automotivo, ACES XML é o padrão da indústria -- a maioria dos fornecedores fornece dados neste formato, e ferramentas como WHI Solutions e ASAP Network podem ajudá-lo a acessar. Para indústrias não-automotivas, você provavelmente precisará criar seu próprio esquema. Comece com um pipeline de importação CSV e construa validação em cima. O formato importa menos que a consistência e precisão dos dados.

Quantos níveis minha hierarquia de compatibilidade deveria ter?

A maioria das buscas de compatibilidade funciona bem com 3-5 níveis. Automotivo tipicamente usa 4-5 (Ano, Marca, Modelo, Submodelo, Motor). Marinha e powersports geralmente precisam de 4. HVAC e peças de eletrodomésticos frequentemente funcionam com 3. A regra de ouro: use níveis suficientes para identificar uniquamente o equipamento, mas não mais. Cada nível adicional adiciona fricção à experiência do usuário.

Posso usar Elasticsearch em vez de PostgreSQL para dados de compatibilidade?

Você pode, mas não recomendo como sua loja primária de compatibilidade. Elasticsearch é ótimo para busca de texto completo e funciona bem como camada de busca secundária, mas bancos de dados relacionais lidam com as consultas de cascata hierárquica mais naturalmente e com melhor integridade de dados. Use PostgreSQL como a fonte de verdade e adicione Elasticsearch ou Meilisearch para o componente de busca de texto em cima.

Como faço para lidar com peças que se encaixam em vários tipos de equipamento?

Isso é exatamente o que a tabela de junção de compatibilidade faz. Uma única peça pode ter centenas de registros de compatibilidade ligando-a a diferentes equipamentos. A chave é fazer o lookup reverso rápido -- quando alguém visualiza uma peça, você precisa mostrar rapidamente tudo em que se encaixa. Visualizações materializadas e índices apropriados tornam isso performático mesmo com milhões de registros de compatibilidade.

E quanto a decodificação de VIN para compatibilidade automotiva?

Decodificação de VIN é um ótimo recurso complementar. Serviços como DataOne Software, API gratuita do NHTSA e decodificador de VIN do Carvana podem extrair ano, marca, modelo e motor de um VIN. Isso deixa clientes pular a cascata de dropdown inteiramente. A API do NHTSA é gratuita mas com limite de taxa e às vezes incompleta. APIs comerciais de DataOne ou Chrome Data são mais confiáveis a $0,02-0,10 por lookup.

Como faço para obter dados de compatibilidade para indústrias não-automotivas?

Esta é a parte difícil. Ao contrário de automotivo, a maioria das outras indústrias não têm bancos de dados de compatibilidade padronizados. Você tipicamente precisará: (1) construir a partir de PDFs de referência cruzada do fabricante, (2) raspar dados de compatibilidade de concorrentes (legalmente, verifique seus ToS), (3) trabalhar diretamente com fornecedores que fornecem planilhas de compatibilidade, ou (4) construir manualmente a partir de catálogos e folhas de especificações. Orçamento tempo significativo para aquisição de dados -- é geralmente a fase mais longa do projeto.

Devo construir busca de compatibilidade em minha plataforma existente ou começar do zero?

Depende da sua plataforma atual. Se você está em Shopify ou WooCommerce e tem menos de 20K SKUs, tente um plugin primeiro. Se você está em um sistema legado ou tem um catálogo grande, uma reformulação headless com compatibilidade integrada desde o início vai servir você muito melhor a longo prazo. Parafusar compatibilidade em um sistema existente que não foi projetado para isso geralmente resulta em desempenho pobre e dores de cabeça de manutenção.

Como faço para lidar com SEO de busca de compatibilidade?

Gere páginas estáticas ou renderizadas no servidor para combinações de compatibilidade populares. Uma URL como /parts/2024/toyota/camry/oil-filters deveria ser uma página real, indexável com tags de título únicas, descrições e dados estruturados. Use marcação Product do schema.org com isAccessoryOrSparePartFor para ajudar mecanismos de busca a entenderem compatibilidade. Link interno entre páginas de compatibilidade relacionadas (mesmo modelo anos diferentes, mesmo ano partes diferentes) constrói autoridade tópica. Vimos páginas otimizadas para compatibilidade superar varejistas grandes para consultas de peças de cauda longa.