Parámetros estándar del feed de productos XML

La mayoría de los artículos sobre feeds XML dan por hecho que usted vende camisetas.

Esa suposición tenía sentido hace una década, cuando un «feed de productos» era un archivo de Google Shopping y nada más. Hoy ya no se sostiene. Un concesionario de coches, un portal de empleo, un grupo hotelero, un portal inmobiliario y una plataforma de apuestas utilizan hoy publicidad basada en feeds, y ninguno de ellos envía size ni gtin. Envían números de bastidor (VIN), códigos IATA, número de dormitorios, tipos de contrato y horas de inicio de los partidos.

La mecánica subyacente es idéntica. Los parámetros no.

Esta guía cubre ambas cosas: las reglas estructurales que se aplican a cualquier feed XML, sea cual sea el sector, y los conjuntos de atributos específicos de cada uno de los principales tipos de feed: retail, inventario local, vehículos, viajes, inmuebles, empleo e inventario con fecha límite, como partidos, eventos y sesiones de cine. Con XML funcional para cada uno.

1. Qué es realmente un feed XML

Un feed XML es un archivo estructurado que describe un inventario de forma que las máquinas puedan procesarlo sin que una persona lo interprete. Una plataforma descarga el archivo según una programación, lo analiza y crea fichas, anuncios o resultados de búsqueda a partir de lo que encuentra.

El formato importa menos de lo que la mayoría cree. Lo que importa es el contrato: cada destino publica una especificación que indica qué campos exige, qué valores son válidos y cómo se comportará cuando sean incorrectos. El feed es su parte de ese contrato.

De ello se derivan dos consecuencias, y son la razón por la que los feeds son más difíciles de lo que parecen:

El contrato es distinto para cada destino. La especificación de productos de Google, la especificación de catálogo de Meta y el XML de empleo de Indeed apenas comparten nombres de campos. Un mismo catálogo de origen tiene que transformarse de forma distinta para cada uno.

Los incumplimientos suelen fallar en silencio. Un campo mal formado rara vez rompe el archivo. Rechaza un artículo, o rebaja una ficha, o elimina un atributo del anuncio, y nada en el panel de su campaña lo indica.

2. La anatomía del archivo

La mayoría de los feeds XML publicitarios utilizan RSS 2.0 con una extensión de espacio de nombres. La estructura siempre tiene las mismas tres capas:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:g="http://base.google.com/ns/1.0">
  <channel>
    <title>Example Store — Product Feed</title>
    <link>https://example.com</link>
    <description>Full catalogue, updated hourly</description>

    <item>
      <!-- one inventory item -->
    </item>

  </channel>
</rss>

• La declaración XML establece la codificación. En la práctica debe ser UTF-8; cualquier otra cosa corrompe los caracteres en los catálogos que no están en inglés y es, con diferencia, la causa más habitual de títulos de producto deformados en turco, alemán y checo.
• La declaración del espacio de nombres (xmlns:g="...") es lo que hace válido <g:price>. Si la omite, todos los elementos con prefijo se ignoran en silencio: el feed se analiza sin errores y no se importa casi nada.
• <channel> contiene los metadatos del feed.
• <item> es una unidad de inventario. Qué significa «una unidad» es una decisión, no algo dado: un SKU, una variante, un vehículo, una oferta de empleo, un hotel, un partido.

No todos los sectores utilizan esta forma. Los feeds de empleo utilizan <source><job>, y algunos marketplaces definen sus propios elementos raíz por completo. La lógica de tres capas (documento, contenedor, artículo repetido) se mantiene en cualquier caso.

3. El núcleo universal

Siete parámetros aparecen, con distintos nombres, prácticamente en todas las especificaciones de feed que se han escrito. Si los entiende, puede leer cualquier especificación.

Tres reglas sobre el ID que se aplican de forma universal y que causan más daño que cualquier otro campo:

1. Debe ser estable. Si su ID se regenera en cada exportación (derivado del orden de las filas, de una marca de tiempo o de un hash de contenido que cambia), cada sincronización destruye el historial de rendimiento acumulado del artículo, que vuelve a empezar desde cero.
2. Debe ser único. Los ID duplicados hacen que las filas posteriores se descarten sin ningún mensaje de error. Los artículos simplemente desaparecen.
3. Debe coincidir con lo que envía su píxel o su etiqueta. La asociación de catálogos de Meta, el remarketing dinámico de Google y cualquier producto de retargeting dependen de que el ID del feed y el ID del evento del sitio sean la misma cadena. Es el motivo más habitual por el que el retargeting dinámico «no funciona».

