2021 में, एक ट्रैवल क्लाइंट ने Seahawk को एक माइग्रेशन ब्रीफ सौंपा जिसने मेरा दिल बैठा दिया। इक्यानवे हज़ार डेस्टिनेशन और होटल पेज। हर एक को वैध, विशिष्ट, परीक्षित स्कीमा मार्कअप की ज़रूरत थी -- न कि वह आलसी वन-साइज़-फिट्स-ऑल WebPage टाइप जो ज़्यादातर प्लगइन लगा देते हैं और बस कह देते हैं। क्लाइंट ने पहले से ही दो "ऑटोमेटिक स्कीमा" WordPress प्लगइन आज़मा चुके थे। दोनों ने तकनीकी रूप से वैध JSON-LD तैयार किया था जो हर सार्थक अर्थ में बेकार भी था -- जेनेरिक नाम, कोई नेस्टेड एंटिटी नहीं, कीमतें गायब, रिव्यू एग्रीगेट गलत जगह इंगित कर रहे थे। Google का Rich Results Test विनम्रता से भ्रमित था।tested schema markup -- not the lazy one-size-fits-all WebPage type that most plugins slap on and call it a day. The client had already tried two "automatic schema" WordPress plugins. Both had produced technically valid JSON-LD that was also, in every meaningful sense, useless -- generic names, no nested entities, prices missing, review aggregates pointing at the wrong thing. Google's Rich Results Test was politely confused.
मुख्य निष्कर्ष: 91,000 पृष्ठों के लिए स्कीमा एक आर्किटेक्चर समस्या है, प्लगइन समस्या नहीं: इसे बिल्ड टाइम पर डेटा लेयर से जेनरेट करें और पाइपलाइन में वैलिडेट करें।Schema for 91,000 pages is an architecture problem, not a plugin problem: generate it from the data layer at build time and validate it in the pipeline.
उस प्रोजेक्ट ने मुझे पिछले आठ सालों की तुलना में स्केल पर स्कीमा के बारे में कहीं अधिक सिखाया। तो यहाँ है जो मुझे वास्तव में पता है।
---
"बस एक प्लगइन इंस्टॉल करो" स्केल पर क्यों टूट जाता है
देखिए, मैं यहाँ Yoast या Rank Math पर तनक़ी करने नहीं आया हूँ। 40-पेज की ब्रोशर साइट के लिए वे वाक़ई ठीक हैं। लेकिन 500-पेज के आसपास कहीं, प्लगइन-जेनरेटेड स्कीमा अपनी ख़ुद की मान्यताओं के तहत टूटने लगता है।
मूल समस्या यह है कि प्लगइन पेज टेम्पलेट के आस-पास बनाए जाते हैं, डेटा मॉडल के आस-पास नहीं। वे पोस्ट टाइटल पढ़ते हैं, शायद एक-दो कस्टम फील्ड, और एक स्कीमा ब्लॉब बनाते हैं। जब आपकी साइट में 91,000 पेज छह कंटेंट टाइप में फैले हों -- होटल, डेस्टिनेशन, टूर, रिव्यू, FAQ, और लेखक प्रोफाइल -- एक ही प्लगइन कॉन्फ़िगरेशन बिना विशाल मैनुअल ओवरराइड काम के उस विविधता को व्यक्त नहीं कर सकता। और अगर आप उस स्केल पर मैनुअल ओवरराइड कर रहे हैं, तो आप पहले ही हार चुके हैं।page templates, not data models. They read the post title, maybe a custom field or two, and construct a schema blob. When your site has 91,000 pages across six content types -- hotels, destinations, tours, reviews, FAQs, and author profiles -- a single plugin configuration cannot express that variety without enormous manual override work. And if you're doing manual overrides at that scale, you've already lost.
बात यह है: स्कीमा मार्कअप मौलिक रूप से एक डेटा ट्रांसफॉर्मेशन समस्या है। आपके पास डेटाबेस में संरचित डेटा है; आपको इसे एक <script> टैग में JSON-LD के रूप में व्यक्त करने की जरूरत है। बस इतना ही। जिस क्षण आप इसे इस तरीके से समझते हैं, सही आर्किटेक्चर बहुत स्पष्ट हो जाता है।<script>tag. That's it. The moment you frame it that way, the right architecture becomes much clearer.
तीन विफलता मोड जो मैं लगातार देख रहा हूँ
- स्टैटिक स्कीमा ब्लॉब्स टेम्पलेट्स में हार्डकोड किए गए। ठीक है जब तक प्रोडक्ट का नाम न बदले, फिर आपके पास 12,000 पेजेज़ Google को झूठ बोल रहे हैं। hardcoded in templates. Fine until the product name changes, then you've got 12,000 pages lying to Google.
- प्लगइन कॉन्फ़िगरेशन जो कंडीशनल लॉजिक को हैंडल नहीं कर सकते -- जैसे कि केवल aggregateRating दिखाना जब वास्तव में रिव्यू हों, या पोस्ट कैटेगरी के अनुसार अलग @type। that can't handle conditional logic -- like only showing
aggregateRatingwhen there are actually reviews, or different@typeper post category. - बैच-जेनरेटेड फाइलें एक बार अपलोड कीं और कभी अपडेट नहीं कीं। मैंने साइट्स ऑडिट किए हैं जहाँ स्कीमा अठारह महीने पुरानी थी। कीमतें गलत थीं। इवेंट के डेट्स पास हो चुके थे। uploaded once and never updated. I've audited sites where the schema was eighteen months stale. The prices were wrong. The event dates had passed.
---
JSON-LD वास्तव में बड़े पैमाने पर कैसे काम करता है
टूलिंग में जाने से पहले: एक त्वरित आधार।JSON-LD -- JSON for Linked Data -- Google का पसंदीदा स्कीमा फॉर्मेट है क्योंकि यह <script> ब्लॉक में रहता है, आपके HTML से अलग। इसका मतलब है कि आप इसे सर्वर-साइड जेनरेट कर सकते हैं, इसे साफ-सुथरे तरीके से इंजेक्ट कर सकते हैं, और मार्कअप को छुए बिना इसे अपडेट कर सकते हैं। यह अलगाव सब कुछ है जब आप दसियों हज़ार पेजों से निपट रहे हों।JSON-LD -- JSON for Linked Data -- is Google's preferred schema format precisely because it lives in a<script>block, separate from your HTML. That means you can generate it server-side, inject it cleanly, and update it without touching markup. That separation is everything when you're dealing with tens of thousands of pages.
Schema.org शब्दावली विशाल है। ज़्यादातर लोग इसका लगभग 1% उपयोग करते हैं। स्केल पर आपको गहरे जाने की ज़रूरत है -- Hotel, TouristDestination, LocalBusiness, Review, AggregateRating, नेस्टेड Offer ऑब्जेक्ट, BreadcrumbList। हर टाइप के आवश्यक और अनुशंसित प्रॉपर्टी हैं, और Google की "अनुशंसित" की व्याख्या मूलतः "आवश्यक है अगर आप रिच रिजल्ट चाहते हैं" है।Schema.org vocabulary is vast. Most people use about 1% of it. At scale you need to go deeper -- Hotel,TouristDestination,LocalBusiness,Review,AggregateRating, nested Offer objects,BreadcrumbList. Each type has required and recommended properties, and Google's interpretation of "recommended" is basically "required if you want the rich result."
वह फंडामेंटल रूल जिसे मैं फॉलो करता हूँ: एक प्राइमरी `@type` प्रति पेज, नेस्टेड टाइप्स ज़रूरत के हिसाब से। पाँच @type वैल्यूज़ स्टैक करने की कोशिश न करें यह उम्मीद में कि एक स्टिक हो जाए। सबसे स्पेसिफ़िक टाइप चुनें जो फ़िट हो, फिर सपोर्टिंग टाइप्स इसके अंदर नेस्ट करें।one primary `@type` per page, with nested types as needed.Don't stack five@type values hoping one sticks. Pick the most specific type that fits, then nest supporting types inside it.
---
आर्किटेक्चर जो हमने असल में इस्तेमाल किया
ट्रैवल क्लायंट के लिए, हम तीन-लेयर सिस्टम पर पहुँचे। व्हाइटबोर्ड-डायग्राम के नजरिये से सुंदर नहीं, लेकिन यह काम करता था।
लेयर 1: टेम्पलेट-स्तरीय Schema क्लासेज़ (PHP)
हर कंटेंट टाइप को अपना PHP क्लास मिला जो अपना स्कीमा एरे बनाने के लिए ज़िम्मेदार था। HotelSchemaBuilder, DestinationSchemaBuilder, TourSchemaBuilder -- आप समझ गए। हर क्लास ACF Pro कस्टम फील्ड, जहाँ लागू हो WooCommerce डेटा, और कुछ कंप्यूटेड वैल्यू खींचता था (जैसे एक CPT-आधारित रिव्यू सिस्टम से aggregateRating की गणना)।HotelSchemaBuilder,DestinationSchemaBuilder,TourSchemaBuilder -- you get the idea. Each class pulled from ACF Pro custom fields, WooCommerce data where applicable, and a few computed values (like calculating aggregateRating from a CPT-based review system).
हर क्लास का आउटपुट एक साधारण PHP ऐरे था। अभी JSON नहीं। बस डेटा।
यह ज़रूरी है क्योंकि इसका मतलब है कि आप डेटा लॉजिक को सीरिएलाइज़ेशन से अलग यूनिट टेस्ट कर सकते हैं। मुझे शुरू से ही इस प्रोजेक्ट पर ऐसा करना चाहिए था। मैंने नहीं किया। इसकी कीमत हमें स्टेजिंग में करीब दो दिन की डिबगिंग में पड़ी जब ratingValue एक स्ट्रिंग की जगह फ़्लोट रिटर्न कर रहा था और Google का वैलिडेटर चुपचाप पूरे aggregateRating ब्लॉक को इग्नोर कर रहा था।ratingValue was returning a string instead of a float and Google's validator was silently ignoring the whole aggregateRating block.
लेयर 2: एक सेंट्रल Schema Manager
एक सिंगल SchemaManager क्लास, wp_head में हुक किया गया, इसके लिए ज़िम्मेदार था:SchemaManager class, hooked into wp_head, was responsible for:
- वर्तमान टेम्पलेट/पोस्ट टाइप के आधार पर कौन सा बिल्डर क्लास invoke करना है, यह निर्धारित करना
- साइटव्यापी entities को मर्ज करना (Organization graph, WebSite with SearchAction, BreadcrumbList)
Organizationgraph,WebSitewithSearchAction,BreadcrumbList) - JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE के साथ अंतिम array को JSON के रूप में encode करना
JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE - इसे <script type="application/ld+json"> टैग में wrap करना और echo करना
<script type="application/ld+json">tag and echoing it
breadcrumb logic सबसे मुश्किल हिस्सा था। Destinations के पास तीन-स्तरीय hierarchy था: Region → Country → City। BreadcrumbList को गतिशील रूप से प्रतिबिंबित करना, कुछ भी hardcode किए बिना, इसका अर्थ था render time पर post ancestors को traverse करना। यदि आप सावधान न हों तो धीमा। हमने breadcrumb arrays को post ID के per एक transient में cache किया 24-hour TTL के साथ। इससे overhead को नगण्य तक नीचे लाया गया।BreadcrumbList to reflect that dynamically, without hardcoding anything, meant traversing post ancestors at render time. Slow, if you're not careful. We cached the breadcrumb arrays per post ID in a transient with a 24-hour TTL. That brought the overhead down to negligible.
Layer 3: Validation और Monitoring
Schema generate करना पहला कदम है। जानना कि यह कब टूटता है, दूसरा कदम है, और ज्यादातर teams इसे पूरी तरह skip कर देती हैं।
हमने एक Google Search Console प्रॉपर्टी सेट अप की और Rich Results रिपोर्ट को साप्ताहिक रूप से देखते रहे। लेकिन वह प्रतिक्रियाशील है -- GSC आपको Google के द्वारा पेज को क्रॉल करने के बाद त्रुटियों के बारे में बताता है। सक्रिय जांच के लिए, हमने हर महीने शीर्ष 2,000 पेजों के क्रॉल पर SchemaApp चलाया। यह प्रॉपर्टी-स्तरीय त्रुटियाँ सामने लाता है जो GSC रिपोर्ट को अस्पष्ट रखती हैं।after Google has crawled the page. For proactive checks, we ran SchemaApp on a crawl of the top 2,000 pages monthly. It surfaces property-level errors that the GSC report obscures.
साथ ही: Google के Rich Results Test के पास एक API है। हमने एक छोटी script लिखी जो हर रात 50 URLs के एक random sample के साथ API को hit करेगी और किसी भी validation failures को log करेगी। सस्ता बीमा।Google's Rich Results Test has an API. We wrote a small script that would hit the API with a random sample of 50 URLs nightly and log any validation failures. Cheap insurance.
---
गतिशील डेटा को संभालना — परफॉर्मेंस को बर्बाद किए बिना
यहाँ वह जगह है जहाँ ज़्यादातर स्केल इंप्लीमेंटेशन गिरते हैं। स्कीमा जो लाइव डेटा को संदर्भित करते हैं -- मूल्य, उपलब्धता, रिव्यू काउंट -- ताज़ा रहना पड़ता है। लेकिन 91,000 पेजों के हर सिंगल पेज लोड पर JSON-LD को दोबारा जेनरेट करना मुफ़्त नहीं है।
मेरा तरीका, और मैंने इसे शायद एक दर्जन बड़ी साइटों पर रिफाइन किया है:
आक्रामक तरीके से कैश करें, स्मार्ट तरीके से इनवेलिडेट करें।
होटल पेजों के लिए, स्कीमा blob को post meta के रूप में स्टोर किया जाता था -- एक serialised JSON-LD string -- और इसे केवल तब regenerate किया जाता था जब:
- पोस्ट खुद अपडेट होती है
- उस पोस्ट के लिए एक नया रिव्यू सबमिट होता है
- price custom field बदला गया (हमने इसके लिए ACF save_post action में hook किया)
save_postaction for this)
बाकी सब कुछ कैश्ड स्ट्रिंग से सर्व किया जाता है। बिलकुल तेज़। और क्योंकि इनवेलिडेशन हुक्स विशिष्ट थे, स्कीमा सटीक रहता था।
एक चीज़ जो मैंने शुरुआत में गलत की: मैंने पूरे <script> tag को cache किया, opening और closing elements सहित। फिर हमें एक content type के लिए @context URL बदलने की जरूरत थी। हर cache entry को bust करना पड़ा। अब मैं केवल JSON string को cache करता हूँ और render time पर इसे wrap करता हूँ। पाँच मिनट की अतिरिक्त code, एक घंटे की head-scratching को बचाया।<script>tag, including the opening and closing elements. Then we needed to change the@context URL for one content type. Had to bust every cache entry. Now I cache only the JSON string and wrap it at render time. Five minutes of extra code, saved an hour of head-scratching.
असल कीमतों के बारे में क्या?
tour pricing के लिए जो दिन में कई बार बदलता था, हमने एक अलग approach लिया। base schema को cache किया गया था, लेकिन Offer block को request time पर fresh generate किया गया था और serialisation से पहले merge किया गया था। हाँ, इसने प्रति request एक छोटा overhead जोड़ा। लेकिन यह page load के per एक database query था, बारह नहीं। स्वीकार्य trade-off।Offer block was generated fresh at request time and merged in before serialisation. Yes, it added a small overhead per request. But it was one database query per page load, not twelve. Acceptable trade-off.
---
कई साइटों तक स्केल करना: Seahawk का कोण
Seahawk ने 12,000 से अधिक साइटें बनाई हैं, और स्कीमा इम्प्लीमेंटेशन उनके काफ़ी हिस्से में आता है। ट्रैवल क्लाइंट एक सीमांत मामला था। लेकिन वही आर्किटेक्चरल सिद्धांत चाहे आप 91,000 पेजेज़ पर काम कर रहे हों या 4,000 पर, लागू होते हैं।
जो pattern मैंने settle किया है वह एक छोटा internal WordPress plugin है -- हम इसे seahawk-schema-core कहते हैं -- जो manager/builder scaffolding provide करता है बिना किसी content-type-specific logic के। Client projects इसे अपनी खुद की builder classes से extend करती हैं। Core schema logic के लिए कोई plugin dependencies नहीं। कोई जोखिम नहीं कि कोई third-party plugin update किसी site की entire rich results presence को तोड़ दे।seahawk-schema-core -- that provides the manager/builder scaffolding without any content-type-specific logic. Client projects extend it with their own builder classes. No plugin dependencies for the core schema logic. No risk of a third-party plugin update blowing up a site's entire rich results presence.
वह आखिरी बात लोग जितना मानते हैं उससे कहीं ज्यादा real है। मैंने देखा है कि Rank Math updates ने silently custom schema overrides को तोड़ दिया है। यह इसलिए नहीं कि Rank Math बुरा है -- यह नहीं है -- लेकिन जब आप एक बड़ी site के लिए आवश्यक level पर output customize कर रहे हों, तो आप उस चीज़ के बाहर operate कर रहे हो जिसे plugin handle करने के लिए design किया गया था। Code को own करो, risk profile को own करो।
---
इस स्केल पर टेस्टिंग: एक व्यावहारिक चेकलिस्ट
आप 91,000 URLs को मैन्युअली टेस्ट नहीं कर सकते। तो आप स्मार्टली टेस्ट करते हैं।
- Template type के हिसाब से sample करो। हर content type के लिए 10 URLs pick करो। उन्हें test करो। अगर builder एक होटल पेज के लिए सही है, तो यह सभी 3,000 होटल पेजों के लिए सही है (जब तक कि कोई bad data न हो -- इस पर बाद में बात करेंगे)।Pick 10 URLs per content type. Test those. If the builder is correct for one hotel page, it's correct for all 3,000 hotel pages (unless there's bad data -- more on that below).
- विशेष रूप से edge cases को टेस्ट करें। कोई रिव्यू न होने वाले पेज। अधूरे कस्टम फील्ड वाले पेज। टाइटल में स्पेशल कैरेक्टर वाले पेज (&, ", एक्सेंटेड कैरेक्टर)। JSON सीरिएलाइजेशन इनमें से ज्यादातर को खा जाता है, लेकिन सभी को नहीं।Pages with no reviews. Pages with incomplete custom fields. Pages with special characters in titles (
&,", accented characters). JSON serialisation eats a lot of these, but not all of them. - Screaming Frog के साथ एक पूर्ण structured data crawl चलाएँ। Screaming Frog SEO Spider के पास एक structured data extraction mode है जो हर URL से JSON-LD को pull और validate करेगा जिसे यह crawl करता है। errors को export करें, template type के आधार पर group करें, source पर fix करें।The Screaming Frog SEO Spider has a structured data extraction mode that'll pull and validate JSON-LD from every URL it crawls. Export the errors, group by template type, fix at the source.
- GSC के Enhancements tab को monitor करो। एक threshold alert set करो -- अगर valid items week-over-week 5% से ज्यादा drop हों, तो कुछ टूट गया है। 48 घंटों के अंदर action लो।Set a threshold alert -- if valid items drop by more than 5% week-over-week, something broke. Act within 48 hours.
- हर deployment के बाद spot-check करो। भले ही schema code बदला न हो। Database migrations, plugin updates, theme changes -- इनमें से कोई भी upstream data issues introduce कर सकता है जो schema output को corrupt कर सकते हैं।Even if the schema code didn't change. Database migrations, plugin updates, theme changes -- any of them can introduce upstream data issues that corrupt schema output.
बुरा डेटा साइलेंट किलर है
उस travel site के पास तीन देशों में बारह लोगों की एक content team थी। कुछ destination pages के description field में malformed HTML था -- presumably Word से paste किया गया। जब वह field schema description property में गया, तो JSON technically valid था लेकिन description में entities और stray<span>tags शामिल थे। Google ने property को ignore कर दिया। हमने हर builder class में एक sanitisation step add किया जो tags को strip करता है और HTML entities को decode करता है इससे पहले कि value schema array में जाए। इसने इसे permanently solve कर दिया।description field -- pasted from Word, presumably. When that field fed into the schema description property, the JSON was technically valid but the description included entities and stray<span>tags. Google ignored the property. We added a sanitisation step in every builder class that strips tags and decodes HTML entities before the value hits the schema array. Solved it permanently.
---
द एंटिटी ग्राफ: इसे ignore न करें
जो चीज़ mediocre schema work को genuinely अच्छे technical SEO से अलग करती है वह entity graph है -- specifically, वह sitewide Organization और WebSite entities जो हर page पर दिखने चाहिए और सब कुछ को एक-दूसरे से जोड़ते हैं।Organization and WebSite entities that should appear on every page and link everything together.
ज़्यादातर साइटों के पास ये हैं, लेकिन ख़राबी से। Name, URL, शायद एक logo। पूरा Organization type sameAs links को आपकी Wikidata entry में, social profiles में, और अन्य authoritative sources को सपोर्ट करता है। वह cross-linking यह है कि Google को confidence मिलता है कि आपकी Organization entity उसके Knowledge Graph में वही entity है जो आपके page schema में दिख रही है।Organization type supports sameAs links to your Wikidata entry, social profiles, and other authoritative sources. That cross-linking is how Google builds confidence that your Organization entity in its Knowledge Graph is the same entity appearing in your page schema.
उस ट्रैवल क्लाइंट के लिए, हमने Organization block को इसके साथ बनाया:Organization block with:
sameAs जो उनकी Crunchbase profile, LinkedIn page, और एक Wikipedia stub को point करता है जो उनके पास थाpointing to their Crunchbase profile, LinkedIn page, and a Wikipedia stub they hadcontactPoint structured phone और department info के साथwith structured phone and department infofoundingDate और numberOfEmployees (rough range -- यह public info है वैसे भी)andnumberOfEmployees(rough range -- this is public info anyway)
क्या इसने रात भर रैंकिंग को हिलाया? नहीं। स्कीमा अलगाव में लगभग कभी नहीं करता। लेकिन यह ढांचा है। आप इसे एक बार ठीक से बनाते हैं, और यह समय के साथ चक्रवृद्धि होता है।
---
FAQ
इस पैमाने पर स्कीमा को लागू करने में कितना समय लगता है?
उस 91,000-page travel site के लिए, पूरे implementation -- architecture, builder classes, caching layer, testing, GSC monitoring setup -- में लगभग छः हफ्ते दो developers के साथ लगे। यह बहुत लगता है। लेकिन उस समय का आधा existing data quality को audit करने में लगा, schema code लिखने में नहीं। अगर आपका data clean है, तो आप faster move कर सकते हो।
क्या मुझे बड़ी साइटों के लिए प्लगइन का उपयोग करना चाहिए या कस्टम बनाना चाहिए?
कुछ सौ पेजों तक कुछ भी हो, प्लगइन वाकई ठीक है। Rank Math का schema मॉड्यूल ठोस है और कस्टम schema ब्लॉक आपको सकारण लचीलापन देता है। कई हज़ार पेजों से ऊपर जहाँ कई अलग कंटेंट टाइप हों, मैं हर बार कस्टम बनाता हूँ। कंट्रोल बिल्ड कॉस्ट के लायक है।
बड़े स्तर पर schema का सबसे आम गलती क्या है?
समीक्षाएँ मौजूद होने पर aggregateRating का न होना -- या फिर न होने पर भी इसे शामिल करना। Google इस पर कड़ा है। अगर आपका schema 843 समीक्षाओं से 4.7 की aggregateRating का दावा करता है और उपयोगकर्ता पेज पर आता है लेकिन कोई समीक्षा नहीं देखता, तो यह एक manual action का इंतज़ार कर रहा है। आपके builder classes में conditional logic अनिवार्य है।aggregateRating when reviews exist -- or including it when they don't. Google is strict about this. If your schema claims an aggregateRating of 4.7 from 843 reviews and a user lands on the page and sees no reviews, that's a manual action waiting to happen. Conditional logic in your builder classes is non-negotiable.
क्या schema सीधे रैंकिंग में सुधार करता है?
सीधे तौर पर? शायद ज़्यादातर query types के लिए इतना नहीं। जो यह करता है वह है rich results को unlock करना -- star ratings, FAQ dropdowns, review snippets, SERP में breadcrumbs -- और ये features click-through rates को measurably बेहतर करते हैं। travel client ने पूरे implementation के चार महीने के भीतर hotel pages पर 22% CTR increase देखा। यह engagement signals में जाता है, जो rankings को प्रभावित करते हैं। तो: indirect रूप से, हाँ। Substantially।
आप schema काम के लिए रोज़-मर्रा कौन से टूल्स इस्तेमाल करते हैं?
Screaming Frog crawl-level auditing के लिए। Google का Rich Results Test spot-checks के लिए। validator.schema.org पर Schema Markup Validator property-level validation के लिए। और ईमानदारी से कहूँ, तो Schema.org documentation ख़ुद -- मेरे पास Hotel type page और कुछ अन्य bookmarked हैं और मैं उन्हें लगातार देखता हूँ। कोई fancy subscription tool की ज़रूरत नहीं।validator.schema.org for property-level validation. And honestly, the Schema.org documentation itself -- I have the Hotel type page and a handful of others bookmarked and I refer to them constantly. No fancy subscription tool needed.
---
बड़े स्तर पर Schema उन समस्याओं में से एक है जो प्लगइन समस्या की तरह दिखती है जब तक कि आप अंदर न हों और यह समझ न जाएँ कि यह वाकई एक सॉफ्टवेयर आर्किटेक्चर समस्या है जिसे SEO कपड़ों में पहनाया गया है। डेटा मॉडल को सही करो। बुद्धिमानी से कैश करो। निरंतर वैलिडेट करो। markup खुद लगभग आसान हिस्सा है।