Entidad de conocimiento en Wikidata: cómo un consultor independiente cierra su grafo semántico

Nomen est omen. En la web semántica, sin identificador no hay nombre.

Consultoría Actuarial del Norte, S.L.P. es un despacho de un único socio en Bilbao. Cinco personas contando al fundador. Facturación estable, cartera de mutualidades y aseguradoras medianas, dieciocho años de historial. El fundador aparece como ponente en dos congresos al año y ha firmado un libro técnico sobre Solvencia II con una editorial universitaria. Su web tiene autoridad de dominio razonable y su LinkedIn suma 4.200 seguidores. Todo bien sobre el papel.

Google no lo sabe. Al buscar su nombre exacto no aparece Knowledge Panel a la derecha. Al preguntarle a un LLM por consultores actuariales especializados en Solvencia II en España, el modelo cita a dos boutiques grandes de Madrid y a un despacho catalán, pero no a él. Cuando aparece en un resultado, es un resultado suelto: un PDF de un congreso, un post en el blog de su despacho, un perfil viejo de un directorio profesional. Cada mención es una isla.

El problema no es de autoridad. Es de identidad.

Google y varios LLMs necesitan un identificador único al que colgar todas las menciones dispersas para reconocerlas como referidas a la misma entidad. Ese identificador, para el 90% del ecosistema semántico abierto, es un Q-ID de Wikidata. Sin él, el sistema ve cinco menciones inconexas. Con él, ve un consultor.

Ya aplica.

Wikipedia no es Wikidata, y confundirlas es el primer error

Casi todo el mundo asume que para estar en el Knowledge Graph de Google hace falta un artículo en Wikipedia. Es falso. Wikipedia y Wikidata son dos proyectos hermanos de la Fundación Wikimedia, con reglas distintas y fines distintos.

Wikipedia es una enciclopedia de artículos redactados en lenguaje natural. Su regla dura es la de notabilidad: solo entra en Wikipedia lo que tiene cobertura significativa en fuentes secundarias independientes. Para un consultor individual eso significa, en la práctica, cinco a diez artículos periodísticos de medios generalistas o especializados con foco en su persona. La mayoría de los consultores no cumple ese umbral y nunca lo va a cumplir. Está bien. Wikipedia no es para eso.

Wikidata es una base de datos estructurada de items. Cada item tiene un identificador (Q-ID) y una lista de propiedades con valores. No es una enciclopedia. Es un grafo de conocimiento. Su regla de admisión es mucho más laxa: entra cualquier entidad identificable de forma unívoca y con al menos una referencia externa que la sustente. El umbral típico son dos o tres enlaces a fuentes externas: perfil ORCID, perfil VIAF, ISBN de un libro, entrada en un directorio profesional oficial, referencia en una base de datos académica.

Traducción: un consultor con un libro publicado, un perfil ORCID y dos ponencias registradas en bases académicas puede entrar en Wikidata sin problema. En Wikipedia no. Y para el Knowledge Graph de Google, con Wikidata basta en la mayoría de los casos.

La confusión sale cara. El consultor pierde meses intentando forzar un artículo de Wikipedia que le van a borrar por autopromoción o falta de notabilidad, cuando la vía útil siempre fue la otra puerta.

Wikipedia comprueba notabilidad narrativa. Wikidata comprueba identidad estructurada. Son problemas distintos y se resuelven distinto.

Hay una tercera confusión frecuente: pensar que Wikidata solo importa para figuras públicas. No. Wikidata contiene items de universidades, revistas científicas, edificios, canciones, subespecies de escarabajos y, sí, profesionales técnicos que han publicado bajo un identificador persistente. En diciembre de 2025, Wikidata pasó de 115 millones de items. La barrera para consultores especializados que ya tienen huella pública mínima es baja.

Qué propiedades rellenar como persona y qué propiedades rellenar como empresa

Un consultor independiente casi siempre necesita dos items en Wikidata, no uno. Uno para la persona física y otro para el despacho o marca profesional cuando factura a través de una sociedad. Los dos items se enlazan entre sí y cada uno tiene sus propiedades mínimas.

Persona física

Las propiedades mínimas para que Google trate al item como una persona con identidad estable son estas.

