Google টুল ছাড়া স্ট্রাকচার্ড ডেটা কীভাবে ভ্যালিডেট করবেন

Structured data validation অদ্ভুতভাবে Google-কেন্দ্রিক টুলের ওপর নির্ভরশীল হয়ে পড়েছে। এটি বোঝা যায়: অনেক টিম JSON-LD যোগ করে কারণ তারা rich results চায়, এবং Google-এর testing tools পরিচিত। কিন্তু structured data কোনো Google format নয়। এটি সাধারণত Schema.org vocabulary ব্যবহার করা JSON-LD, HTML-এর মধ্যে embedded থাকে, অনেক consumer এটি interpret করে, এবং আপনার নিজের publishing workflow এটি maintain করে।

আপনি যদি শুধু search-engine lens দিয়ে validate করেন, তাহলে মৌলিক সমস্যাগুলো চোখ এড়িয়ে যেতে পারে: invalid JSON, rendering-এর পরে হারিয়ে যাওয়া data, পুরনো product price, conflicting canonical URL, অথবা technically valid হলেও semantically অযৌক্তিক markup।

আরও ভালো workflow হলো standards-first। data-কে data হিসেবে validate করুন, তারপর vocabulary validate করুন, তারপর page-টি production-এ যেমন আছে সেভাবে validate করুন।

আপনি আসলে কী validate করছেন?

“Structured data” একক কোনো জিনিস নয়। অধিকাংশ website-এ এর চারটি layer থাকে:

1. JSON syntax — code কি parse করা যায়?
2. JSON-LD model — এটি কি meaningful linked data-তে expand হয়?
3. Schema.org vocabulary — types এবং properties কি plausible?
4. Page-level truth — markup কি users এবং crawlers যা দেখতে পারে তার সঙ্গে মেলে?

Google tools মূলত চতুর্থ layer এবং Google-specific rich-result eligibility-তে focus করে। উপকারী, হ্যাঁ। সম্পূর্ণ, না।

উদাহরণস্বরূপ, এটি valid JSON-LD হতে পারে, তবু poor structured data হতে পারে:

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

এখানে ভাঙা কিছু নেই। কিন্তু visible page-এ যদি আলাদা headline থাকে, author attribution না থাকে, এবং last-modified date markup-এর সঙ্গে বিরোধ তৈরি করে, তাহলে আপনার সমস্যা syntax নয়, quality।

Step 1: SEO ভাবার আগে JSON parse করুন

নীরস check দিয়ে শুরু করুন: JSON কি parse করা যায়?

HTML-এ embedded JSON-LD প্রায়ই ছোট template ভুলের কারণে ভেঙে যায়:

• trailing commas
• product name-এ unescaped quotes
• string-এর মধ্যে invalid line breaks
• conditional fields-এর পরে missing braces
• layout inheritance থেকে duplicate script blocks
• partial objects output করা CMS plugins

Local checks-এর জন্য আপনার কোনো SEO platform দরকার নেই। আপনার development stack-এ ইতিমধ্যেই থাকা tools ব্যবহার করুন।

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-তে, rendered HTML থেকে script contents extract করুন এবং JSON হিসেবে parse করুন। এতে production-এ পৌঁছানোর আগেই অনেক সমস্যা ধরা পড়ে।

গুরুত্বপূর্ণ বিষয়: কোনো Schema.org validation-এর আগে এটি করুন। data valid JSON না হলে vocabulary validator সাহায্য করতে পারবে না।

Step 2: শুধু JSON syntax নয়, JSON-LD behaviour check করুন

Valid JSON স্বয়ংক্রিয়ভাবে valid JSON-LD নয়। JSON-LD @context, @type, @id, এবং graph relationships-এর মতো concept ব্যবহার করে। এগুলো malformed হলে parsers আপনার data-কে আপনার intended meaning থেকে ভিন্নভাবে interpret করতে পারে।

কমপক্ষে নিশ্চিত করুন:

• প্রতিটি block-এ appropriate @context আছে
• primary entities-এ clear @type values আছে
• repeated entities যেখানে উপযোগী, সেখানে stable @id values ব্যবহার করছে
• nested entities logically connected
• multiple values possible হলে arrays ব্যবহার করা হয়েছে

