Како валидирати структуриране податке без Google алата

Валидација структурираних података постала је необично зависна од алата усмерених ка Google-у. То је разумљиво: многи тимови додају JSON-LD зато што желе богате резултате, а Google-ови алати за тестирање су познати. Али структурирани подаци нису Google формат. То је најчешће JSON-LD који користи Schema.org речник, уграђен у HTML, тумаче га многи потрошачи података, а одржава га ваш сопствени издавачки ток рада.

Ако валидирате само кроз призму претраживача, можете пропустити основне проблеме: неисправан JSON, податке који нестају после рендеровања, застареле цене производа, супротстављене canonical URL-ове или markup који је технички исправан, али семантички бесмислен.

Бољи ток рада почиње од стандарда. Прво валидирајте податке као податке, затим речник, а онда страницу онако како постоји у продукцији.

Шта заправо валидирате?

„Структурирани подаци“ нису једна ствар. На већини веб-сајтова имају четири слоја:

1. JSON синтакса — да ли се код може парсирати?
2. JSON-LD модел — да ли се проширује у смислене повезане податке?
3. Schema.org речник — да ли су типови и својства уверљиви?
4. Истинитост на нивоу странице — да ли markup одговара ономе што корисници и crawler-и могу да виде?

Google алати се углавном фокусирају на четврти слој, уз Google-ова специфична правила за подобност за богате резултате. Корисно, да. Потпуно, не.

На пример, ово може бити исправан JSON-LD, а ипак лоши структурирани подаци:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Best winter jackets",
  "datePublished": "2026-01-12",
  "author": {
    "@type": "Organization",
    "name": "Editorial Team"
  }
}

Овде ништа није покварено. Али ако видљива страница има другачији наслов, нема навођење аутора и има датум последње измене који противречи markup-у, имате проблем квалитета, а не проблем синтаксе.

Корак 1: Парсирајте JSON пре него што размишљате о SEO-у

Почните од досадне провере: да ли се JSON може парсирати?

JSON-LD уграђен у HTML често пуца због малих грешака у шаблону:

• завршни зарези
• неескејповани наводници у називима производа
• неисправни преломи редова унутар стрингова
• недостајуће витичасте заграде после условних поља
• дуплирани script блокови због наслеђивања layout-а
• CMS додаци који исписују делимичне објекте

За локалне провере није вам потребна SEO платформа. Користите алате који већ постоје у вашем развојном stack-у.

У JavaScript-у:

const blocks = [...document.querySelectorAll('script[type="application/ld+json"]')];

for (const block of blocks) {
  try {
    JSON.parse(block.textContent);
  } catch (error) {
    console.error('Invalid JSON-LD:', error.message, block);
  }
}

У CI-ју, издвојите садржај script елемената из рендерованог HTML-а и парсирајте их као JSON. То хвата многе проблеме пре него што стигну у продукцију.

Важно је следеће: урадите ово пре било какве Schema.org валидације. Валидатор речника не може да помогне ако подаци нису исправан JSON.

Корак 2: Проверите понашање JSON-LD-а, не само JSON синтаксу

Исправан JSON није аутоматски исправан JSON-LD. JSON-LD користи концепте као што су @context, @type, @id и односи у графу. Ако су они лоше обликовани, parser-и могу протумачити ваше податке другачије него што сте намеравали.

У најмању руку, потврдите:

• да сваки блок има одговарајући @context
• да примарни ентитети имају јасне @type вредности
• да поновљени ентитети користе стабилне @id вредности тамо где је корисно
• да су угнежђени ентитети логички повезани
• да се низови користе када је могуће више вредности

За веће сајтове, стабилни идентификатори су посебно корисни. Ако се ваша организација појављује у подацима за Article, Product, BreadcrumbList и FAQPage, коришћење истог @id помаже потрошачима да разумеју да су то референце на исти ентитет, а не четири неповезане организације са истим именом.

Типичан образац изгледа овако:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "url": "https://example.com/"
}

Овде не покушавате да импресионирате валидатор. Чините своје податке мање двосмисленим.

Корак 3: Валидирајте према Schema.org речнику

Када су JSON и JSON-LD структура исправни, проверите речник.

Schema.org валидатор је користан зато што тестира према Schema.org терминима, а не према правилима једног претраживача за богате резултате. Може да покаже да ли су својства препозната, да ли се типови тумаче очекивано и да ли ваше угнежђене структуре имају смисла.

Овде хватате грешке као што су:

• publishingDate уместо datePublished
• imageUrl тамо где се очекује image
• Product markup на листингу категорије који није производ
• AggregateRating без смислене ставке која је оцењена
• Person коришћен за налог бренда

Будите опрезни са упозорењима. Schema.org је намерно флексибилан. Валидатор може дозволити својство које није корисно за ваш случај употребе, или упозорити на нешто што је опционално. Третирајте валидацију као доказ, не као пресуду.

Практично правило: ако својство помаже машини да тачније разуме страницу, задржите га. Ако постоји само зато што га је неко копирао из генератора snippet-а, преиспитајте га.

Корак 4: Упоредите markup са видљивим садржајем

Претраживачи и други потрошачи података имају тенденцију да не верују markup-у који не одговара страници. Још важније, корисници заслужују доследност.

За сваки тип структурираних података, упоредите markup са видљивом страницом:

Article и BlogPosting