4. Parámetros de retail / comercio electrónico

Es la especificación mejor documentada y la base de la que toman elementos la mayoría de los demás sectores.

Obligatorios

Identificadores

brand, gtin, mpn e identifier_exists. El GTIN es el campo que determina si su producto se asocia al grafo de conocimiento de productos de Google y, por tanto, si aparece siquiera en las superficies de comparación y de compras con IA. En la práctica no es opcional, diga lo que diga la especificación.

Variantes

item_group_id, item_group_title, color, size, size_type, size_system, material, pattern, gender, age_group.

Las variantes merecen un tema aparte; en resumen, item_group_id debe ser idéntico en todo el grupo y derivarse de datos de origen estables, y gender y age_group son constantes dentro del grupo, mientras que color y size no lo son.

Categorización

google_product_category (la taxonomía de Google, ID o ruta completa), product_type (su propia taxonomía: es el campo que hace posible la estructura de las campañas, y es de formato libre, así que utilícelo).

Comercial

sale_price, sale_price_effective_date, unit_pricing_measure, unit_pricing_base_measure, installment, subscription_cost, loyalty_program.

Logística

shipping, shipping_weight, shipping_length / _width / _height, shipping_label, transit_time_label, min_handling_time, max_handling_time, tax.

Control de campañas

excluded_destination, included_destination, ads_redirect, de custom_label_0 a custom_label_4.

Las cinco etiquetas personalizadas son los campos más infrautilizados de toda la especificación. No significan nada para Google: existen únicamente para que usted pueda segmentar. Tramos de margen, profundidad de stock, estacionalidad, antigüedad del producto, nivel de rendimiento en GA4. Si la estructura de su campaña no puede expresar una regla de negocio, normalmente es por esto.

Multimedia

additional_image_link, lifestyle_image_link, virtual_model_link, video_link.

Un artículo de retail mínimo pero completo

<item>
  <g:id>KRC-4210-BLK</g:id>
  <g:title>Karaca Fine Pearl 6-Person Dinner Set — Black</g:title>
  <g:description>26-piece porcelain dinner set for six. Dishwasher and microwave safe.</g:description>
  <g:link>https://example.com/urun/fine-pearl-6-kisilik</g:link>
  <g:image_link>https://cdn.example.com/krc-4210-blk-01.jpg</g:image_link>
  <g:additional_image_link>https://cdn.example.com/krc-4210-blk-02.jpg</g:additional_image_link>
  <g:video_link>https://cdn.example.com/video/krc-4210.mp4</g:video_link>
  <g:availability>in_stock</g:availability>
  <g:price>4299.00 TRY</g:price>
  <g:sale_price>3499.00 TRY</g:sale_price>
  <g:sale_price_effective_date>2026-11-24T00:00+0300/2026-12-01T23:59+0300</g:sale_price_effective_date>
  <g:brand>Karaca</g:brand>
  <g:gtin>8680150042109</g:gtin>
  <g:condition>new</g:condition>
  <g:google_product_category>672</g:google_product_category>
  <g:product_type>Home &amp; Kitchen &gt; Dinnerware &gt; Dinner Sets</g:product_type>
  <g:custom_label_0>high-margin</g:custom_label_0>
  <g:custom_label_1>bf-2026</g:custom_label_1>
</item>

Fíjese en & y > en product_type. Los caracteres & sin escapar en las URL y en las rutas de categoría son la causa más frecuente de archivos XML que no se pueden analizar en absoluto.

5. Qué ha cambiado en 2026

Hay tres cambios en la especificación de datos de producto de Google sobre los que merece la pena actuar ya, y no al llegar la fecha límite.

La resolución mínima de imagen es ahora de 500x500 px para image_link y additional_image_link, en todas las categorías y métodos de marketing. Las advertencias empezaron a aparecer en Merchant Center en abril de 2026; la aplicación obligatoria comienza el 31 de enero de 2027. Google puede ampliar automáticamente algunas imágenes más pequeñas, pero considerarlo una solución es un error: las imágenes ampliadas se notan, y la calidad de la imagen es una variable del porcentaje de clics.