বড় site-এর জন্য stable identifiers বিশেষভাবে সহায়ক। আপনার organization যদি Article, Product, BreadcrumbList, এবং FAQPage data-তে দেখা যায়, একই @id ব্যবহার করলে consumers বুঝতে পারে এগুলো একই entity-র reference, একই নামে চারটি unrelated organization নয়।

একটি typical pattern এমন দেখায়:

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

এখানে আপনার লক্ষ্য কোনো validator-কে impress করা নয়। আপনি আপনার data-কে কম ambiguous করছেন।

Step 3: Schema.org vocabulary অনুযায়ী validate করুন

JSON এবং JSON-LD structure sound হলে, vocabulary check করুন।

Schema.org validator উপকারী, কারণ এটি কোনো একটি search engine-এর rich-result rules নয়, Schema.org terms অনুযায়ী test করে। এটি দেখাতে পারে properties recognized কি না, types expected ভাবে interpreted হচ্ছে কি না, এবং আপনার nested structures অর্থবহ কি না।

এখানেই আপনি এমন ভুল ধরবেন:

• datePublished-এর বদলে publishingDate
• যেখানে image expected, সেখানে imageUrl
• product নয় এমন category listing-এ Product markup
• meaningful reviewed item ছাড়া AggregateRating
• brand account-এর জন্য Person ব্যবহার

Warnings নিয়ে সতর্ক থাকুন। Schema.org ইচ্ছাকৃতভাবে flexible। কোনো validator এমন property allow করতে পারে যা আপনার use case-এ দরকারি নয়, অথবা optional বিষয়ে warning দিতে পারে। validation-কে evidence হিসেবে নিন, verdict হিসেবে নয়।

একটি practical rule: কোনো property যদি machine-কে page আরও accurately বুঝতে সাহায্য করে, রাখুন। যদি সেটি শুধু কেউ snippet generator থেকে copy করেছে বলে থাকে, প্রশ্ন তুলুন।

Step 4: Markup visible content-এর সঙ্গে compare করুন

Search engines এবং অন্যান্য data consumers সাধারণত page-এর সঙ্গে না মেলা markup-কে distrust করে। আরও গুরুত্বপূর্ণ হলো, users consistency পাওয়ার যোগ্য।

প্রতিটি structured data type-এর জন্য, markup visible page-এর সঙ্গে compare করুন:

Article and BlogPosting

Headline, author, published date, modified date, image, এবং publisher visible বা reasonably inferable কি না check করুন। আপনি যদি AI-assisted content publish করেন, unclear authorship ঢাকার জন্য structured data ব্যবহার করা উচিত নয়। আমরা ছোট website-এ honest AI disclosure কেমন হওয়া উচিত নিয়ে আলাদাভাবে লিখেছি, এবং একই principle এখানেও প্রযোজ্য: metadata স্পষ্ট করবে, অস্পষ্ট করবে না।

Product

Name, price, availability, currency, variants, ratings, এবং review counts check করুন। Product structured data বিশেষভাবে stale হয়ে পড়ে, কারণ prices এবং stock status CMS-এর বাইরে change হয়।

LocalBusiness

Name, address, phone number, opening hours, এবং service area check করুন। আপনার footer যদি এক কথা বলে আর JSON-LD আরেক কথা বলে, তাহলে JSON-LD “better” নয়। এটি contradictory।

BreadcrumbList

Breadcrumb positions visible breadcrumb trail-এর সঙ্গে মেলে কি না এবং URLs canonical, crawlable, ও অপ্রয়োজনীয়ভাবে redirected নয় কি না check করুন।

এই কাজ glamorous নয়। structured data problems-এর অনেকগুলো এখানেই পাওয়া যায়।

Step 5: Template নয়, rendered page validate করুন

অনেক site JavaScript, tag managers, personalization layers, অথবা component hydration-এর মাধ্যমে JSON-LD generate করে। এর অর্থ template file একটি crawler বা browser আসলে যা দেখে তা represent নাও করতে পারে।

কমপক্ষে তিনটি state-এ rendered HTML validate করুন:

• local development build
• staging or preview URL
• production URL

Final DOM inspect করতে browser DevTools ব্যবহার করুন। application/ld+json search করুন এবং rendering-এর পরে যে exact script content থাকে সেটি copy করুন। server-rendered markup যদি hydrated markup থেকে আলাদা হয়, তাহলে consumers কোন version পড়বে বলে আপনি expect করছেন তা ঠিক করুন।

