Screpy-এর স্ট্রাকচার্ড ডেটা যাচাইকারী একটি সর্বজনীন পৃষ্ঠা বা পেস্ট করা কোডের JSON-LD পরীক্ষা করে। এটি পার্সিং ত্রুটি শনাক্ত করে, ঘোষিত সত্তা দেখায় এবং পাঁচটি সমর্থিত স্কিমা ধরনের নির্বাচিত বৈশিষ্ট্যের সমস্যা জানায়। কোনটি ঠিক করতে হবে আর কোনটির আরও বিস্তৃত পরীক্ষা দরকার, তা বুঝতে রিপোর্ট ব্যবহার করুন। বৈধ সিনট্যাক্স, সমর্থিত পরীক্ষা এবং Google-এর সমৃদ্ধ ফলের যোগ্যতা আলাদা বিষয়; এখানে সবুজ অবস্থা তিনটিরই উত্তর দেয় না।
পৃষ্ঠা URL বা পেস্ট করা JSON-LD বেছে নিন
প্রকাশিত পৃষ্ঠা, যেমন পণ্যের বিস্তারিত পৃষ্ঠা বা ব্যবসার যোগাযোগের পৃষ্ঠা পরীক্ষা করতে পৃষ্ঠার URL বেছে নিন। স্বাভাবিকভাবে শুধু হোমপেজ না দিয়ে নির্দিষ্ট পৃষ্ঠার সর্বজনীন HTTP বা HTTPS ঠিকানা দিন: ভিন্ন টেমপ্লেটে ভিন্ন মার্কআপ থাকতে পারে। URL মোড পৃষ্ঠা থেকে ফেরত আসা HTML পড়ে। ব্যক্তিগত বা পাসওয়ার্ড-সুরক্ষিত পৃষ্ঠা একই সর্বজনীন প্রমাণ দেয় না, আর পৃষ্ঠা আনতে ব্যর্থ হওয়া মানেই তার স্ট্রাকচার্ড ডেটা নষ্ট নয়।
খসড়া, আলাদা করে নেওয়া স্ক্রিপ্ট বা আপনার কাছে থাকা HTML দেখতে কোড পেস্ট করুন বেছে নিন। শুধু JSON দেওয়ার জন্য JSON-LD বাছুন, চারপাশে <script> উপাদান দেবেন না। ইনপুটে <script type="application/ld+json"> ব্লক থাকলে HTML বাছুন। আলাদা JSON ফাইলের ঠিকানা HTML পৃষ্ঠা নয়; তার বিষয়বস্তু JSON-LD মোডে পেস্ট করুন। পেস্ট করা ইনপুটের সীমা UTF-8 বাইট হিসেবে ২৫৬ KiB, তাই অনুমোদিত অক্ষরের সংখ্যা লেখার ওপর নির্ভর করে।
URL পরীক্ষা JavaScript চালায় না। পৃষ্ঠা লোড হওয়ার পরে যোগ হওয়া মার্কআপ আনা উৎসে অনুপস্থিত থাকতে পারে। Google গতিশীলভাবে যোগ করা JSON-LD প্রক্রিয়া করতে পারে, তাই এই রিপোর্টে ব্লক না থাকা মানেই Google সেটি দেখে না, এমন নয়। এই পার্থক্য গুরুত্বপূর্ণ হলে সংশ্লিষ্ট রেন্ডার করা মার্কআপ দেখুন বা Google-এর ফিচার পরীক্ষা ব্যবহার করুন। পেস্ট করা কোডে কেবল আপনার দেওয়া ইনপুট পরীক্ষা হয়; সরাসরি প্রকাশিত পৃষ্ঠা কী পাঠায়, তা প্রমাণ হয় না।
স্ট্রাকচার্ড ডেটা রিপোর্ট পড়ুন
প্রথমে পরীক্ষার পরিধি দেখুন, তারপর পর্যবেক্ষণ ও সত্তার টেবিল পড়ুন। JSON-LD ব্লক HTML-এ শনাক্ত করা স্ক্রিপ্টের সংখ্যা দেখায়; পেস্ট করা JSON-LD একটি ব্লক হিসেবে ধরা হয়। সত্তা সফলভাবে পার্স করা JSON-এর সংরক্ষিত, ঘোষিত ধরনযুক্ত অবজেক্টের সংখ্যা দেখায়; একটি স্ক্রিপ্টে একাধিক সত্তা থাকতে পারে। সিনট্যাক্স ত্রুটি প্রক্রিয়া করা যেসব ব্লক পার্স করা যায়নি, সেগুলো গোনে। এগুলো আলাদা সংখ্যা, তাই তিনটি ব্লকের পৃষ্ঠায় তিনটি সত্তা থাকতেই হবে না। আংশিক রিপোর্টে শনাক্ত ব্লকের সংখ্যা সব ব্লক পরীক্ষা হওয়ার প্রমাণ নয়।
প্রতিটি সারি সিনট্যাক্স ও পরিধি আলাদা করে দেখায়। সবুজ বৈধ সিনট্যাক্স মানে JSON পার্সার ব্লকটি গ্রহণ করেছে। সবুজ সমর্থিত পরীক্ষা মানে সত্তাটি এই টুলের নির্বাচিত বৈশিষ্ট্যের পরীক্ষার শর্ত পূরণ করেছে। পর্যবেক্ষণও পড়ুন: কোনো অবস্থাই সব বৈশিষ্ট্য সঠিক হওয়া প্রমাণ করে না। লাল পার্সিং ত্রুটি বা ত্রুটি-স্তরের পর্যবেক্ষণ, হলুদ সতর্কতা ও আংশিক পরীক্ষা, আর ধূসর অসমর্থিত বা অনুপলব্ধ প্রমাণ বোঝায়। রঙের পাশাপাশি লেখা অবস্থাটিও পড়ুন।
পথ কলাম ভেতরের অবজেক্ট খুঁজতে সাহায্য করে। যেমন $.author মূল অবজেক্টের ভেতরের লেখকের অবজেক্ট দেখায়, আর $.@graph[1] একটি @graph অ্যারের দ্বিতীয় অবজেক্ট দেখায়। পথ সংশ্লিষ্ট JSON-LD ব্লকের সাপেক্ষে দেওয়া হয়, তাই একাধিক স্ক্রিপ্টে একই পথ থাকতে পারে। ডাউনলোড করা JSON-এ তাদের আলাদা করার জন্য ব্লক নম্বর থাকে।
নাম কলাম name পড়ে, প্রতিটি ধরনের প্রদর্শনযোগ্য নামের বৈশিষ্ট্য নয়। তাই বৈধ headline থাকা Article-এর নামের ঘর খালি থাকতে পারে। এটিকে বিষয়বস্তুর ত্রুটি বলার আগে প্রাসঙ্গিক বৈশিষ্ট্য ও পর্যবেক্ষণ দেখুন।
বৈশিষ্ট্যের সতর্কতার আগে JSON সিনট্যাক্স ঠিক করুন
অবৈধ ব্লক থেকে সত্তা সম্পর্কে নির্ভরযোগ্য পর্যবেক্ষণ পাওয়া যায় না। আগে JSON সারান, তারপর অনুপস্থিত বৈশিষ্ট্যের সতর্কতা ব্যাখ্যা করার আগে আবার পরীক্ষা করুন। সাধারণ কারণ হলো নাম বা লেখার চারপাশে একক উদ্ধৃতি, শেষ বৈশিষ্ট্যের পরে বাড়তি কমা, বন্ধ করার ব্র্যাকেট না থাকা এবং লেখার মধ্যে এস্কেপ না করা উদ্ধৃতিচিহ্ন। JSON-এ দ্বৈত উদ্ধৃতির স্ট্রিং এবং সদস্যের মাঝে কমা থাকে; RFC 8259 এর ব্যাকরণ নির্ধারণ করে।
এই কাল্পনিক Organization হলো কোড পেস্ট করুন → JSON-LD-এর ন্যূনতম সিনট্যাক্স উদাহরণ:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Example Studio",
"url": "https://example.com/"
}
উদাহরণে Organization-এর জন্য এই যাচাইকারী যে দুটি বৈশিষ্ট্য খোঁজে, সেগুলো রয়েছে। এটি Google-এর কোনো সার্চ ফিচারের সম্পূর্ণ টেমপ্লেট নয়। কাল্পনিক মানের বদলে পৃষ্ঠার সত্য তথ্য দিন এবং প্রকাশের আগে প্রাসঙ্গিক ফিচারের শর্ত দেখুন।
শুধু বৈধ JSON হলেই ব্যবহারযোগ্য স্ট্রাকচার্ড ডেটা হয় না। আলাদা স্ট্রিং বা সংখ্যা বৈধ JSON হতে পারে, কিন্তু প্রত্যাশিত সত্তা বর্ণনা করতে পারে না; এই টুল জানায় যে মূলে অবজেক্ট বা অ্যারে দরকার। একইভাবে ঘোষিত @type ছাড়া পার্স করা অবজেক্ট থেকে কোনো সত্তার সারি নাও আসতে পারে। কেবল রিপোর্টের বার্তা সরাতে বৈশিষ্ট্য যোগ করার আগে আসল কাঠামো পরীক্ষা করুন।
স্কিমার কোন বৈশিষ্ট্য পরীক্ষা করা হয়?
স্ট্রাকচার্ড ডেটা যাচাইকারী কনটেক্সট চিনতে পারলে নির্দিষ্ট পাঁচটি ধরনের ওপর নির্বাচিত পরীক্ষা চালায়। পর্যবেক্ষণ বোঝার জন্য এই টেবিল ব্যবহার করুন; এটি Schema.org-এর সব বৈশিষ্ট্য বা Google-এর প্রয়োজনীয় সব ক্ষেত্রের তালিকা নয়।
| ঘোষিত ধরন | এই যাচাইকারী কী পরীক্ষা করে | পর্যবেক্ষণ কীভাবে ব্যবহার করবেন |
|---|---|---|
Organization |
name ও url-এর উপস্থিতি |
সেগুলো আসল প্রতিষ্ঠান ও তার সঠিক ওয়েবসাইট বর্ণনা করছে কি না দেখুন। |
LocalBusiness |
name ও address-এর উপস্থিতি |
আসল ব্যবসার পরিচয় ও ঠিকানা দেখুন; ঠিকানার উপাদান পুরোপুরি যাচাই হয় না। |
Article |
headline, author, datePublished ও image-এর উপস্থিতি |
মানগুলো নিবন্ধের সঙ্গে মিলিয়ে দেখুন এবং ফরম্যাট আলাদা করে পরীক্ষা করুন। |
Product |
name-এর উপস্থিতি; offers, review বা aggregateRating-এর কোনোটি দেওয়া আছে কি না |
শুধু সত্য ও প্রযোজ্য পণ্যের তথ্য দিন। সতর্কতা সরাতে অফার বা পর্যালোচনা বানাবেন না। |
BreadcrumbList |
খালি নয় এমন itemListElement অ্যারে; পরীক্ষিত প্রতিটি আইটেমের ধনাত্মক পূর্ণসংখ্যা position ও খালি নয় এমন লেখা name |
নির্দেশিত আইটেম ঠিক করুন, তারপর সম্পূর্ণ নেভিগেশন পথ ও গন্তব্য URL আলাদা করে দেখুন। |
বেশিরভাগই উপস্থিতির পরীক্ষা। কোনো মান থাকতে পারে, অথচ তার URL, তারিখ, ছবি, অবজেক্টের কাঠামো বা তথ্য ভুল হতে পারে। খালি অবজেক্ট উপস্থিতির পরীক্ষা পাস করতে পারে, আর শুধু ফাঁকা স্থানযুক্ত মান সব পরীক্ষায় বাদ পড়ে না। তাই সমর্থিত অবস্থা ঠিকানা, লেখক বা অফার সম্পূর্ণ হওয়া নিশ্চিত করে না।
ব্রেডক্রাম্ব পরীক্ষা নির্বাচিত আইটেমের মানও দেখে, তবে ক্রমিক বা অনন্য অবস্থান, সঠিক item URL কিংবা সম্পূর্ণ ListItem অর্থগত নিয়ম নিশ্চিত করে না। রিপোর্ট প্রতিটি সত্তার জন্য সর্বোচ্চ ১০০টি বৈশিষ্ট্য-সংক্রান্ত পর্যবেক্ষণ রাখে। দীর্ঘ নেভিগেশন পথ বা বারবার ত্রুটিযুক্ত সত্তার আরও পরীক্ষা লাগতে পারে।
পৃষ্ঠার প্রেক্ষাপটে পর্যবেক্ষণ ঠিক করুন। নিবন্ধের লেখক মানুষ হলে, ভেতরের Person এই যাচাইকারীর আওতার বাইরে দেখালেও সঠিক লেখকের কাঠামো রাখুন। শুধু সবুজ অবস্থা পাওয়ার জন্য সত্য মার্কআপ বদলালে আসল সমস্যা সমাধানের বদলে চাপা পড়তে পারে।
বৈধ মার্কআপ কেন অসমর্থিত বা আংশিক দেখায়?
অসমর্থিত মানে টুল ওই সত্তার নির্বাচিত বৈশিষ্ট্যের পরীক্ষা করেনি। এর মানে এই নয় যে Schema.org ওই ধরন নিষিদ্ধ করেছে। যেমন সমর্থিত Article-এর ভেতরে Person লেখক থাকতে পারে। Article নির্বাচিত পরীক্ষা পায়, কিন্তু Person অসমর্থিত দেখায়, তাই পরীক্ষার পরিধি আংশিক হয়। Restaurant আরও নির্দিষ্ট ব্যবসার ধরন হলেও সমর্থিত পাঁচটি নির্দিষ্ট ধরনের বাইরে। বিষয়কে সঠিকভাবে বর্ণনা করা ধরন রাখুন এবং বাকি পরীক্ষার জন্য আরও বিস্তৃত যাচাইকারী ব্যবহার করুন।
কনটেক্সটের কারণেও একই পার্থক্য হতে পারে। এই যাচাইকারী সরল http://schema.org বা https://schema.org কনটেক্সট চেনে, শেষে স্ল্যাশ থাকুক বা না থাকুক, এমনকি ওপরের অবজেক্ট থেকে উত্তরাধিকারসূত্রে পাওয়া কনটেক্সটও। অবজেক্ট বা অ্যারে কনটেক্সট এটি সমাধান করে না। W3C-এর JSON-LD কনটেক্সট নির্দেশনা অনুযায়ী এমন রূপ বৈধ হতে পারে। কোনো সত্তায় একাধিক ধরন ঘোষিত হলে বৈশিষ্ট্যের পরীক্ষা চালাতে সবগুলো সমর্থিত সেটে থাকতে হবে।
পরীক্ষার পরিধিও সীমিত। যাচাইকারী প্রথম ৫০টি JSON-LD ব্লক বিবেচনা করে এবং অবৈধ ব্লকের সারিসহ সর্বোচ্চ ৫০০টি ফলের সারি রাখে। ৩২টির বেশি নেস্টিং স্তর বা প্রতি ব্লকে ১০,০০০টি পরিদর্শিত মানের পরে কাঠামো অনুসরণ থামে। ফলে পরের সত্তা পরীক্ষা না-ও হতে পারে। HTML-এ Microdata বা RDFa ধরা পড়লেও রিপোর্ট আংশিক হয়, কারণ এখানে এসব ফরম্যাট যাচাই করা হয় না।
বড় পেস্ট করা ইনপুটের সম্পূর্ণ JSON-LD ব্লক আলাদা আলাদা পরীক্ষায় দিন। মাঝখানে অবজেক্ট কেটে নতুন সিনট্যাক্স ত্রুটি তৈরি করবেন না। মূল উৎস রাখুন এবং কোন রিপোর্ট কোন অংশ পরীক্ষা করেছে, তা চিহ্নিত করুন। এসব আলাদা পরীক্ষা নিজে থেকে সম্পূর্ণ পৃষ্ঠা অডিটে একত্রিত হয় না।
মার্কআপ ঠিক করার পরে পৃষ্ঠা যাচাই করুন
আগে মার্কআপের তথ্য দর্শক পৃষ্ঠায় যা পড়তে পারেন, তার সঙ্গে মেলান। পরিচয়, তারিখ, ঠিকানা, পণ্যের তথ্য ও পর্যালোচনা আসল বিষয়বস্তু দিয়ে যাচাই করুন। Google-এর স্ট্রাকচার্ড ডেটা নীতিমালা প্রাসঙ্গিক, সঠিক তথ্য এবং প্রযোজ্য ফিচারের শর্ত পূরণ চায়; পার্সার এসব তথ্য নিশ্চিত করতে পারে না। বৈশিষ্ট্যের সতর্কতা সরাতে বানানো তথ্য যোগ করবেন না।
অমীমাংসিত প্রশ্ন অনুযায়ী পরের পরীক্ষা বেছে নিন। Microdata ও RDFa-সহ আরও বিস্তৃত Schema.org মার্কআপ পরীক্ষা করতে Schema.org Markup Validator ব্যবহার করুন। এরও সীমা আছে: অন্য কনটেক্সট URL এনে ব্যাখ্যা করে না। সমর্থিত Google সার্চ ফিচার ও তাদের ত্রুটি বা সতর্কতা দেখতে Google-এর Rich Results Test ব্যবহার করুন। পরীক্ষা পাস করলেই Google সমৃদ্ধ ফল দেখাবে, তার নিশ্চয়তা নেই।
ব্যবসার মার্কআপ তৈরি করলে স্থানীয় ব্যবসার Schema জেনারেটর আসল তথ্য থেকে JSON-LD তৈরি করতে পারে। প্রকাশের আগে ফল দেখুন। নির্দিষ্ট ব্যবসার ধরন এবং ভেতরের PostalAddress অবজেক্ট এই যাচাইকারীতে অসমর্থিত থাকতে পারে; তৈরি করা ও নির্বাচিত যাচাই আলাদা কাজ।
সংশোধন প্রয়োগের পরে শুধু খসড়ায় নয়, প্রকাশিত পৃষ্ঠায় প্রাসঙ্গিক পরীক্ষা আবার চালান। পাঠানো মার্কআপে কাঙ্ক্ষিত পরিবর্তন আছে কি না নিশ্চিত করুন এবং বাকি পর্যবেক্ষণ তুলনা করুন। ওই পরীক্ষার ব্লক নম্বর, সত্তার পথ, পর্যবেক্ষণ ও পরিধি রাখতে JSON ডাউনলোড করুন ব্যবহার করুন। রপ্তানি করা রিপোর্টের সঙ্গে ইনপুট ও আওতা রাখুন, যাতে আরেকজন পর্যালোচক প্রমাণ বুঝতে পারেন। সংরক্ষিত রিপোর্ট একটি পরীক্ষার রেকর্ড; ভবিষ্যৎ টেমপ্লেট বা বিষয়বস্তুর পরিবর্তন নিরবচ্ছিন্নভাবে পর্যবেক্ষণ করে না।