Què canvien realment les dades estructurades
Una pàgina web és un text que el motor ha d’interpretar. Les dades estructurades suprimeixen aquesta interpretació: declaren explícitament que aquest nombre és un preu, que aquesta data és una data d’esdeveniment, que aquesta persona és l’autor. El format retingut per Google per a aquesta declaració és el JSON-LD, un bloc de codi aïllat a la capçalera de la pàgina, sense efecte en la visualització.
L’efecte directe en el rànquing és nul, i cal dir-ho clarament per evitar falses expectatives. Cap marcatge fa pujar una pàgina. El que produeix és una visualització enriquida en els resultats: estrelles de valoració, preu, disponibilitat, preguntes desplegables, fil d’Ariadna llegible, imatge de recepta. Aquesta visualització ocupa més superfície i atrau més clics a igual posició.
L’efecte indirecte és més profund. Un lloc web correctament marcat esdevé una font que els sistemes automàtics comprenen sense ambigüitat, la qual cosa és cada cop més important a mesura que els motors generen respostes en lloc de llistes d’enllaços. Declarar correctament la seva entitat, els seus serveis i els seus autors ja no és una optimització marginal, és la manera com una organització es fa llegible.
El JSON-LD es col·loca en una etiqueta de script dedicada, generalment a la capçalera del document. No és visible ni indexat com a text, i no substitueix el contingut de la pàgina. Un marcatge que declara una informació absent de la pàgina és una infracció de les directrius de Google i exposa a una acció manual.
Els tres formats i per què només un és important
Tres sintaxis coexisteixen històricament per expressar el mateix. Les microdades i el RDFa s’insereixen en l’HTML visible, afegint atributs a les etiquetes existents. El JSON-LD viu a part, en un bloc autònom.
Google recomana explícitament el JSON-LD des de fa diversos anys, per una raó pràctica: com que el marcatge està separat del contingut, es genera, es modifica i es valida sense tocar la plantilla. En un lloc web on el contingut és produït per diverses persones, aquesta separació evita que una modificació editorial trenqui el marcatge sense que ningú se n’adoni.
Els altres dos formats continuen sent llegits i interpretats, per tant, no hi ha urgència a migrar un lloc web que els utilitza correctament. En canvi, barrejar dos formats a la mateixa pàgina produeix declaracions concurrents i resultats impredictibles. Un sol format per pàgina, i preferiblement el JSON-LD.
El vocabulari Schema.org, i com orientar-s’hi
Schema.org és un vocabulari compartit, mantingut conjuntament pels principals motors. Defineix centenars de tipus i milers de propietats, la qual cosa desanima a la primera lectura. En la pràctica, una desena de tipus cobreixen gairebé la totalitat de les necessitats d’un lloc web professional.
Els tipus que realment necessitareu
Organization declara l’empresa mateixa, el seu nom, el seu logotip, les seves dades de contacte i els seus perfils oficials. LocalBusiness i els seus subtipus precisen l’establiment físic, els seus horaris i la seva zona de servei. Article cobreix els continguts editorials, Product les fitxes de producte, FAQPage les preguntes freqüents, BreadcrumbList el fil d’Ariadna, Person els autors i Service les prestacions.
El principi de selecció és simple: prendre el tipus més precís que existeix. Declarar un restaurant com a LocalBusiness funciona, declarar-lo com a Restaurant transmet més informació. Un gabinet dental guanya a utilitzar Dentist en lloc de MedicalBusiness. Aquesta precisió costa el mateix esforç i millora la comprensió.
El graf, per evitar les declaracions òrfenes
Una pàgina ben marcada no declara tres blocs independents, declara un conjunt d’entitats interconnectades. L’estructura en graf permet dir que aquest article té com a autor aquesta persona, la qual pertany a aquesta organització, la qual edita aquest lloc web.
Tècnicament, això consisteix a agrupar les entitats en una taula i donar-los identificadors estables, per després referenciar-les per aquests identificadors en lloc de copiar les seves propietats. El guany és doble: el fitxer segueix sent llegible, i els motors consoliden la informació d’una pàgina a l’altra al voltant dels mateixos identificadors.
Els marcatges que activen una visualització enriquida
No tots els tipus produeixen una visualització particular. Aquí teniu els que donen un resultat visible, per ordre de freqüència en els llocs web d’empresa.
FAQPage, el més rendible d’implementar
Declara preguntes i les seves respostes, i permet una visualització desplegable sota el resultat. El guany de superfície és clar i el cost d’implementació baix, ja que el contingut ja existeix a la pàgina. La condició a respectar és estricta: cada pregunta i cada resposta declarades han de ser visibles per al visitant, fins i tot si estan plegades en un acordió.
BreadcrumbList, discret però sistemàtic
Substitueix l’adreça bruta mostrada sota el títol per un camí llegible. L’efecte sobre la taxa de clics és modest pres aïlladament, però s’aplica a totes les pàgines del lloc web i només costa una generació automàtica des de l’arborescència. És el marcatge amb la millor relació entre esforç i cobertura.
Product i AggregateRating, per al comerç
Preu, disponibilitat, nota mitjana i nombre de ressenyes apareixen directament en els resultats. L’impacte sobre la taxa de clics és el més fort de tots els marcatges. La restricció és proporcional: les ressenyes declarades han de ser reals, recollides al lloc web i visibles. Declarar una nota agregada sense ressenyes mostrades és una infracció freqüent i sancionada.
LocalBusiness, per als establiments
Consolida l’entitat amb Google i creua la informació de la fitxa d’establiment. No activa una visualització espectacular, però contribueix a la coherència dels senyals locals, tema detallat a la nostra guia de SEO local.
Escriure un marcatge net, les regles que eviten errors
La sintaxi és simple, els errors són gairebé sempre lògics més que tècnics.
La primera regla és la correspondència estricta entre el marcatge i la pàgina. Un preu declarat ha de ser el preu mostrat. Una data de publicació declarada ha de correspondre a la visible. Aquesta exigència sembla evident i és violada constantment per marcatges generats automàticament a partir de camps mal emplenats.
La segona regla és l’estabilitat dels identificadors. Una entitat conserva el mateix identificador d’una pàgina a l’altra i d’un any a l’altre. Canviar l’identificador d’una organització a cada redisseny equival a crear una nova entitat i a perdre la consolidació acumulada.
La tercera és la completesa raonada. Emplenar les propietats obligatòries i després les propietats recomanades és suficient. Apilar desenes de propietats facultatives no aporta res i allarga un fitxer que caldrà mantenir. Més val cinc tipus ben emplenats que quinze tipus incomplets.
La quarta es refereix als caràcters especials. Un marcatge és JSON, per tant, les cometes internes han de ser escapades i els salts de línia codificats. Una ampersand no tractada o un apòstrof tipogràfic mal codificat és suficient per invalidar tot el bloc, i l’error és silenciós: el motor simplement ignora el marcatge.
Validar, i sobretot validar el bon renderitzat
La validació és l’etapa que tothom salta i la que revela la meitat dels problemes.
Les dues eines a utilitzar, en aquest ordre
El validador de Schema.org controla la conformitat amb el vocabulari: tipus existents, propietats autoritzades, valors correctament tipificats. El test dels resultats enriquits de Google controla una altra cosa: l’elegibilitat per a una visualització enriquida, amb les propietats que Google exigeix a més de les que Schema.org autoritza.
Els dos són complementaris i un marcatge pot passar el primer i fallar el segon. Utilitzar els dos evita concloure massa ràpid que un marcatge és correcte perquè no apareix cap error de sintaxi.
Provar l’URL en línia, no el codi enganxat
Aquesta és la precaució més important i la més negligida. Enganxar el codi al validador prova el que s’ha escrit. Provar l’adreça en línia prova el que el servidor envia realment, després del pas de les extensions, la memòria cau i les possibles reescriptures. La diferència entre els dos és freqüent, i és precisament aquí on s’amaguen els duplicats de declaració.
La Search Console proporciona un seguiment a llarg termini, per tipus de marcatge, amb els errors detectats en totes les pàgines explorades. És l’únic lloc on es veu que un problema afecta quatre-centes fitxes de producte i no només la que s’ha provat.
Els errors de marcatge més freqüents
Sis errors es repeteixen en gairebé totes les auditories que realitzem.
- Declarar un contingut absent de la pàgina. Preguntes marcades que no apareixen enlloc, o una nota agregada sense ressenyes visibles. Aquesta és la infracció més sancionada.
- Deixar que dues fonts generin el mateix tipus. L’extensió SEO i la plantilla produeixen cadascuna el seu bloc, i les dues es contradiuen.
- Marcar la pàgina d’inici com un Article. No ho és, és una WebPage o una Organization segons el que presenti.
- Oblidar d’actualitzar la data de modificació. Un article revisat que encara declara la seva data d’origen perd el benefici de la frescor.
- Utilitzar un tipus massa general. LocalBusiness quan existeix Restaurant, Dentist o HomeAndConstructionBusiness.
- No revalidar mai després d’una actualització. Una actualització d’extensió de vegades canvia el marcatge generat, sense avís.
Cap d’aquests errors és difícil de corregir. Persisteixen perquè ningú mira el marcatge una vegada que s’ha implementat, tot i que viu i es degrada com la resta del lloc web.
El marcatge per tipus de lloc web
Les prioritats difereixen segons l’activitat. Aquí teniu el que implementem sistemàticament segons el perfil.
Lloc web de prestació de serveis
Organization per a l’entitat, LocalBusiness si un establiment rep públic, Service per a cada prestació amb la seva zona de servei, BreadcrumbList a tot arreu, FAQPage a les pàgines que en contenen, i Person per a l’autor dels continguts editorials. Aquesta base cobreix l’essencial i es genera des de la plantilla.
Botiga en línia
Product a cada fitxa, amb Offer per al preu i la disponibilitat, AggregateRating si hi ha ressenyes reals, BreadcrumbList al camí de categories, i Organization a nivell de lloc web. El punt d’atenció és la generació automàtica en milers de fitxes: un error de plantilla es replica instantàniament a tot arreu.
Lloc web editorial i blog
Article o BlogPosting segons la naturalesa, amb autor identificat, dates de publicació i de modificació, i imatge. La declaració de l’autor mereix una atenció especial, ja que participa directament en els senyals d’expertesa, tema que tractem en la prestació de posicionament natural.
El marcatge en una botiga en línia, cas particular
El comerç concentra alhora el potencial més gran de visualització enriquida i el risc més gran d’error massiu. Una declaració de producte falsa no afecta una pàgina, afecta la totalitat del catàleg en una sola posada en línia.
El preu declarat ha de correspondre al preu efectivament pagat, impostos inclosos per a una clientela de particulars, i la divisa ha de ser explícita. Les botigues que mostren un preu sense impostos a la façana i declaren el mateix import en el seu marcatge produeixen resultats enganyosos que acaben sent denunciats.
La disponibilitat planteja un problema de sincronització. Un producte esgotat que continua declarant-se disponible genera frustració i degrada la confiança atorgada al domini. La declaració ha de connectar-se a l’estat real de l’estoc, no a un valor fixat a la plantilla.
Les variants, finalment. Un producte declinat en diverses talles o colors es pot declarar com una entitat única amb un rang de preus, o com diverses entitats diferents. L’elecció depèn de l’estructura de les adreces retinguda, que al seu torn depèn de la plataforma, tema tractat en la nostra comparativa WordPress o Shopify. Les dues aproximacions funcionen, barrejar-les en un mateix catàleg no funciona.
En els catàlegs grans, la regla de prudència és provar la plantilla en tres productes representatius abans de desplegar-la, i després verificar-ho a la Search Console durant les dues setmanes següents. Un error replicat en vuit-centes fitxes es corregeix tan ràpid com es va propagar, però cal veure’l. És un dels punts de control d’una prestació de SEO e-commerce.
El marcatge es decideix amb l’arquitectura, no després
Una observació metodològica que val per a tots els projectes. El marcatge expressa l’estructura del lloc web, no la crea. Un lloc web amb una arborescència confusa produeix un fil d’Ariadna confús, i cap declaració no compensarà una jerarquia mal pensada.
Per això, tractem el marcatge en el moment en què l’arquitectura es dissenya, amb la mateixa lògica que la que s’exposa en el nostre mètode de cocon semàntic. Els identificadors d’entitats, les relacions entre pàgines pilars i pàgines filles, la jerarquia de les categories: tot això es decideix una vegada, i després es tradueix mecànicament en marcatge.
En un projecte nou, aquesta exigència es formalitza en el plec de condicions del lloc web, al mateix títol que els llindars de rendiment. Llavors costa unes hores. Afegida després de la posada en línia, suposa tornar a cada plantilla i verificar cada tipus, la qual cosa representa diversos dies.
El cas dels llocs web multilingües mereix una menció. Cada versió lingüística porta el seu propi marcatge, amb la llengua declarada i identificadors d’entitat compartits entre les versions. L’organització segueix sent la mateixa entitat sigui quina sigui la llengua, cosa que la declaració ha de reflectir, ja que altrament el motor veu quatre organitzacions diferents amb el mateix nom.
Quant costa un marcatge complet
La qüestió del pressupost sempre arriba, i la resposta depèn sobretot del nombre de plantilles, no del nombre de pàgines.
En un lloc web de prestació de serveis clàssic, compteu un dia per a l’inventari i la neteja, un dia per dissenyar el graf i establir la base, i mig dia per cada plantilla específica restant. Un lloc web corporatiu de vint pàgines amb tres plantilles es gestiona en dos o tres dies.
En una botiga, afegiu la plantilla de producte i la plantilla de categoria, més el temps de verificació en una mostra representativa. El catàleg en si no canvia el cost, ja que el marcatge es genera, la qual cosa explica que una botiga de vuit-centes referències no costi més de marcar que una botiga de cinquanta.
Aquest pressupost és modest en relació amb l’efecte, i això és el que el converteix en una de les intervencions amb millor rendiment en un projecte de posicionament. Els llocs web que lliurem a les nostres realitzacions parteixen tots amb aquesta base implementada, la qual cosa evita haver-hi de tornar.
El que el marcatge no farà per vosaltres
Una aclaració útil, perquè el tema atrau promeses excessives.
El marcatge no fa pujar una pàgina en els resultats. Una pàgina mal escrita, en un lloc web lent i sense autoritat, romandrà al seu lloc sigui quina sigui la qualitat de les seves declaracions. Els guanys observats després d’un marcatge provenen de la millora de la taxa de clics, no d’un canvi de posició.
Tampoc garanteix la visualització enriquida. L’elegibilitat és una condició necessària, la visualització segueix sent una decisió de Google presa consulta per consulta. Una pàgina perfectament marcada pot no mostrar cap enriquiment durant mesos, i després mostrar-lo sobtadament.
Finalment, no compensa cap defecte tècnic. Un lloc web les pàgines del qual triguen cinc segons a mostrar-se té un problema que el marcatge no afecta, i que s’ha de tractar primer, com es detalla en el nostre article sobre els Core Web Vitals. L’ordre de prioritats és important: accessibilitat tècnica, contingut, arquitectura, i després marcatge.
Implementar el marcatge en un lloc web existent
El mètode que apliquem consta de cinc fases i generalment s’estén durant dos o tres dies de treball per a un lloc web de mida mitjana.
Primer, inventari: quines plantilles existeixen, quin marcatge ja es produeix i per què. Aquesta etapa gairebé sempre revela generacions automàtiques oblidades, heretades d’una antiga extensió.
Després, neteja: desactivar les fonts concurrents per mantenir només un emissor per tipus. Aquesta és l’etapa que resol la majoria dels problemes i no produeix cap contingut nou.
Disseny del graf: definir els identificadors estables de l’organització, de l’establiment i dels autors, d’una vegada per totes. Aquests identificadors s’utilitzaran en totes les pàgines i no hauran de canviar més.
Implementació per plantilla, començant per la que cobreix més pàgines. Un marcatge implementat a la plantilla d’article cobreix instantàniament tot el blog, mentre que un marcatge implementat pàgina per pàgina no s’acaba mai.
Finalment, validació, a les adreces en línia i no al codi, i després seguiment mensual a la Search Console durant el primer trimestre. Aquesta última etapa detecta les regressions provocades per les actualitzacions, que són la principal causa de degradació a llarg termini. Forma part del que cobreix un contracte de manteniment seriós.
Una paraula sobre la documentació interna. En els llocs web on intervenen diverses persones, escriure una pàgina que descrigui els identificadors d’entitats retinguts i el tipus esperat per plantilla evita que un desenvolupador posterior utilitzi altres convencions. Aquesta pàgina ocupa mitja pàgina i estalvia hores de desfer embolics dos anys més tard.
El que heu de recordar
El JSON-LD declara explícitament el que conté una pàgina, perquè el motor no hagi d’endevinar-ho. No fa guanyar posicions, fa guanyar superfície i clics, i fa que l’empresa sigui llegible per sistemes automàtics la importància dels quals augmenta.
Tres regles són suficients per evitar gairebé tots els problemes. Declarar només el que és visible a la pàgina. Tenir només una font de generació per tipus. Provar l’adreça en línia en lloc del codi escrit, perquè la diferència entre els dos és precisament on es troben els errors.
Comenceu per BreadcrumbList i FAQPage, que cobreixen moltes pàgines amb poc esforç, i després afegiu la base Organization i LocalBusiness. La resta es tracta plantilla per plantilla, per ordre de nombre de pàgines cobertes. És una intervenció curta, mesurable, i l’efecte de la qual es llegeix a la Search Console en poques setmanes.
Una precisió sobre el manteniment del marcatge. Els tipus i les propietats de Schema.org evolucionen, i les exigències de Google per a la visualització enriquida canvien encara més ràpid: alguns tipus han perdut la seva elegibilitat, d’altres l’han guanyada. Una revisió anual del marcatge, alineada amb la revisió tècnica del lloc web, és suficient per mantenir-se al dia sense dedicar-hi un seguiment permanent. Aquest control pren una hora i evita descobrir a posteriori que una visualització ha desaparegut des de fa sis mesos.