Structured data duplicated হচ্ছে কি না তাও check করুন। Duplicate Article বা Product blocks common, যখন একটি CMS plugin এবং একটি custom component দুটিই schema emit করে। Duplication সব সময় fatal নয়, কিন্তু conflicting duplication সমস্যা: দুটি price, দুটি author, দুটি publication date, অথবা দুটি canonical URL।

এটি performance এবং diagnostics reports পড়ার মতো: প্রথম কাজ panic করা নয়, বরং signal ও noise আলাদা করা। Lighthouse report panic ছাড়া পড়ার সময় একই অভ্যাস কাজে লাগে — যদিও structured data নিজেকে কোনো single score-এ নামিয়ে আনা উচিত নয়।

Step 6: Production transport details check করুন

Structured data আপনার source-এ perfect হতে পারে, তবু production-এ fail করতে পারে, কারণ page আপনার অনুমান করা 방식ে accessible নয়।

Check করুন:

• final status code 200, soft 404 নয়
• canonical URL আপনি যে page validate করছেন তার সঙ্গে মেলে
• redirects intentional এবং stable
• indexing expected হলে robots directives indexing block করছে না
• কিছু user agent-এর জন্য HTML error page দিয়ে replace হচ্ছে না
• cached pages stale JSON-LD serve করছে না

এখানেই HTTP inspection গুরুত্বপূর্ণ। কোনো product page যদি canonical destination-এ পৌঁছানোর আগে তিনটি URL দিয়ে redirect হয়, তাহলে CMS থেকে copy করা প্রথম URL নয়, final page validate করুন। raw mechanics-এর জন্য, আমাদের production-এ redirects এবং HTTP headers debug করার small toolkit guide একটি useful companion।

Structured data vacuum-এ থাকে না। এটি headers, redirects, caching, canonical tags, এবং robots directives-এর সঙ্গে ভ্রমণ করে।

Step 7: Release process-এ structured data tests যোগ করুন

Manual validation এক page-এর জন্য ঠিক আছে। শত বা হাজার URL জুড়ে এটি scale করে না।

একটি simple automated test suite সবচেয়ে expensive ভুলগুলো ধরতে পারে:

• প্রতিটি template type থেকে representative URLs fetch করুন
• সব JSON-LD blocks extract করুন
• JSON.parse দিয়ে parse করুন
• প্রতিটি page type-এর জন্য required fields assert করুন
• dates valid ISO 8601 strings কি না check করুন
• URLs absolute এবং canonical কি না check করুন
• product pages-এর জন্য prices এবং availability আছে কি না check করুন
• duplicate entities conflict করছে কি না check করুন

Templates-এর জন্য CI-তে এবং production URLs-এর জন্য schedule অনুযায়ী এটি run করতে পারেন। লক্ষ্য হলো প্রতিটি rich-result feature appear করবে তা prove করা নয়। search engine-এর বাইরে কেউ সেটি promise করতে পারে না। লক্ষ্য হলো আপনার নিজস্ব data accurate, parseable, এবং consistent রাখা।

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

💡 এটি চেষ্টা করুন: স্কিমার লজিক যাচাই করার আগে, আপনার JSON-LD JSON Formatter দিয়ে চালিয়ে নিন, যাতে এমন সিনট্যাক্স ত্রুটি ধরা পড়ে যা নইলে পরবর্তী প্রতিটি যাচাই ভেঙে দিত।

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

একটি standards-first validation checklist

Search engine page-টি পছন্দ করে কি না জিজ্ঞেস করার আগে এই short checklist ব্যবহার করুন:

• প্রতিটি JSON-LD block কি valid JSON?
• প্রতিটি block-এ কি correct @context এবং @type আছে?
• Schema.org properties কি correctly spelled?
• Markup কি visible content-এর সঙ্গে মেলে?
• Dates, prices, ratings, এবং availability কি current?
• URLs কি absolute, canonical, এবং reachable?
• Rendered production page কি আপনি যে page test করেছেন একই page?
• Duplicate entities কি intentional এবং non-conflicting?

এই প্রশ্নগুলোর উত্তর যদি yes হয়, তাহলে structured data কাজের durable অংশ আপনি সম্পন্ন করেছেন। Search-specific testing পরে এখনও useful হতে পারে, কিন্তু সেটি আপনার validation process-এর foundation নয়, final compatibility check হওয়া উচিত।