যে schema.org টাইপগুলো সত্যিই সার্চ ফলাফলকে প্রভাবিত করে
যে structured data আপনার পেজ সার্চে কীভাবে দেখা যাবে তা বদলাতে পারে—এবং যে markup মূলত মেশিনকে আপনাকে বুঝতে সাহায্য করে—তার একটি ব্যবহারিক গাইড।
সুচিপত্র
- সংক্ষিপ্ত উত্তর
- প্রথমে: structured data হলো eligibility, entitlement নয়
- সবচেয়ে স্পষ্ট প্রভাব ফেলে যে types
- Product, Offer, AggregateRating, এবং Review
- BreadcrumbList
- Article, NewsArticle, এবং BlogPosting
- LocalBusiness এবং এর subtypes
- Event
- JobPosting
- Recipe
- VideoObject
- Organization, Logo, এবং WebSite
- FAQPage: technically supported, কিন্তু বেশিরভাগ site-এর জন্য খুব কমই দৃশ্যমান
- DiscussionForumPosting এবং ProfilePage
- উপকারী কিন্তু প্রায়ই অতিমূল্যায়িত types
- JSON-LD সাধারণত সেরা implementation format
- একটি ব্যবহারিক prioritization model
- সাধারণ mistakes যা impact কমায়
- ভুল page type mark up করা
- দৃশ্যমান নয় এমন properties যোগ করা
- Validation-কে success হিসেবে ধরা
- একবার schema implement করে ভুলে যাওয়া
- শান্ত সুপারিশ
সংক্ষিপ্ত উত্তর
Schema.org markup স্বয়ংক্রিয়ভাবে rankings উন্নত করে না। তবে এটি একটি পেজকে উন্নত সার্চ উপস্থিতির জন্য যোগ্য করতে পারে: rich results, product panels, breadcrumbs, event listings, job modules, video previews, এবং অনুরূপ features।
এই পার্থক্যটি গুরুত্বপূর্ণ। Schema.org হলো ওয়েবে জিনিসপত্র বর্ণনা করার জন্য একটি বিস্তৃত vocabulary। Search engines এর কেবল একটি subset সমর্থন করে, এবং প্রতিটি search feature-এর নিজস্ব নিয়ম আছে। আপনি Thing, CreativeWork, বা Service দিয়ে একটি পেজ নিখুঁতভাবে mark up করতে পারেন, তবুও search results-এ কোনো দৃশ্যমান পরিবর্তন নাও দেখতে পারেন, কারণ ওই type-এর সঙ্গে যুক্ত কোনো search feature নাও থাকতে পারে।
তাই কার্যকর প্রশ্নটি “কোন schema types আছে?” নয়। বরং “কোন schema types search engines দৃশ্যমান বা operational search features তৈরি করতে ব্যবহার করে?”
নিচে ব্যবহারিক উত্তরটি দেওয়া হলো।
প্রথমে: structured data হলো eligibility, entitlement নয়
Structured data search engines-কে স্পষ্ট clues দেয়। এটি তাদের কিছু প্রদর্শন করতে বাধ্য করে না।
Structured data-এর কোনো দৃশ্যমান প্রভাব পড়ার আগে একটি পেজের সাধারণত নিচের সবগুলোই প্রয়োজন হয়:
- Markup-টি দৃশ্যমান page content-এর সঙ্গে মিলতে হবে।
- Required এবং recommended properties উপস্থিত থাকতে হবে।
- পেজটি indexable হতে হবে এবং robots rules দ্বারা blocked হওয়া যাবে না।
- Content-কে quality এবং spam policies পূরণ করতে হবে।
- Search engine-কে সিদ্ধান্ত নিতে হবে যে enhanced result ব্যবহারকারীকে সাহায্য করে।
এ কারণেই একইভাবে technically valid দুটি পেজ search-এ ভিন্নভাবে আচরণ করতে পারে। একটি product rich result পেতে পারে; অন্যটি plain blue link হিসেবে দেখাতে পারে। Markup কেবল একটি input।
এ কারণেই obscure schema types-এর পেছনে ছোটা সাধারণত সময়ের দুর্বল ব্যবহার। যদি type-এর সঙ্গে কোনো supported search feature যুক্ত না থাকে, সুবিধাটি দৃশ্যমানের চেয়ে বেশিরভাগই semantic।
সবচেয়ে স্পষ্ট প্রভাব ফেলে যে types
Product, Offer, AggregateRating, এবং Review
Ecommerce এবং software pages-এর জন্য product markup হলো সবচেয়ে দৃশ্যমানভাবে উপকারী structured data families-এর একটি।
একটি Product page price, availability, rating, shipping, return, এবং merchant listing features-এর জন্য eligible হতে পারে। সবচেয়ে গুরুত্বপূর্ণ supporting types সাধারণত হলো:
- Price, currency, availability, এবং seller information-এর জন্য
Offer - Summarized ratings-এর জন্য
AggregateRating - Individual reviews-এর জন্য
Review, যেখানে উপযুক্ত - Manufacturer বা seller context-এর জন্য
BrandবাOrganization
এই markup সবচেয়ে উপকারী যখন পেজটি সত্যিই একটি নির্দিষ্ট product নিয়ে, কোনো category বা অস্পষ্ট service page নয়। Search engines review এবং rating abuse সম্পর্কে ক্রমেই কঠোর হচ্ছে, বিশেষ করে self-serving reviews-এর ক্ষেত্রে। Rating যদি পেজে ব্যবহারকারীদের কাছে দৃশ্যমান না হয়, সেটি mark up করবেন না।
Product schema classic organic snippets এবং merchant-style surfaces—উভয়কেই প্রভাবিত করতে পারে। Retailers-এর জন্য, এটি প্রায়ই সবচেয়ে বেশি return দেওয়া structured data implementations-এর একটি।
BreadcrumbList
BreadcrumbList আকর্ষণীয় নাও হতে পারে, কিন্তু এটি ব্যবহারিক। এটি search results-এ URL/path display প্রভাবিত করতে পারে, একটি এলোমেলো URL-এর জায়গায় পরিষ্কার hierarchy দেখাতে পারে।
Breadcrumb markup উপকারী:
- Ecommerce category এবং product pages
- Documentation sites
- বড় blogs এবং publications
- SaaS help centers
এটি খুব কমই নাটকীয় rich result তৈরি করে, কিন্তু comprehension উন্নত করতে পারে। Users ক্লিক করার আগেই দেখতে পারেন পেজটি কোথায় অবস্থান করছে। Search engines-ও site structure-এর একটি পরিষ্কার ধারণা পায়।
আপনার site-এ deep navigation থাকলে, breadcrumb markup শুরুতেই করা মূল্যবান।
Article, NewsArticle, এবং BlogPosting
Article, NewsArticle, এবং BlogPosting search engines-কে headline, author, date, image, এবং publisher information বুঝতে সাহায্য করতে পারে। Publishers-এর ক্ষেত্রে, এটি article-oriented features-এর eligibility-কে প্রভাবিত করতে পারে, বিশেষ করে strong crawlability, freshness, এবং content quality-এর সঙ্গে মিললে।
Article schema কোনো সাধারণ blog post-কে news result-এ পরিণত করবে—এমন আশা করবেন না। এটি দুর্বল reporting, missing author information, বা thin content-এর ক্ষতিপূরণ করবে না।
তবুও, editorial sites-এর জন্য article markup যুক্তিযুক্ত। Basic facts অস্পষ্টতা ছাড়া জানাতে এটি ব্যবহার করুন:
- Headline
- Author বা organization
- Date published এবং date modified
- Main image
- Publisher
- Canonical URL
আপনার team যদি AI-assisted publishing ব্যবহার করে, structured data disclosure বা editorial accountability-এর বিকল্প নয়। আমরা এর মানবিক দিকটি আলোচনা করেছি একটি ছোট website-এ সৎ AI disclosure কেমন হওয়া উচিত লেখায়। Search systems আপনার markup parse করতে পারে, কিন্তু readers পেজটিকেই বিচার করে।
LocalBusiness এবং এর subtypes
Local organizations-এর জন্য, LocalBusiness এবং এর subtypes—যেমন Restaurant, Dentist, Store, বা ProfessionalService—একটি website-কে business facts-এর সঙ্গে যুক্ত করতে সাহায্য করতে পারে: name, address, phone number, opening hours, geo coordinates, এবং same-as profiles।
দৃশ্যমান প্রভাব product বা recipe markup-এর তুলনায় কম predictable, কারণ local search অনেকটাই business listings, proximity, prominence, reviews, এবং user intent-এর ওপর নির্ভর করে। তবুও, consistent local business markup দরকারি hygiene।
এটি সেই পেজে ব্যবহার করুন যা business location-কে প্রতিনিধিত্ব করে, প্রতিটি blog post-এ এলোমেলোভাবে নয়। আপনার যদি multiple locations থাকে, প্রতিটি location page-কে তার নিজস্ব address এবং opening hours দিয়ে mark up করুন।
Event
Event markup eligible pages-কে event-related search features-এ dates, locations, এবং ticket information সহ দেখাতে পারে।
এটি ভালোভাবে মানায়:
- Concerts
- Conferences
- Webinars
- Classes
- Festivals
- Community events
মূল বিষয় হলো specificity। “our annual training program” সম্পর্কে একটি পেজ start time, location, organizer, এবং attendance mode সহ dated event-এর পেজের মতো নয়।
Online events-এর জন্য virtual attendance details অন্তর্ভুক্ত করুন। Physical events-এর জন্য venue information অন্তর্ভুক্ত করুন। Cancelled, postponed, এবং rescheduled events updated রাখুন; stale event markup কোনো markup না থাকার চেয়েও খারাপ।
JobPosting
JobPosting হলো নির্দিষ্ট search experience চালিত করা structured data-এর সবচেয়ে স্পষ্ট উদাহরণগুলোর একটি। সঠিকভাবে marked job pages job search features-এর জন্য eligible হতে পারে, যার মধ্যে role, location, salary, employment type, এবং posting date থাকে।
এই markup কেবল প্রকৃত job posting pages-এ উপকারী। যেসব generic careers pages আলাদা detail pages ছাড়া multiple roles তালিকাভুক্ত করে, সেখানে এটি প্রয়োগ করবেন না।
গুরুত্বপূর্ণ fields হলো:
- Job title
- Hiring organization
- Location বা remote status
- Date posted
- Valid-through date
- Employment type
- Compensation, যেখানে পাওয়া যায়
Expired jobs সরিয়ে ফেলতে হবে, যথাযথভাবে redirect করতে হবে, অথবা আর valid নয় হিসেবে mark করতে হবে। Search engines ব্যবহারকারীদের dead openings-এ পাঠাতে পছন্দ করে না।
Recipe
Recipe markup এখনও classic rich-result cases-এর একটি। এটি image thumbnails, ratings, cooking time, ingredients, nutrition, এবং guided recipe experiences প্রভাবিত করতে পারে।
এটি structured data-এর সবচেয়ে বেশি abused areas-এরও একটি। পেজটি যদি বেশিরভাগই personal essay হয় এবং recipe নিচে লুকানো থাকে, তবুও markup-টি visible recipe সঠিকভাবে বর্ণনা করতে হবে। Instructions অন্য কথা বললে structured data-তে five-minute prep time দাবি করা উচিত নয়।
Recipe pages image-heavy, তাই structured data কাজের কেবল একটি অংশ। Good images, sensible compression, এবং useful alt text—সবই গুরুত্বপূর্ণ। আপনি যদি food, product, বা editorial images পরিষ্কার করছেন, 2026 সালে image alt text-এর একটি ব্যবহারিক গাইড schema কাজের একটি উপকারী companion।
VideoObject
VideoObject markup video previews, key moments, thumbnails, duration, upload date, এবং video indexing প্রভাবিত করতে পারে। এটি তখনই উপকারী যখন video পেজের একটি meaningful অংশ, নিচে incidental embed নয়।
ন্যূনতমভাবে, দিন:
- Name
- Description
- Thumbnail URL
- Upload date
- Duration
- Embed বা content URL
Instructional বা long-form videos-এর জন্য, key moments search engines-কে video-র sections বুঝতে সাহায্য করতে পারে। এটি video search-এ কীভাবে দেখা যায় তা উন্নত করতে পারে, যদিও আবারও বলি, placement নিশ্চিত করে না।
Organization, Logo, এবং WebSite
Organization markup একটি site-এর পেছনের entity define করতে সাহায্য করে। WebSite site-level understanding সমর্থন করতে পারে এবং কিছু ক্ষেত্রে, search engine দেখানোর সিদ্ধান্ত নিলে sitelinks search box-এর মতো features সমর্থন করতে পারে।
এই markup flashy নয়, বরং foundational। এটি পরিষ্কার করতে সাহায্য করতে পারে:
- Official site identity
- Logo
- Social profiles
- Contact information
- Parent বা subsidiary relationships
প্রতিটি serious business, publication, nonprofit, এবং product company-এর কোথাও স্থিতিশীল জায়গায় clean organization markup থাকা উচিত, সাধারণত homepage বা about page-এ।
এর মধ্যে সম্ভাব্য প্রতিটি property ঠেসে দেবেন না। লক্ষ্য হলো entity clarity, database dump নয়।
FAQPage: technically supported, কিন্তু বেশিরভাগ site-এর জন্য খুব কমই দৃশ্যমান
FAQPage বিশেষভাবে উল্লেখযোগ্য, কারণ এটি একসময় সহজ win ছিল। বহু বছর ধরে, FAQ markup snippets-কে question-and-answer accordions দিয়ে expand করতে পারত। এতে এটি আকর্ষণীয় হয়ে ওঠে এবং অনুমেয়ভাবেই overused হয়।
Google পরে FAQ rich results ব্যাপকভাবে সীমিত করে, সাধারণত কেবল well-known authoritative government এবং health sites-এর জন্য সেগুলো দেখায়। Other search engines FAQ markup ভিন্নভাবে ব্যবহার করতে পারে, এবং markup এখনও machines-কে content structure বুঝতে সাহায্য করতে পারে, কিন্তু বেশিরভাগ commercial এবং editorial sites দৃশ্যমান FAQ rich results আশা করা উচিত নয়।
FAQ markup ব্যবহার করুন কেবল তখনই যখন পেজে সত্যিই FAQ আছে। Search real estate ধরার জন্য fake Q&A blocks যোগ করবেন না।
DiscussionForumPosting এবং ProfilePage
Community content search results-এ বেশি prominent হয়ে উঠেছে, এবং structured data forum threads এবং profile pages শনাক্ত করতে সাহায্য করতে পারে।
DiscussionForumPosting forums, Q&A communities, এবং discussion platforms-এর জন্য উপকারী হতে পারে, যেখানে main content হলো user-generated discussion। ProfilePage people বা contributors সম্পর্কে pages শনাক্ত করতে সাহায্য করতে পারে, বিশেষ করে যেখানে expertise, authorship, বা community identity গুরুত্বপূর্ণ।
এটি সাধারণ marketing testimonials বা blog comments-এর জন্য উপযুক্ত নয়। Page type-টি actual experience-এর সঙ্গে মিলতে হবে।
উপকারী কিন্তু প্রায়ই অতিমূল্যায়িত types
কিছু schema.org types semantic দিক থেকে যুক্তিযুক্ত, কিন্তু নিজেরা সচরাচর visible search enhancements তৈরি করে না।
Examples অন্তর্ভুক্ত:
ServiceThingCreativeWorkPersonPlaceImageObjectWebPageAboutPageContactPage
এগুলো “খারাপ” types নয়। এগুলো একটি পেজকে আরও নির্দিষ্টভাবে বর্ণনা করতে সাহায্য করতে পারে, এবং broader knowledge graph contexts-এ উপকারী হতে পারে। কিন্তু আপনার লক্ষ্য যদি search results-এ দৃশ্যমান পরিবর্তন হয়, এগুলো সাধারণত secondary।
উদাহরণস্বরূপ, একটি consulting page-কে Service হিসেবে mark করলে নির্ভরযোগ্যভাবে কোনো special service rich result তৈরি হবে না। Clear copy, internal links, fast rendering, এবং credible evidence সহ একটি well-structured page elaborate কিন্তু unsupported markup-এর চেয়ে search performance-এর জন্য বেশি কাজ করবে।
একইভাবে, ImageObject images বর্ণনা করতে পারে, কিন্তু image search performance surrounding text, filenames, captions, image quality, indexing, এবং accessibility-এর ওপরও নির্ভর করে। Schema basics-এর বিকল্প নয়।
JSON-LD সাধারণত সেরা implementation format
Search engines Microdata এবং RDFa সহ কয়েকটি structured data formats পড়তে পারে, কিন্তু JSON-LD সাধারণত সবচেয়ে পরিষ্কার পছন্দ।
এটি markup-কে HTML presentation থেকে আলাদা রাখে, test করা সহজ, এবং designers templates পরিবর্তন করলে ভেঙে যাওয়ার সম্ভাবনা কম। বেশিরভাগ teams-এর জন্য, page head বা body-তে JSON-LD হলো practical default।
একটি সহজ product example এমন দেখায়:
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Acme Carbon Tripod",
"image": "https://example.com/images/tripod.jpg",
"description": "A lightweight carbon tripod for travel photography.",
"brand": {
"@type": "Brand",
"name": "Acme"
},
"offers": {
"@type": "Offer",
"priceCurrency": "USD",
"price": "149.00",
"availability": "https://schema.org/InStock",
"url": "https://example.com/products/carbon-tripod"
}
}
উদাহরণটি ইচ্ছাকৃতভাবে plain। বেশিরভাগ structured data boring হওয়া উচিত। Clever হওয়ার চেয়ে accurate হওয়া ভালো।
একটি ব্যবহারিক prioritization model
প্রথমে কী implement করবেন তা সিদ্ধান্ত নিতে হলে, এই order ব্যবহার করুন:
- Supported search features-এর সঙ্গে map করে এমন page types দিয়ে শুরু করুন। Product, recipe, event, job, video, breadcrumb, article, এবং local business markup সাধারণত obscure types-এর আগে মনোযোগ পাওয়ার যোগ্য।
- শুধু users যা দেখতে পারে সেটিই mark up করুন। Hidden claims structured data-কে ineligible বা risky করে তোলার সাধারণ কারণ।
- Individual pages নয়, templates ঠিক করুন। Structured data maintain করা সবচেয়ে সহজ যখন এটি আপনার CMS বা product database থেকে generated হয়।
- Validate করুন, তারপর monitor করুন। Official rich result এবং schema validation tools ব্যবহার করুন, তারপর যেখানে পাওয়া যায় Search Console enhancement reports দেখুন।
- Page experience উপেক্ষা করবেন না। Rich results presentation-এ সাহায্য করতে পারে, কিন্তু users শেষ পর্যন্ত পেজেই land করে। Performance reports যদি আপনার team-কে nervous করে, schema-কে আরেকটি distraction বানানোর আগে panic না করে Lighthouse reports পড়ুন।
সাধারণ mistakes যা impact কমায়
ভুল page type mark up করা
একটি category page product page নয়। Careers landing page job posting নয়। Upcoming webinars-এর একটি list necessarily একটি event নয়।
Search features সাধারণত নির্দিষ্ট page intents ঘিরে design করা হয়। Markup-কে পেজের dominant purpose-এর সঙ্গে মিলিয়ে নিন।
দৃশ্যমান নয় এমন properties যোগ করা
পেজে rating না দেখালে aggregateRating অন্তর্ভুক্ত করবেন না। Job page salary উল্লেখ না করলে compensation markup তৈরি করার ব্যাপারে সতর্ক থাকুন। কোনো product out of stock হলে সেটিকে in stock হিসেবে mark করবেন না।
Structured data visible facts parse করা সহজ করবে, পেজের একটি parallel version তৈরি করবে না।
Validation-কে success হিসেবে ধরা
Validator pass করা মানে কেবল syntax গ্রহণযোগ্য এবং required fields উপস্থিত থাকতে পারে। এর মানে এই নয় যে পেজটি rich result পাবে।
Validation-কে outcome নয়, floor হিসেবে ভাবুন।
একবার schema implement করে ভুলে যাওয়া
Prices বদলায়। Jobs expire করে। Events postponed হয়। Authors চলে যায়। Logos redesigned হয়।
Stale fields থেকে generated structured data নীরবে inaccurate হয়ে যেতে পারে। Templates, CMS fields, বা business data sources পরিবর্তন করলেই এটি review করুন।
<!-- tool-cta:start -->
💡 এটি চেষ্টা করুন: কোন স্কিমা টাইপগুলো আসলে গুরুত্বপূর্ণ তা খতিয়ে দেখার আগে, JSON Formatter দিয়ে আপনার JSON-LD পরিষ্কার করুন, যাতে কাঠামোটি সহজে অডিট করা যায়।
<!-- tool-cta:end -->
শান্ত সুপারিশ
বেশিরভাগ sites-এর জন্য, schema strategy modest এবং deliberate হওয়া উচিত।
আপনার real content-এর সঙ্গে মেলে এবং supported search features-এর সঙ্গে map করে এমন types implement করুন। Data accurate রাখুন। Reliable sources থেকে generate করুন। Validate করুন। Results monitor করুন। তারপর থামুন।
পেজের প্রতিটি noun mark up করার প্রয়োজন নেই। কোনো checklist বলেছে বলে বারোটি nested schema types দরকার নেই। এবং পেজ নিজে যা বলে তার চেয়ে বেশি বলে এমন structured data তো অবশ্যই দরকার নেই।
Schema.org সবচেয়ে উপকারী যখন এটি ambiguity দূর করে। Search results উন্নত হয় যখন সেই clarity search engines সত্যিই support করে এমন feature-এর সঙ্গে align করে।