• P31 (instance of). Valor obligatorio: Q5 (ser humano). Sin este triple, el item no se resuelve como persona en ningún sitio.
• P21 (sex or gender). Valor Q6581072 (femenino), Q6581097 (masculino) u otras opciones documentadas. Google lo usa para desambiguación.
• P106 (occupation). Aquí van una o varias ocupaciones. Para un actuario, Q1077636 (actuario). Para un ingeniero de software independiente, Q82594 (ingeniero de software) más Q131524 (consultor). Cuantas más ocupaciones concretas mejor, siempre que sean ciertas.
• P569 (date of birth). Año de nacimiento como mínimo. Fecha completa si es pública. Sin fecha de nacimiento, Wikidata trata al item como incompleto y Google le baja la prioridad para Knowledge Panel.
• P27 (country of citizenship). Valor Q29 (España) en el caso peninsular.
• P19 (place of birth). Ciudad o municipio. Se enlaza a un item Q existente.
• P108 (employer) o P800 (notable work). Al menos uno. Si el consultor factura a través de su propia sociedad, P108 apunta al Q-ID del despacho. P800 se rellena con libros publicados (enlazados por su propio Q-ID) o proyectos notables.
• P1416 (affiliation). Colegio profesional, asociación sectorial, cátedra. Ayuda a fijar el nicho.
• P856 (official website). URL de la web personal o profesional.
• P2002 (Twitter/X username), P2035 (LinkedIn), P2013 (Facebook), P4033 (Mastodon), P11947 (Bluesky). Todos los perfiles públicos activos como propiedades separadas. Cada uno es una fuente externa que ancla la identidad.
• P496 (ORCID iD). Para cualquier consultor con producción académica o técnica registrada. ORCID es el identificador persistente que más peso da al item ante Google.

Sociedad o despacho

Cuando la marca factura, el item de la sociedad va aparte.

• P31. Valor Q4830453 (empresa) o más específico: Q1477538 (sociedad limitada profesional) para una S.L.P., Q188907 (sociedad de responsabilidad limitada) para una S.L. genérica.
• P17 (country). Q29.
• P159 (headquarters location). Ciudad de la sede fiscal.
• P571 (inception). Año de constitución.
• P452 (industry). Sector. Existen items para casi todos: consultoría actuarial (Q11681746), auditoría (Q193465), consultoría de gestión (Q853574), desarrollo de software (Q638608).
• P169 (chief executive officer) o P488 (chairperson). Enlazado al Q-ID de la persona física fundadora. Este triple cierra el bucle: el grafo sabe que la persona X dirige la empresa Y, y que la empresa Y tiene como CEO a la persona X.
• P1128 (employees). Número de empleados si es público. No obligatorio, útil.
• P856 (official website). URL corporativa.
• P1320 (OpenCorporates ID). Identificador en la base OpenCorporates. Cada sociedad española con NIF activo tiene entrada automática. Es la referencia externa más fácil de sumar.

Regla: ningún item se publica sin al menos dos propiedades externas con referencia (P856 no cuenta como externa porque es la propia web). ORCID, VIAF, ISBN, OpenCorporates, DOI, GND, ISNI. Cualquiera de esas basta y dos ya son cómodas. Sin referencias externas, el item sobrevive a la primera semana pero cae en el segundo patrullaje.

El enlace bidireccional: sameAs, JSON-LD y por qué sin él Google no cierra el círculo

Publicar el item en Wikidata no basta. Hay que decirle al resto de la web que ese Q-ID es tu identidad. El vehículo estándar es el atributo sameAs dentro del JSON-LD que la web propia sirve en cada página relevante.

En la home de la web personal o profesional, dentro del <head>, va un bloque como este.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://consultoriaactuarialdelnorte.example/#persona-fundador",
  "name": "Nombre Apellido Apellido",
  "jobTitle": "Actuario colegiado",
  "worksFor": {
    "@type": "Organization",
    "@id": "https://consultoriaactuarialdelnorte.example/#organizacion"
  },
  "url": "https://consultoriaactuarialdelnorte.example/",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q123456789",
    "https://orcid.org/0000-0002-XXXX-XXXX",
    "https://www.linkedin.com/in/nombreapellido/",
    "https://scholar.google.com/citations?user=XXXX",
    "https://dialnet.unirioja.es/servlet/autor?codigo=XXXX"
  ]
}
</script>