video_link ya está activo y se muestra. Los vídeos enviados mediante este atributo pueden mostrarse desde el 30 de junio de 2026, con validación de políticas y de calidad. Los errores bloquean el vídeo, pero no la oferta, lo que significa que es un campo de bajo riesgo que conviene rellenar. La mayoría de los catálogos no tienen vídeo de producto para la mayoría de sus SKU, y precisamente por eso generarlos a gran escala a partir de los datos del feed es hoy una brecha competitiva y no un simple extra.

Se han ampliado los controles de envío a nivel de producto. handling_cutoff_time establece una hora límite diaria de procesamiento de pedidos, y minimum_order_value especifica el gasto mínimo para la entrega. El atributo shipping también ha incorporado los subatributos loyalty_program_label y loyalty_tier_label para las ventajas de entrega vinculadas a programas de fidelización.

La tendencia es coherente: Google sigue trasladando al nivel del artículo detalles que antes se configuraban a nivel de cuenta. Todo lo que se expresa por artículo es algo que una capa de feed puede automatizar y un proceso manual no.

6. El mapa de sectores

El retail es una fila de esta tabla, no toda la tabla.

Dos reglas estructurales que conviene interiorizar antes de crear nada:

Un catálogo de Meta contiene exactamente un tipo de inventario. No se pueden mezclar hoteles y productos. Si vende ambos, necesita dos catálogos.

Google separa los sectores a nivel de fuente de datos. Una fuente de datos de vehículos debe dirigirse únicamente a los anuncios de vehículos. Enviar vehículos a una fuente de datos de Shopping genera rechazos, no fichas, y las fuentes de vehículos no deben contener recambios ni accesorios, que corresponden a un feed de productos normal.

7. Feeds de vehículos

La automoción es el sector en el que «usar la especificación de retail sin más» falla de forma más evidente. Un coche es un objeto físico único con un identificador legal, no un SKU con profundidad de stock.

Los atributos de vehículos de Google se suman al núcleo común:

<item>
  <g:id>STK-88214</g:id>
  <g:title>2023 Volkswagen Passat 1.5 TSI Business DSG</g:title>
  <g:description>Single owner, full service history, no accident record.</g:description>
  <g:link>https://example.com/ilan/88214</g:link>
  <g:image_link>https://cdn.example.com/88214-01.jpg</g:image_link>
  <g:price>1450000.00 TRY</g:price>
  <g:condition>used</g:condition>
  <g:brand>Volkswagen</g:brand>
  <g:model>Passat</g:model>
  <g:trim>1.5 TSI Business DSG</g:trim>
  <g:year>2023</g:year>
  <g:vin>WVWZZZ3CZPE000000</g:vin>
  <g:mileage>
    <g:value>42500</g:value>
    <g:unit>km</g:unit>
  </g:mileage>
  <g:body_style>sedan</g:body_style>
  <g:color>Grey</g:color>
  <g:vehicle_fulfillment>
    <g:option>in_store</g:option>
    <g:store_code>IST-01</g:store_code>
  </g:vehicle_fulfillment>
</item>

Qué hace que los feeds de vehículos sean operativamente diferentes:

• El inventario es de una sola unidad. Cada artículo es una unidad única. Cuando se vende, debe salir del feed de inmediato, no en la sincronización de mañana. Las fichas de vehículos desactualizadas desperdician clics de CPC elevado en coches que ya no existen y perjudican la calidad de la cuenta.
• La frecuencia de actualización lo es todo. Los ciclos de actualización de cuatro horas son la práctica habitual en automoción, no una optimización.
• Se exige coherencia con la página de destino. El precio y el kilometraje del feed deben coincidir exactamente con la página de detalle del vehículo. Un cambio de precios en todo el concesionario que actualiza el sitio pero no el feed provoca una oleada de rechazos en cuestión de horas.
• Los anuncios de inventario de automoción de Meta utilizan un vocabulario de campos distinto (state_of_vehicle, exterior_color, transmission, drivetrain, dealer_id), por lo que los mismos datos de origen necesitan una transformación diferente para cada canal.

8. Feeds de viajes

Los viajes se dividen en tres tipos de catálogo distintos, y el error es tratarlos como uno solo.

Hoteles

El feed de establecimientos es relativamente estático: nombre, descripción, dirección, coordenadas, categoría en estrellas, imágenes y un precio de partida. Lo que cambia es la disponibilidad y la tarifa, por lo que las configuraciones hoteleras suelen combinar un feed de establecimientos estático con feeds dinámicos de tipos de habitación y precios.

