Kio estas JSON-LD?
Serĉvidebleco, indeksado kaj strukturitaj datumoj
JSON-LD, mallongigo de JavaScript Object Notation for Linked Data, estas formato bazita sur JSON por publikigi ligitajn datumojn - la entojn, ecojn kaj rilatojn de paĝo. Ĝi estas la plej ofte uzata formato por aldoni Schema.org strukturitajn datumojn, kiel Article kaj BreadcrumbList, kiuj helpas maŝinojn kompreni paĝon. JSON-LD estas W3C-normo. Ĝi ne estas ŝparvojo por rangotabeloj, kaj validaj strukturitaj datumoj ne garantias riĉajn rezultojn. La markado devas priskribi enhavon efektive videblan sur la paĝo, kaj la paĝo devas esti rampebla kaj indeksebla por profiti.
Reviziita de Jackie, Head of Learning & Development, Levellers - Laste reviziita la 8-an de junio 2026
Kion tio signifas
JSON-LD estas orda maniero priskribi la temon de paĝo en formo legebla de maŝinoj. Anstataŭ lasi serĉilon konjekti signifon el la vortoj sur ekrano, vi diras ĝin rekte - ekzemple, ke ĉi tiu paĝo estas artikolo, kun tiu ĉi titolo, tiu ĉi aŭtoro kaj tiu ĉi publikigdato.
Helpas distingi kvar ideojn, kiuj ofte konfuziĝas. JSON estas ĝenerala datumformato. JSON-LD estas specifa varianto de JSON por ligitaj datumoj. Schema.org estas la komuna vortaro de tipoj kaj ecoj, kiel Article aŭ Person. Strukturita datuma markado estas la praktiko uzi formaton kiel JSON-LD por publikigi tiun vortaron sur paĝo. JSON-LD estas populara ĉar ĝi sidas en aparta koda bloko anstataŭ esti teksita tra la videbla HTML, kio faciligas aldoni, ŝablonigi kaj prizorgi ĝin.
Kial ĝi gravas
Klara maŝina kompreno estas kvalito de bona eldonado. Kiam serĉilo povas fidinde legi kiu verkis paĝon, kiam ĝi estis ĝisdatigita kaj pri kio ĝi temas, la paĝo estas pli facile prezentebla precize kaj surfacebla por la ĝustaj demandoj. JSON-LD estas la formato, kiun Google rekomendas por tio, kvankam Microdata kaj RDFa ankaŭ estas subtenataj kaj traktataj kiel egale validaj kiam ĝuste efektivigitaj.
La komerca averto estas, ke strukturitaj datumoj ne estas magio. Ili ne levas rangojn memstare, kaj ĝusta markado ne garantias riĉan rezulton. Serĉiloj decidas, kion montri, surbaze de multaj faktoroj, kaj ili povas ignori aŭ malakcepti markadon, kiu estas misgvida aŭ ne kongruas kun la videbla paĝo. La valoro venas el preciza, reprezenta markado sur paĝoj, kiuj jam meritas montriĝi - ne el markado de maldika aŭ kaŝita enhavo.
Kiel ĝi funkcias
W3C-normo por ligitaj datumoj
JSON-LD estas publikigita W3C-normo. Ĝi unue fariĝis W3C-Rekomendo en 2014, kaj la nuna versio, JSON-LD 1.1, fariĝis Rekomendo en 2020. Ĝi difinas JSON-bazitan manieron seriigi ligitajn datumojn, por ke la sama informo povu esti dividita kaj komprenita tra malsamaj sistemoj. Sur retpaĝoj, ĝi plej ofte estas uzata por publikigi Schema.org-vortaron ene de skripta bloko de tipo application/ld+json.
Oftaj tipoj kaj kampoj
Por artikolo, la rilata Schema.org-tipo estas Article, aŭ la pli specifa NewsArticle aŭ BlogPosting. La kampoj, kiuj helpas serĉilon kompreni la paĝon, inkluzivas la titolon, la aŭtoron kun nomo kaj URL, la publikigdaton, la modifan daton, bildon kaj la kanonan referencon. Titolo plej bone estu konciza, ĉar tre longaj titoloj povas esti trunkataj, kaj la gvidlinioj de Google sugestas limigi ĝin al ĉirkaŭ 110 signoj. Panmigroj estas priskribitaj per BreadcrumbList kaj ĝiaj ListItem-eroj, kiuj fiksas la pozicion de la paĝo ene de la hierarkio de la retejo.
La regulo, ke markado devas reprezenti la paĝon
Strukturitaj datumoj devas priskribi la enhavon efektive sur la paĝo kaj esti reprezentaj de ĝia ĉefa enhavo. Marki enhavon, kiu estas kaŝita, nerilevanta aŭ misgvida, rompas la gvidliniojn kaj povas kaŭzi, ke la markado estu ignorata aŭ traktata kiel spamo - tio estas fidindeca limo, kiu meritas respekton. La markado estas vera deklaro pri la paĝo, ne alternativa versio de ĝi.
Kie la markado estas generata
JSON-LD povas esti aldonita servile, per ŝablono de enhavadministra sistemo, aŭ injektita per JavaScript, inkluzive per etikedadministrilo. Ĉiu metodo funkcias, sed la injektitaj aliroj portas pli da risko. Se paĝo komenciĝas per noindex-instrukcioj, serĉilo povas preteriri renderadon kaj neniam ruli la JavaScript-on, kiu estus aldoninta la markadon. Mismatchoj en etikedadministriloj ankaŭ povas lasi la renderitan markadon malkongrua kun la paĝo. Servila aŭ ŝablon-bazita markado, kiu aperas en la komenca HTML, estas la plej fidinda.
Elektebleco kaj AI-funkcioj
Valida markado estas necesa sed ne sufiĉa. Paĝo devas esti indeksebla kaj elektebla por montriĝi kun fragmento, antaŭ ol ĝi povas esti konsiderata por riĉaj rezultoj aŭ por generativaj funkcioj kiel AI Overviews. Ne bloku strukturitajn datumpaĝojn per robots.txt aŭ noindex, se vi volas, ke ili estu elekteblaj. Por la AI-funkcioj de Google specife, ne ekzistas speciala postulo pri strukturitaj datumoj kaj neniu speciala markado por aldoni. La samaj fundamentoj validas - nome rampebla, indeksebla paĝo elektebla por aperi kun fragmento.
La nuna stato de FAQ-riĉaj rezultoj
Strukturitaj datumtipoj ŝanĝiĝas laŭtempe, kaj la FAQ-funkcio estas klara lastatempa ekzemplo. La dokumentaro de Google deklaras, ke ekde la 7-a de majo 2026, FAQ-riĉaj rezultoj ne plu aperas en Google Search. La FAQ-serĉa aspekto, la riĉa rezulta raporto kaj subteno en la Rich Results Test estas forigotaj en junio 2026, kaj subteno por la FAQ-riĉa rezulto en la Search Console API estos forigita en aŭgusto 2026. FAQPage restas valida Schema.org-tipo, do la markado mem ne estas nevalida kaj povas resti, sed ĝi ne plu produktas tiun videblan serĉfunkcion. HowTo-riĉaj rezultoj estis simile malakceptitaj en 2023, kaj la HowTo-dokumentaro poste estis forigita. La leciono por gvidantoj estas, ke riĉaj rezultaj funkcioj venas kaj foriras, dum la baza valoro de preciza, reprezenta strukturita markado daŭras.
Ekzemploj
Enhava teamo mapas ĉiun paĝtipon al kongrua Schema.org-tipo - uzante Article por redakciaj pecoj kaj BreadcrumbList por navigada kunteksto - kaj konfirmas, ke la titolo, aŭtoro, publikigdato kaj modifa dato estas plenigitaj el la ĝustaj kampoj anstataŭ restadi ĉe ŝablon-defaŭltoj.
Entrepreno, kiu antaŭe aldonis FAQ-markadon por gajni etendeblan serĉfunkcion, reviziis siajn paĝojn post kiam la funkcio estis retirita. Ili konservas la FAQ-markadon kie ĝi precize reflektas realan, videblan sekcion de demandoj kaj respondoj, kaj forigas ĝin kie la sekcio estis maldika kaj aldonita nur por la malnova funkcio.
Evoluiga teamo movas strukturitajn datumojn el etikedadministrilo en la paĝŝablonon, post kiam ili konstatis, ke la injektita markado foje malsukcesis renderadi. Ili poste validigas la renderitan markadon kontraŭ la videbla paĝo per strukturita datuma testilo antaŭ ĉiu eldono.
Oftaj miskomprenoj
La plej ofta eraro estas atendi, ke strukturitaj datumoj levu rangojn. Ili helpas maŝinojn kompreni paĝon, sed ili ne estas ŝparvojo por rangotabeloj kaj ne garantias riĉan rezulton.
Dua estas marki enhavon, kiu ne estas videbla sur la paĝo - tio rompas la gvidliniojn kaj povas esti traktata kiel spamo.
Tria estas supozi, ke valida markado sufiĉas. Strukturitaj datumoj povas esti teknike validaj sed malbonoj, kun malfreŝaj aŭ eraraj valoroj, kaj ĝusta markado ankoraŭ ne garantias riĉan rezulton.
Kvara estas konfuzi la konstrubrikojn. JSON, JSON-LD, Schema.org kaj strukturita datuma markado estas apartaj aferoj, kaj klareco pri kiu estas kiu malhelpas efektivigajn erarojn.
Riskoj kaj limoj
Kampmapaj fiaskoj estas la plej ofta praktika risko. Enhavadministra sistemo povas publikigi malfreŝan titolon, malĝustajn datojn, defaŭltan panmigran vojon aŭ malĝustan eldoniston - tiel la markado kviete misprezentadas la paĝon.
Troa markado estas dua risko, kie teamoj markas ĉion en la espero de pli da funkcioj, kio aldonas bruon sen valoro.
Vivocikla kaj ŝablona risko estas tria. Ŝablona ŝanĝo aŭ kromaĵa ĝisdatigo povas rompi aŭ ŝanĝi la markadon silente, do ĝi bezonas retestadi post ŝanĝoj.
La fidindeca limo estas la firma barero. Serĉiloj povas ignori aŭ malakcepti markadon, kiu estas misgvida aŭ ne kongruas kun la videbla paĝo, do la markado devas ĉiam esti vera reprezento de tio, kion leganto vidas. Bloki strukturitajn datumpaĝojn per robots.txt aŭ noindex forigas la elekteblecon, kiun la markado estis celita subteni.
Kion fari poste
Elektu Schema.org-tipojn, kiuj vere kongruas kun ĉiu paĝo, kaj rezistadu marki enhavon, kiu ne estas ĉeesta aŭ ne videbla.
Akordigu redakcian kaj teknikan proprieton, por ke la homoj, kiuj verkas titolojn kaj datojn, kaj la homoj, kiuj konstruas ŝablonojn, konsentu pri la deveno de ĉiu kampo. Revizieu vian markadon per riĉa rezulta testilo, kaj komparu la renderitajn strukturitajn datumojn kun la videbla paĝo por kapti malfreŝajn aŭ mismatchajn valorojn. Traktu strukturitajn datumojn kiel daŭran investon en maŝina kompreno anstataŭ kiel ĉadon post iu ajn sola riĉa rezulta funkcio - ĉar funkcioj kiel FAQ kaj HowTo estis retiritaj, dum preciza markado konservas sian valoron.
Ĉu vi havas demandon aŭ sugeston, aŭ volas kompreni, kiel ni esploras kaj reviziis ĉi tiujn gvidilojn? Legu pri niaj redakciaj normoj kaj kiel kontakti nin.
Oftaj demandoj
Kia estas la diferenco inter Article kaj BlogPosting?
BlogPosting estas pli specifa tipo de Article, celita por blogstilaj afiŝoj, dum Article taŭgas por ĝenerala skribita enhavo kaj NewsArticle por ĵurnalismo. Uzu la plej specifan tipon, kiu vere konvenas al la paĝo. Ĉiuj tri estas subtenataj kaj uzas similajn kampojn.
Ĉu JSON-LD helpos miajn paĝojn aperi en AI-serĉo?
Nerekte, plej multe. Paĝo devas esti indeksebla kaj elektebla por montriĝi kun fragmento, antaŭ ol AI-funkcioj konsideras ĝin, kaj Google deklaras, ke ne ekzistas speciala postulo pri strukturitaj datumoj por ĝiaj AI-funkcioj. Preciza markado subtenas maŝinan komprenon, sed ĝi ne estas garantiita vojo al AI-videbleco.
Ĉu estas sekure injekti JSON-LD per JavaScript aŭ etikedadministrilo?
Ĝi povas funkcii, sed ĝi portas riskon. Se paĝo komenciĝas per noindex-instrukcioj, la serĉilo povas preteriri renderadon kaj neniam ruli la skripton, kaj etikedadministrilaj aranĝoj povas malkongruiĝi kun la paĝo. Servila aŭ ŝablon-bazita markado en la komenca HTML estas pli fidinda.
Ĉu valida strukturita markado garantias riĉan rezulton?
Ne. Ĝusta markado igas paĝon elektebla por funkcio - ĝi ne garantias ĝin. Serĉiloj decidas, kion montri, surbaze de multaj faktoroj, kaj povas montri anstataŭe simplan rezulton.
Kiaj estas la plej oftaj CMS-eraroj kun JSON-LD?
Malfreŝaj aŭ malĝustaj kampvaloroj - kiel malnova titolo, malĝustaj publikig- aŭ modifaj datoj, defaŭlta panmigra vojo aŭ malĝusta eldonisto. Tiuj devenas el malbona kampmapado kaj estas kaptitaj per komparo de la renderita markado kun la videbla paĝo.
Ĉu FAQ-riĉaj rezultoj ankoraŭ aperas en Google?
Ne. La dokumentaro de Google deklaras, ke ekde la 7-a de majo 2026, FAQ-riĉaj rezultoj ne plu aperas en Google Search, kun raportada kaj testa subteno forigota en junio 2026 kaj Search Console API-subteno en aŭgusto 2026. FAQPage restas valida Schema.org-tipo, do la markado ne estas nevalida - ĝi simple ne plu produktas tiun funkcion.
Ĉu mi devas forigi miajn FAQ-strukturitajn datumojn nun?
Ne nepre. Konservu ilin kie ili precize priskribas realan, videblan sekcion de demandoj kaj respondoj, ĉar neuzataj strukturitaj datumoj ne kaŭzas problemojn. Forigu ilin kie la sekcio estis maldika aŭ aldonita nur por gajni la malnovan funkcion.
Kiun strukturitan datumformaton mi uzu?
Google rekomendas JSON-LD pro ĝia facileco de efektivigo kaj prizorgado, kvankam Microdata kaj RDFa ankaŭ estas subtenataj kaj traktataj kiel egale validaj kiam ĝuste efektivigitaj. Por la plej multaj novaj laboroj, JSON-LD estas la praktika defaŭlto.
Ĉu JSON-LD estas utila nur por Google?
Ne. Ĝi estas malfermita W3C-normo por ligitaj datumoj uzata tra multaj sistemoj, kaj aliaj serĉiloj kaj iloj povas legi Schema.org-markadon publikigitan en JSON-LD. Ĝia valoro estas ĝenerala maŝina kompreno, ne ununura platformo.
Fontoj
JSON-LD 1.1 (W3C). Confirmation that JSON-LD is a W3C Recommendation and a JSON based format for serialising linked data.
JSON-LD 1.1 Specifications are W3C Recommendations (W3C). The date JSON-LD 1.1 became a W3C Recommendation and the description of its purpose.
FAQPage type (Schema.org). Confirmation that FAQPage remains a current, valid Schema.org type that is not deprecated.
Mark Up FAQs with Structured Data (FAQPage) (Google Search Central). The deprecation notice stating FAQ rich results no longer appear as of 7 May 2026, with reporting and Rich Results Test support removed in June 2026 and Search Console API support removed in August 2026.