Проверите да ли су наслов, аутор, датум објављивања, датум измене, слика и издавач видљиви или разумно изводљиви. Ако објављујете садржај потпомогнут AI-јем, ваши структурирани подаци не треба да се користе за прикривање нејасног ауторства. Посебно смо писали о поштеном AI обелодањивању на малом веб-сајту, а исти принцип важи и овде: metadata треба да разјасни, не да замагли.

Product

Проверите назив, цену, доступност, валуту, варијанте, оцене и број рецензија. Структурирани подаци о производима су посебно склони застаревању зато што се цене и стање залиха мењају ван CMS-а.

LocalBusiness

Проверите назив, адресу, број телефона, радно време и подручје услуге. Ако footer каже једно, а ваш JSON-LD друго, JSON-LD није „бољи“. Он је противречан.

BreadcrumbList

Проверите да ли позиције у breadcrumb-у одговарају видљивој breadcrumb путањи и да ли су URL-ови canonical, crawlable и без непотребних редирекција.

Ово није гламурозан посао. Али управо ту се налазе многи проблеми са структурираним подацима.

Корак 5: Валидирајте рендеровану страницу, не свој шаблон

Многи сајтови генеришу JSON-LD преко JavaScript-а, tag manager-а, слојева персонализације или component hydration-а. То значи да фајл шаблона можда не представља оно што crawler или browser заправо види.

Валидирајте рендеровани HTML у најмање три стања:

• локални development build
• staging или preview URL
• production URL

Користите browser DevTools да прегледате коначни DOM. Потражите application/ld+json и копирајте тачан садржај script елемента који постоји после рендеровања. Ако се server-rendered markup разликује од hydrated markup-а, одлучите коју верзију очекујете да потрошачи читају.

Такође проверите да ли се структурирани подаци дуплирају. Дуплирани Article или Product блокови су чести када и CMS додатак и прилагођена компонента емитују schema. Дуплирање није увек фатално, али конфликтно дуплирање јесте проблем: две цене, два аутора, два датума објављивања или два canonical URL-а.

Ово је слично читању извештаја о перформансама и дијагностици: први задатак није паника, већ раздвајање сигнала од шума. Иста навика помаже када читате Lighthouse извештај без панике — иако структуриране податке саме по себи не треба сводити на један скор.

Корак 6: Проверите продукционе транспортне детаље

Структурирани подаци могу бити савршени у вашем извору, а ипак отказати у продукцији зато што страница није доступна на начин који претпостављате.

Проверите:

• да је коначни статусни код 200, а не soft 404
• да canonical URL одговара страници коју валидирате
• да су редирекције намерне и стабилне
• да robots директиве не блокирају индексирање тамо где се индексирање очекује
• да HTML није замењен страницом са грешком за неке user agent-е
• да кеширане странице не испоручују застарели JSON-LD

Овде је важна HTTP инспекција. Ако страница производа пролази кроз три URL-а пре него што стигне до canonical одредишта, валидирајте коначну страницу, а не први URL копиран из CMS-а. За сирову механику, наш водич за debugging редирекција и HTTP header-а у продукцији користан је пратилац.

Структурирани подаци не живе у вакууму. Путују заједно са header-има, редирекцијама, кеширањем, canonical tag-овима и robots директивама.

Корак 7: Додајте тестове структурираних података у процес објављивања

Ручна валидација је у реду за једну страницу. Не скалира се на стотине или хиљаде URL-ова.

Једноставан аутоматизовани test suite може ухватити најскупље грешке:

• дохватите репрезентативне URL-ове за сваки тип шаблона
• издвојите све JSON-LD блокове
• парсирајте их помоћу JSON.parse
• проверите обавезна поља за сваки тип странице
• проверите да ли су датуми исправни ISO 8601 стрингови
• проверите да ли су URL-ови апсолутни и canonical
• проверите да ли цене и доступност постоје за странице производа
• проверите да ли се дуплирани ентитети не сукобљавају

Ово можете покретати у CI-ју за шаблоне и по распореду за продукционе URL-ове. Циљ није да докажете да ће се свака функција богатих резултата појавити. Нико ван претраживача то не може обећати. Циљ је да ваши сопствени подаци остану тачни, парсабилни и доследни.

<!-- tool-cta:start -->

💡 Испробајте ово: Пре него што валидирате логику шеме, пропустите свој JSON-LD кроз JSON Formatter да бисте ухватили синтаксне грешке које би иначе поквариле сваку накнадну проверу.

<!-- tool-cta:end -->

Контролна листа за валидацију која полази од стандарда

Користите ову кратку контролну листу пре него што питате да ли се страница допада претраживачу:

• Да ли је сваки JSON-LD блок исправан JSON?
• Да ли сваки блок садржи исправан @context и @type?
• Да ли су Schema.org својства правилно написана?
• Да ли markup одговара видљивом садржају?
• Да ли су датуми, цене, оцене и доступност актуелни?
• Да ли су URL-ови апсолутни, canonical и доступни?
• Да ли је рендерована продукциона страница иста страница коју сте тестирали?
• Да ли су дуплирани ентитети намерни и без конфликта?

Ако на ова питања можете да одговорите потврдно, урадили сте трајни део посла са структурираним подацима. Тестирање специфично за претраживаче и даље може бити корисно касније, али треба да буде завршна провера компатибилности, а не основа вашег процеса валидације.