Parámetros básicos: hotel_id, name, description, brand, url, image, latitude, longitude, address (con city, region, country, postal_code), base_price, currency, star_rating, neighborhood, phone, guest_ratings.

<item>
  <g:hotel_id>HTL-BDR-114</g:hotel_id>
  <g:name>Blue Bay Resort Bodrum</g:name>
  <g:description>Seafront resort with private beach, three restaurants and a spa.</g:description>
  <g:url>https://example.com/otel/blue-bay-bodrum</g:url>
  <g:image>https://cdn.example.com/htl-114-01.jpg</g:image>
  <g:latitude>37.0344</g:latitude>
  <g:longitude>27.4305</g:longitude>
  <g:address>Yalıkavak Mah. Sahil Cad. 12, Bodrum, Muğla, TR, 48990</g:address>
  <g:base_price>4200.00 TRY</g:base_price>
  <g:star_rating>5</g:star_rating>
  <g:neighborhood>Yalıkavak</g:neighborhood>
</item>

Vuelos

El artículo es una ruta, no un asiento. La identidad es el par origen–destino: origin_airport y destination_airport como códigos IATA, más price, url, image y description. Los precios suelen ser precios «desde» y cambian constantemente, por lo que la frecuencia de actualización es la limitación decisiva.

Destinos

El artículo es un lugar al que usted vende viajes: destination_id, name, address, neighborhood, types, price, url, image. Útil para la prospección en la parte alta del embudo, cuando el viajero tiene intención pero no un establecimiento concreto en mente.

El problema recurrente de los viajes es que el precio y la disponibilidad se calculan, no se almacenan. El «precio» de un hotel depende de las fechas, la ocupación y la duración de la estancia; el de un vuelo, del momento en que se consulta. Los feeds quieren un único número. Elegir cuál (el más bajo disponible en los próximos 30 días, el más bajo para el próximo fin de semana, la media) es una decisión comercial que determina silenciosamente el rendimiento de sus anuncios, y merece la pena tomarla de forma deliberada en lugar de quedarse con lo que haya producido la exportación por defecto.

9. Feeds inmobiliarios

Estructuralmente similares a los de vehículos: activos físicos únicos, inventario de una sola unidad, alto valor por clic y una ficha que debe desaparecer en el momento en que el inmueble se vende o se alquila.

Parámetros básicos: home_listing_id, name, description, address, latitude, longitude, url, image, price, currency, property_type (piso, casa, terreno, local comercial), listing_type (venta, alquiler, obra nueva), num_beds, num_baths, area_size, area_unit, year_built, availability, agent_name, agent_phone.

<item>
  <g:home_listing_id>EMK-2291</g:home_listing_id>
  <g:name>3+1 Apartment with Sea View — Kadıköy</g:name>
  <g:description>Renovated 3+1 apartment, 4th floor, elevator, closed parking.</g:description>
  <g:address>Caferağa Mah., Kadıköy, İstanbul, TR</g:address>
  <g:latitude>40.9862</g:latitude>
  <g:longitude>29.0299</g:longitude>
  <g:url>https://example.com/ilan/2291</g:url>
  <g:image>https://cdn.example.com/emk-2291-01.jpg</g:image>
  <g:price>12500000.00 TRY</g:price>
  <g:property_type>apartment</g:property_type>
  <g:listing_type>for_sale</g:listing_type>
  <g:num_beds>3</g:num_beds>
  <g:num_baths>2</g:num_baths>
  <g:area_size>135</g:area_size>
  <g:area_unit>sq_m</g:area_unit>
  <g:availability>available</g:availability>
</item>

Algo que no es un problema del feed, pero que detendrá su campaña: la vivienda es una categoría publicitaria restringida en Meta. Las campañas que promocionan anuncios de viviendas deben declararse en la categoría especial de anuncios de vivienda, que restringe las opciones de segmentación. El catálogo puede ser perfecto y la campaña fallar igualmente si no se configura esto.

10. Feeds de empleo

El sector del empleo utiliza una estructura de documento totalmente distinta (<source> y <job> en lugar de <rss> e <item>), y vale la pena verla, porque demuestra que «feed XML» es un patrón y no un esquema único.