Y en paralelo, un segundo bloque para la organización.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "@id": "https://consultoriaactuarialdelnorte.example/#organizacion",
  "name": "Consultoría Actuarial del Norte, S.L.P.",
  "founder": {
    "@type": "Person",
    "@id": "https://consultoriaactuarialdelnorte.example/#persona-fundador"
  },
  "sameAs": [
    "https://www.wikidata.org/wiki/Q987654321",
    "https://opencorporates.com/companies/es/BXXXXXXX",
    "https://www.linkedin.com/company/consultoria-actuarial-del-norte/"
  ]
}
</script>

El sameAs es el puente. Google lee el JSON-LD, sigue los enlaces de sameAs y comprueba que en el otro extremo hay coherencia: el Q-ID de Wikidata contiene una propiedad P856 que apunta a la misma URL. El circuito se cierra. Google ahora sabe que la web, el Q-ID, el LinkedIn y el ORCID hablan de la misma entidad.

Solución: los dos @id de los bloques JSON-LD son URIs internos con fragmento (#persona-fundador, #organizacion). El fragmento no se resuelve como URL navegable, sirve solo como identificador local para que el bloque Person y el bloque Organization se referencien entre sí. Con worksFor y founder usando esos @id internos, el grafo interno de la propia página también queda cerrado.

Sin JSON-LD en la web, el Q-ID de Wikidata queda huérfano. Google no lo asocia a nada y el Knowledge Panel no se genera. Ha pasado con muchos items publicados durante años que nunca dispararon panel porque su propietario nunca puso el sameAs en el sitio.

Wikidata es la mitad del contrato. El JSON-LD con sameAs en tu propia web es la otra mitad. Sin las dos firmas, el contrato no tiene efecto.

Extra que pocos rellenan y que ayuda: el JSON-LD de cada artículo de blog debe incluir un bloque author que referencie al @id de la persona, no un string suelto con el nombre. Así cada artículo publicado en la web añade un triple más al grafo semántico interno.

Errores que hacen que el patrullaje de Wikidata te haga revert en 48 horas

Wikidata tiene una comunidad de patrulleros voluntarios que revierte cambios sospechosos. Un item mal construido dura poco. Cinco errores frecuentes que provocan revert casi automático.

Error 1: Autopromoción evidente. Síntoma: el item se crea desde una cuenta anónima recién registrada, sin editar antes nada más, y con lenguaje comercial en las descripciones ("consultor líder", "referente en el sector", "experto reconocido"). Solución: la descripción en español debe ser una frase corta y neutra del tipo "actuario español" o "consultor español especializado en Solvencia II", sin adjetivos valorativos. Los adjetivos valorativos son bandera roja instantánea.

Error 2: Cero referencias externas. Síntoma: el item se guarda con propiedades pero sin ninguna referencia (icono de libro) al lado de los valores. El patrullero lo marca en la siguiente ronda y lo borra por falta de sustentación. Solución: cada propiedad que se pueda debe llevar al menos una referencia mediante la propiedad stated in (P248) o reference URL (P854). Como mínimo P106 (occupation), P108 (employer) y P800 (notable work) deben ir referenciadas.

Error 3: Enlaces circulares sin fuente externa. Síntoma: la única referencia del item es la web propia del consultor. Solución: aunque la web propia se admite en P856, no vale como fuente independiente. Hay que sumar al menos una fuente que no controle el propio sujeto: OpenCorporates, ORCID, Google Scholar, Dialnet, ISBN, catálogo de la Biblioteca Nacional, VIAF. Sin al menos una fuente externa que no sea la web del sujeto, el item cae.

Error 4: Nombre en mayúsculas o con títulos honoríficos. Síntoma: se guarda "Nombre APELLIDO APELLIDO" o "Dr. Nombre Apellido, MBA". Solución: el label del item va sin honoríficos, sin postnominales y en mayúsculas y minúsculas normales. Los grados académicos van como propiedades P512 (academic degree), no en el nombre.

Error 5: Descripciones idénticas en varios idiomas. Síntoma: el mismo texto en español pegado en el campo de descripción inglesa, alemana y francesa. Solución: al menos las descripciones en español e inglés deben estar en cada idioma. El resto se pueden dejar en blanco. Descripción vacía es mejor que descripción en el idioma equivocado.

Un item creado con estos cinco cuidados sobrevive el patrullaje inicial. Lo normal es que en las primeras dos semanas otro editor pase, corrija algo menor y añada una o dos propiedades que se te habían olvidado. Eso es sano. Significa que el item se ha integrado en el grafo y otros editores lo están tratando como parte del cuerpo.

Timeline realista desde la publicación hasta que aparece el Knowledge Panel

Hay una expectativa recurrente: publicar el item un martes y ver el Knowledge Panel el jueves. No pasa. Google tarda semanas o meses en cerrar el circuito y disparar el panel, y hay pasos intermedios que conviene medir.

Día 0. Publicación del item en Wikidata. El item existe con Q-ID asignado. Todavía no está indexado por Google como parte del Knowledge Graph.

Días 1 a 3. Indexación en el mirror de Wikidata. La URL https://www.wikidata.org/wiki/QXXXXXXXX se indexa en Google como cualquier otra URL. Ya se puede encontrar por búsqueda directa del Q-ID. Todavía no hay panel.

Días 3 a 7. Publicación del JSON-LD con sameAs en la web propia. Este paso es del consultor, no de Google. Hay que meter los dos bloques JSON-LD en el <head> de la home y validar con la Rich Results Test de Google que no hay errores. Sin este paso, todo lo siguiente no pasa.

Semanas 2 a 6. Rastreo del sameAs por Googlebot. Googlebot pasa por la home, lee el JSON-LD, sigue el sameAs que apunta al Q-ID, verifica la ida y la vuelta. Este cruce ocurre en cada rastreo, no una vez. Cuantas más señales convergentes, mayor confianza asignada.

Semanas 6 a 12. Aparición de resultado enriquecido en SERP. El primer indicio visible en la SERP suele ser el rich result de tipo Person u Organization en la búsqueda del nombre exacto: aparece la foto de perfil junto al primer resultado, o un pequeño snippet enriquecido. No es todavía Knowledge Panel completo, pero es el aviso de que Google ha aceptado la asociación.

Meses 3 a 6. Knowledge Panel embrionario. Aparece un panel a la derecha con la foto, la descripción corta de Wikidata y los enlaces sociales del sameAs. Suele salir primero para búsquedas muy específicas (nombre completo más ciudad, nombre completo más profesión) y luego se generaliza al nombre a secas.

Meses 6 a 12. Knowledge Panel completo y citación en LLMs. El panel se estabiliza con toda la información básica. En paralelo, los LLMs que usan grafos de entidades derivados de Wikidata (varios modelos generalistas lo hacen) empiezan a citar al consultor cuando se les pregunta por su nicho. La curva de menciones en respuestas de IA se acelera claramente a partir del mes seis.

Esa es la horquilla realista para un caso limpio con producción académica mínima. Para un consultor sin producción académica pero con presencia mediática, la curva es más lenta: puede llegar al año largo antes del panel.

Traducción: publicar en Wikidata es una jugada de horizonte anual. No es una campaña. Es una inversión de identidad que rinde durante años una vez que ha cerrado.

Mantenimiento periódico del item: qué revisar cada trimestre

Un item de Wikidata no es estático. Cambia el rol, cambia la afiliación, sale un libro nuevo, se cierra una sociedad. La disciplina es revisarlo cada trimestre con checklist corta.

• Occupation (P106). Verificar que las ocupaciones siguen siendo ciertas. Si el consultor deja de dar formación y solo consulta, quitar la ocupación de formador. Si empieza a arbitrar en tribunales periciales, añadir Q212238 (perito).
• Notable work (P800). Añadir libros nuevos, ponencias en congresos científicos referenciados y proyectos abiertos publicados bajo el propio nombre. Cada obra nueva es una propiedad más y una referencia más.
• Employer (P108) y position held (P39). Si cambia el despacho, la fecha de fin va en el valor antiguo (qualifier P582, end date) y la fecha de inicio va en el nuevo valor (P580, start date). Nunca borrar valores antiguos: se marcan como acabados. Wikidata prefiere historia acumulada a historia sobreescrita.
• Cuentas sociales (P2002, P2035, etc.). Si se cierra un perfil o se abre uno nuevo (Mastodon, Bluesky), actualizar. Las cuentas huérfanas devuelven 404 a Googlebot y bajan la confianza del grafo.
• sameAs de la web. Si aparece un nuevo perfil externo con identificador estable (una nueva base de datos académica, un nuevo directorio profesional), añadirlo tanto como propiedad en Wikidata como en el bloque sameAs del JSON-LD.
• Descripciones. Revisar si la descripción corta sigue reflejando el nicho actual. Cambiar "actuario español" por "actuario español especializado en riesgo climático" cuando el nicho se ha estrechado.

La revisión trimestral cuesta unos veinte o treinta minutos si el item está limpio. Si se ha dejado morir un año, cuesta una tarde entera de recomponerlo. La diferencia neta a favor de la revisión trimestral es enorme.

Regla: una hora al trimestre. Cero excepciones. Es el coste de mantenimiento de la identidad digital estructurada.

Un mantenimiento silencioso adicional que ayuda mucho: cada vez que el consultor publica un artículo de blog o un libro nuevo, meter el nuevo enlace en el sameAs correspondiente y añadir una propiedad P800 con la nueva obra en Wikidata. Cada publicación es una oportunidad de reforzar el grafo. La mayoría de los consultores publica cosas y las deja huérfanas del item. Enganchar cada obra al grafo es lo que separa una identidad viva de una identidad congelada.

Errores frecuentes al ejecutar todo el ciclo

Además de los errores de patrullaje ya vistos, hay cinco errores estratégicos que hacen que el proyecto Wikidata no rinda ni con item aprobado.

Error 1: sameAs sin ida y vuelta. Síntoma: el item de Wikidata tiene P856 apuntando a la web, pero la web no tiene sameAs apuntando al Q-ID. O al revés. Google no cierra el circuito y no genera Knowledge Panel. Solución: comprobar los dos lados con la Rich Results Test y con la propia URL del item de Wikidata. Los dos enlaces deben estar. Sin excepciones.

Error 2: Mezclar persona y sociedad en un mismo item. Síntoma: el consultor crea un solo item con P31 igual a Q5 (ser humano) pero rellena propiedades de empresa (P452 industry, P1128 employees). O al revés. El item queda hibridado y Google no sabe si es persona u organización. Solución: dos items separados, enlazados entre sí por P108 (employer) y P169 (CEO).

Error 3: Descripción que cambia cada mes. Síntoma: el consultor edita la descripción cada vez que reformula su propuesta comercial. La descripción no es texto de marketing. Es la etiqueta corta y neutra que Google va a mostrar en el snippet. Solución: fijar la descripción durante al menos doce meses y solo cambiarla cuando cambia el nicho de verdad, no cuando cambia la campaña.

Error 4: Ignorar el ORCID. Síntoma: el consultor tiene producción publicada pero no ha registrado un ORCID. Solución: registrar ORCID gratuito en orcid.org, verter todas las publicaciones ahí, meter la propiedad P496 en Wikidata y sameAs en la web. ORCID es la fuente externa con más peso relativo para consultores técnicos y académicos, y es gratis.

Error 5: Crear el item con cuenta anónima. Síntoma: el editor no ha creado cuenta o la creó ese mismo día. Los patrulleros son más severos con cuentas nuevas. Solución: crear cuenta en Wikidata unos meses antes, hacer cinco o diez ediciones útiles en items existentes (correcciones menores, referencias añadidas, traducciones de descripciones), y solo entonces crear el propio item. Esa curva de reputación previa reduce el riesgo de revert a la mitad.

Preguntas frecuentes

¿Cómo se crea una entrada en Wikidata para una empresa o un profesional?

Se registra una cuenta en wikidata.org, se hacen algunas ediciones menores en items existentes para ganar reputación y se crea el nuevo item desde el botón "Create a new Item". El item necesita label (nombre), descripción corta neutra y al menos una propiedad P31 (instance of) con valor correcto: Q5 para persona, Q4830453 o subtipo para empresa. Luego se añaden propiedades una a una con al menos dos referencias externas (ORCID, OpenCorporates, ISBN, VIAF) para que sobreviva al patrullaje inicial.

¿Qué beneficio real tiene aparecer en Wikidata para el SEO?

Tres beneficios concretos. Uno: es la vía más corta para que Google active un Knowledge Panel con la foto, la descripción y los enlaces sociales al buscar el nombre exacto. Dos: los LLMs que usan grafos de entidades derivados de Wikidata (varios generalistas lo hacen) empiezan a citar al consultor como referencia cuando se les pregunta por su nicho. Tres: el Q-ID sirve de ancla estable para todo el marcado JSON-LD del sitio, lo que refuerza la coherencia semántica de todas las páginas y ayuda al posicionamiento en resultados enriquecidos.

¿Cómo se consigue aparecer en el Knowledge Panel de Google?

Hay dos requisitos convergentes. Uno: existir como entidad reconocible en el Knowledge Graph, lo que en el 90% de los casos se resuelve por Wikidata con item bien construido y referencias externas verificables. Dos: cerrar el circuito con JSON-LD en la web propia que declare @type Person u @type Organization con sameAs apuntando al Q-ID de Wikidata, al ORCID, al LinkedIn y a otros identificadores externos. Con las dos partes en su sitio, el panel aparece en la horquilla de tres a doce meses según el nivel de señal previo.

¿Qué propiedades mínimas de Wikidata debe rellenar un consultor técnico?

Para persona: P31 igual a Q5, P21 (sex or gender), P106 (occupation), P569 (date of birth), P27 (country of citizenship), P856 (official website), P496 (ORCID), P2035 (LinkedIn) y P800 (notable work) al menos con una obra referenciada. Para la sociedad, en su item aparte: P31 con subtipo de empresa, P17 (country), P159 (headquarters location), P571 (inception), P452 (industry), P169 (CEO enlazado al item de la persona) y P1320 (OpenCorporates ID). Con esas propiedades, más al menos dos referencias externas, el item pasa el patrullaje inicial.

¿Hace falta pagar a alguien para crear el item?

No. La cuenta y la edición en Wikidata son gratuitas y no aceptan pago por creación. Hay agencias que cobran por hacerlo, pero el trabajo es reproducible por cualquier persona que dedique unas horas a leer la documentación de propiedades. Pagar tiene sentido solo cuando el consultor no dispone de las horas y quiere delegar la ejecución, no cuando busca un atajo hacia la aprobación. El item lo aprueba la comunidad de patrulleros con reglas públicas.

¿Se puede pedir a Google que dispare el Knowledge Panel más rápido?

No hay canal directo para eso. Google no acepta solicitudes de creación de panel. Lo único que se puede hacer, una vez el panel aparece, es reclamarlo desde la Search Console para editar información concreta (foto, descripción) usando el flujo de "Claim this Knowledge Panel". El disparo inicial depende del cruce automático entre Wikidata, el JSON-LD del sitio y las menciones externas. La única forma de acelerar es reforzar señales, no pedir.

Cierre

Un item de Wikidata no es marketing. Es infraestructura de identidad digital, del mismo orden que registrar un dominio propio o dar de alta un NIF. Lo hace una vez el propio consultor, se mantiene una hora al trimestre y devuelve durante años presencia estable en Google y citas en LLMs. El coste marginal es risible frente al beneficio compuesto.

La mayoría de los consultores no lo tiene porque nadie se lo ha explicado con este nivel de concreción, o porque han confundido Wikidata con Wikipedia y han tirado la toalla al ver los criterios de notabilidad enciclopédica. Pero la puerta correcta era la otra y siempre estuvo abierta. Un actuario con un libro y un ORCID cabe. Un ingeniero con una ponencia en un congreso IEEE cabe. Un consultor con una sociedad activa cinco años en OpenCorporates cabe. No es cuestión de fama. Es cuestión de identificadores.

Si tienes perfil público mínimo (libro, ponencia, ORCID, sociedad activa) y tu marca profesional se vende, entre otras cosas, por autoridad técnica, tienes un Q-ID pendiente de nacer. Y una vez nazca, todo el trabajo que hagas después de publicar (artículos, libros, ponencias, apariciones) empieza a acumularse sobre esa ancla en lugar de dispersarse en menciones sueltas. Si quieres que revisemos juntos qué propiedades te tocan, qué referencias externas ya tienes disponibles y cómo montar el JSON-LD que cierra el circuito con Google, reserva una cita de 30 minutos o mira cómo abordamos la identidad semántica dentro de un software vertical propio. Cero coste, cero venta agresiva, salida con un plan escrito de tres pasos.

Lecturas relacionadas

• Introducción a Wikidata para principiantes (Wikimedia Foundation)
• Guía de propiedades para personas (Wikimedia Foundation)
• Rich Results Test de Google (Google Search Central)
• Documentación oficial de schema.org sobre Person y Organization
• OpenCorporates: datos abiertos de sociedades