<?xml version="1.0" encoding="UTF-8"?>
<source>
  <publisher>Example Company</publisher>
  <publisherurl>https://example.com</publisherurl>
  <lastBuildDate>Wed, 12 Aug 2026 09:00:00 GMT</lastBuildDate>

  <job>
    <title><![CDATA[Senior Backend Engineer]]></title>
    <date><![CDATA[Mon, 10 Aug 2026 08:00:00 GMT]]></date>
    <referencenumber><![CDATA[ENG-4471]]></referencenumber>
    <url><![CDATA[https://example.com/careers/eng-4471]]></url>
    <company><![CDATA[Example Company]]></company>
    <city><![CDATA[İstanbul]]></city>
    <state><![CDATA[İstanbul]]></state>
    <country><![CDATA[TR]]></country>
    <postalcode><![CDATA[34394]]></postalcode>
    <description><![CDATA[<p>We are hiring a senior backend engineer to work on our data pipeline...</p>]]></description>
    <salary><![CDATA[120000 - 160000 TRY monthly]]></salary>
    <jobtype><![CDATA[fulltime]]></jobtype>
    <category><![CDATA[Engineering]]></category>
    <experience><![CDATA[5+ years]]></experience>
  </job>

</source>

Cuatro reglas específicas de los feeds de empleo:

1. CDATA es la norma, no la excepción. Las descripciones de los puestos contienen HTML, signos «&» y apóstrofos. Envolver cada campo en <![CDATA[...]]> evita toda una categoría de errores de análisis.
2. La ubicación necesita al menos ciudad, provincia o estado y país. Si los omite, la oferta pierde por defecto visibilidad orgánica en los principales agregadores.
3. Los puestos cubiertos deben eliminarse, no marcarse como cerrados. No existe un equivalente de availability. La presencia en el feed es la señal de disponibilidad, y los agregadores penalizan los feeds que contienen ofertas obsoletas.
4. Un idioma, una entrada de empleo. Una oferta publicada en dos idiomas necesita dos entradas independientes con números de referencia distintos.

Al margen del feed, los datos estructurados JobPosting en JSON-LD en la página de empleo son lo que permite que un puesto aparezca en las fichas de empleo de los resultados de búsqueda. Ambos son complementarios: el feed se encarga de la distribución a los agregadores y los datos estructurados, de la búsqueda orgánica. La mayoría de los equipos de selección hacen uno y no el otro.

11. Inventario con fecha límite

La categoría de feed más interesante no tiene especificación oficial, porque las plataformas nunca la previeron: un inventario cuyo atributo definitorio es el cuándo, no el qué.

Partidos de fútbol. Conciertos. Sesiones de cine. Salidas de vuelos. Lotes de subastas. Franjas de reserva en restaurantes. Ventanas de entrega.

Todos ellos tienen las propiedades de un producto (una identidad, un precio, una imagen, una página de destino) y, además, una para la que la especificación de retail no tiene campo: una vida útil que se mide en horas. Un partido que ya ha empezado no está «agotado»: carece de sentido.

El enfoque que funciona es modelarlos como productos de catálogo estándar y codificar la dimensión temporal en campos que la plataforma ya entiende:

<item>
  <g:id>MTC-2026-08-16-GS-FB</g:id>
  <g:title>Galatasaray - Fenerbahçe | Super League, Week 2</g:title>
  <g:description>Saturday 16 August, 19:00. Live odds and in-play betting.</g:description>
  <g:link>https://example.com/mac/2026-08-16-gs-fb</g:link>
  <g:image_link>https://cdn.example.com/creatives/mtc-2026-08-16-gs-fb.jpg</g:image_link>
  <g:availability>in_stock</g:availability>
  <g:price>1.00 TRY</g:price>
  <g:product_type>Football &gt; Super League &gt; Week 2</g:product_type>
  <g:custom_label_0>2026-08-16</g:custom_label_0>
  <g:custom_label_1>derby</g:custom_label_1>
  <g:custom_label_2>ms1-2.10</g:custom_label_2>
  <g:expiration_date>2026-08-16T19:00+0300</g:expiration_date>
</item>

Tres cosas hacen que esto funcione:

• expiration_date o una regla de eliminación equivalente, para que el artículo salga del catálogo al empezar el partido y no en la siguiente sincronización programada.
• Etiquetas personalizadas que transmiten la dimensión temporal, para que las campañas puedan estructurarse en torno a «este fin de semana», «derbi» o «cuotas superiores a 2,0».
• Una creatividad por artículo. Aquí es donde este enfoque suele atascarse. Un calendario de varios cientos de partidos por semana necesita varios cientos de imágenes, cada una con los equipos, la fecha, la hora y las cuotas actuales. Ningún equipo de diseño produce eso. Generar la creatividad a partir de la fila del feed es el único método que sigue el ritmo, y es exactamente como Bilyoner publicó anuncios de catálogo por primera vez y aumentó su ROAS un 49 %.

Si su inventario tiene una hora de inicio, su lugar está en un catálogo. El obstáculo casi siempre es el formato, no el concepto.

12. Feeds de inventario local

El inventario local se sitúa entre el retail y los sectores específicos: los mismos productos, descritos por ubicación física.

Parámetros: id, store_code, quantity, price, sale_price, sale_price_effective_date, availability, pickup_method (comprar, reservar, envío a tienda, no admitido), pickup_sla (mismo día, día siguiente, varios días).

Lo importante desde el punto de vista estructural es que el feed local es un complemento, no un sustituto. Hace referencia a los artículos del feed de productos principal mediante su id y añade datos por tienda. Un artículo, muchas tiendas, muchas filas.

Una nota de 2026 que conviene destacar: las versiones online y en tienda de un mismo producto con precios o disponibilidad diferentes necesitan ahora ID de producto separados en lugar de agruparse en uno solo. A los feeds que los habían consolidado se les está pidiendo que los separen.

13. Reglas de formato

Se aplican a todos los tipos de feed de este artículo y, entre todas, explican la gran mayoría de los feeds que fallan por completo.

Codificación. UTF-8, siempre, declarada en la declaración XML y servida con una cabecera Content-Type coincidente. Las discrepancias entre la codificación declarada y la real corrompen todos los caracteres no ASCII.

Escape de caracteres. Hay cinco caracteres que deben escaparse en el contenido XML: & → &, < → <, > → >, " → ", ' → '. Los signos «&» sin escapar en las URL de seguimiento son la causa número uno de los feeds que no se pueden analizar. La alternativa es CDATA, que es la práctica habitual en los feeds de empleo y resulta útil en cualquier lugar donde las descripciones contengan marcado.

Fechas. ISO 8601 con un desfase horario explícito. 2026-08-16T19:00+0300, no 16.08.2026 19:00. Los feeds que sirven a varios mercados desde una fuente sin zona horaria generan artículos que caducan horas antes o después de lo debido.

Precios. Valor y moneda ISO 4217, con punto decimal y no coma, sin separador de miles. 4299.00 TRY. Y el precio del feed debe coincidir con el de la página de destino: la mayoría de las plataformas lo comprueban mediante rastreo.

Los valores enumerados distinguen mayúsculas, minúsculas y formato, y difieren según la plataforma. Google espera in_stock; Meta espera in stock. Esa única diferencia ha roto más importaciones de catálogo que cualquier otra. Nunca dé por hecho que un valor enumerado sirve para distintos destinos.

Entrega del archivo. Compresión gzip para los archivos grandes, una URL HTTPS estable, ninguna barrera de autenticación salvo que la plataforma lo admita expresamente y un servidor que responda dentro del tiempo de espera de la plataforma. Una URL de feed protegida por la protección antibots de Cloudflare es una URL de feed que no se descarga.

La frecuencia de actualización debe seguir la volatilidad de los datos subyacentes, no una convención: cada hora o más a menudo para las cuotas, los precios de los vuelos y el stock de retail de alta rotación; cada pocas horas para vehículos e inmuebles; a diario para los catálogos estables.

14. XML frente a CSV, JSON y API

XML sigue siendo la opción predeterminada para todo lo que tenga anidamiento, por eso los feeds de vehículos, viajes y retail con mucha información de envío suelen ser XML, mientras que los catálogos de moda sencillos suelen ser TSV. Tenga en cuenta también que varios destinos importantes avanzan hacia una ingesta basada principalmente en API, por lo que considerar el archivo como su única vía de integración es un riesgo a medio plazo.

Si sus títulos contienen comas (y los títulos con color y talla casi siempre las contienen), utilice TSV en lugar de CSV. Desaparece toda una categoría de errores de análisis.

15. Lista de comprobación previa al lanzamiento

• [ ] El archivo se valida en un validador XML antes de acercarse a cualquier plataforma
• [ ] UTF-8 declarado y servido correctamente; los caracteres no ASCII se muestran bien
• [ ] Todos los & de todas las URL escapados, o el campo envuelto en CDATA
• [ ] ID únicos, estables entre sincronizaciones y coincidentes con los eventos de su píxel o etiqueta
• [ ] Todos los atributos obligatorios presentes para el destino en cuestión, verificados frente a la especificación de ese destino y no frente a una general
• [ ] Valores enumerados transformados para cada destino, no copiados
• [ ] Los precios coinciden exactamente con las páginas de destino, incluida la moneda y el tratamiento de impuestos
• [ ] Fechas en ISO 8601 con desfase horario
• [ ] Las imágenes cumplen el mínimo de 500x500 y se cargan por HTTPS sin redirecciones
• [ ] Los artículos vendidos, cubiertos, caducados o ya salidos abandonan el feed en el momento adecuado
• [ ] La frecuencia de actualización se ajusta a la velocidad con la que cambian realmente los datos subyacentes
• [ ] La URL del feed es accesible públicamente y no está bloqueada por una protección antibots
• [ ] Existe una regla de supervisión para los cambios inesperados en el número de artículos

16. Preguntas frecuentes

¿Sigue siendo XML el formato adecuado en 2026?
Para todo lo que tenga datos anidados, sí. Para los catálogos planos, TSV es más sencillo y menos frágil. Para los requisitos en tiempo real, una integración por API supera a cualquier archivo. El formato debe seguir a los datos, no a la costumbre.

¿Puedo utilizar un solo feed para todas las plataformas?
Una sola fuente, sí. Un solo archivo, no. Los nombres de los campos, los valores enumerados, los límites de caracteres y los atributos obligatorios difieren según el destino, y las diferencias no son superficiales. La arquitectura viable es un único catálogo de referencia con transformaciones por canal aplicadas en la exportación.

¿Y si mi inventario no son productos?
Entonces necesita la especificación de su sector, no la de retail. Vehículos, hoteles, vuelos, destinos, inmuebles y empleo tienen cada uno la suya. Y si su inventario es algo para lo que ninguna plataforma tiene especificación (partidos, sesiones, franjas, lotes), lo modela como productos y codifica la dimensión que falta en los campos que existen.

¿Con qué frecuencia debe actualizarse el feed?
Con la misma frecuencia con la que cambian de forma significativa los datos subyacentes. Un vehículo que se vendió esta mañana y sigue anunciándose esta tarde está gastando dinero en nada.

¿Necesito GTIN?
En retail, a efectos prácticos, sí. El GTIN es lo que conecta su artículo con el conocimiento de productos de una plataforma, que determina cada vez más si aparece siquiera en las superficies de comparación y en los resultados de compras basados en IA. Para vehículos, inmuebles y empleo, los campos de identidad equivalentes son vin, el ID del anuncio y el número de referencia.

Dónde se complica

Ninguna de las reglas individuales de este artículo es difícil. La dificultad está en que hay varios cientos, difieren según el destino, cambian sin previo aviso y su incumplimiento falla en silencio.

Un mismo catálogo exportado a Google, Meta, TikTok y tres marketplaces supone cumplir simultáneamente seis contratos diferentes a partir de una única fuente de referencia. Hacerlo a mano implica mantener seis archivos y conciliarlos cada vez que cambia el catálogo.

Esa es la capa para la que se ha creado Feedance: reglas de feed para normalizar los atributos en origen, exportaciones por canal que aplican la transformación adecuada para cada uno de más de 200 destinos sin tocar sus datos de origen, Feed Protection para detectar atributos ausentes y cambios inesperados en el número de artículos antes de que lo haga una plataforma, y Creative Suite, que genera una imagen o un vídeo por cada fila del feed en los catálogos en los que la producción manual nunca fue realista.

Da soporte a los sectores distintos del retail como ciudadanos de primera clase y no como algo secundario: inventario de viajes con precios en vivo, catálogos de apuestas con datos de horarios de partidos, y canales de distribución de automoción, inmuebles y empleo.

Si quiere saber en qué situación se encuentra su feed actual antes de cambiar nada, nuestra herramienta gratuita de auditoría de feeds lo puntúa en cuanto a integridad, calidad de los datos y salud técnica, sin coste. O programe una demo de 15 minutos y lo revisaremos juntos.

Última revisión: agosto de 2026. Las especificaciones de las plataformas cambian con frecuencia; verifique los requisitos actuales en la documentación oficial de cada destino antes de implementarlos.