मेटाडेटा, SEO और सोशल

दो विज़िटर आपके पेज पर आते हैं, बिना इसे ऐसे देखे जैसे कोई व्यक्ति देखता है। एक सर्च इंजन है जो यह तय कर रहा है कि पेज को लिस्ट करना है या नहीं और इसके बारे में क्या कहना है। दूसरा एक सोशल प्लेटफॉर्म है जो छोटा प्रिव्यू कार्ड बना रहा है जो तब दिखाई देता है जब कोई लिंक शेयर करता है। दोनों <head> में टैग्स के एक छोटे ब्लॉक को पढ़ते हैं, स्क्रीन पर दिखाई देने वाली सामग्री को नहीं। यह अध्याय उस ब्लॉक को लिखने के बारे में है ताकि आपका पेज सर्च रिजल्ट में, ब्राउज़र टैब में, और शेयर किए गए लिंक में सही तरीके से दिखाई दे।
Title और description
हर पेज को <title> की जरूरत है। यह ब्राउज़र टैब में, आपके बुकमार्क्स में, और सर्च रिजल्ट्स की लिस्ट में क्लिक करने योग्य हेडलाइन के रूप में दिखाई देने वाला टेक्स्ट है। यह head में रहता है, और यह एक छोटी सी लाइन है:
<title>शुरुआत के लिए साेरडो: आपकी पहली डेक, चरण दर चरण</title>सर्च रिजल्ट में उस हेडलाइन के नीचे आमतौर पर एक वाक्य होता है जो पेज का वर्णन करता है। यह meta description से आता है, एक और टैग जो आप head में रखते हैं:
<meta name="description" content="सरल साेरडो रेसिपी, अपने पहले आटे को मिलाने से लेकर एक कुरकुरे सुनहरे क्रस्ट तक, हर चरण के लिए टाइमिंग के साथ।" />एक शेल्फ पर किताब की कल्पना करें। शीर्षक रीढ़ पर मुद्रित है ताकि आप इसे खोज सकें, और विवरण पीछे का blurb है जो आपको यह तय करने में मदद करता है कि इसे खोलना है या नहीं।
<title> element आवश्यक है, और एक डॉक्यूमेंट में बिल्कुल एक होता है। यह तीन काम करता है: यह ब्राउज़र टैब को लेबल करता है, यह डिफॉल्ट नाम है जब कोई व्यक्ति पेज को बुकमार्क करता है, और यह हेडलाइन है जो सर्च इंजन आपके रिजल्ट के लिए दिखाता है। इसे किसी मनुष्य के लिए लिखें जो एक लिस्ट को स्कैन कर रहा हो, विशिष्ट शब्दों को पहले रखें, और इसे लगभग 60 characters तक सीमित रखें ताकि यह ellipsis से कट न जाए।
<meta name="description"> टैग वह वाक्य है जो उस हेडलाइन के नीचे दिखाई देता है। यह एक ranking factor नहीं है, लेकिन यह उस व्यक्ति के लिए आपकी pitch है जो यह तय कर रहा है कि क्लिक करना है या नहीं, इसलिए इसे विशिष्ट बनाएं और हर पेज के लिए एक अलग लिखें। लगभग 150 से 160 characters का लक्ष्य रखें। यदि आप इसे छोड़ते हैं, तो सर्च इंजन पेज टेक्स्ट से एक snippet खींचकर अपना सारांश लिखता है, और इसका अनुमान आपके वाक्य जितना अच्छा कभी नहीं होता।
<title>शुरुआत के लिए साेरडो: आपकी पहली डेक</title>
<meta name="description" content="एक चरण-दर-चरण पहली साेरडो, टाइमिंग और हर सामान्य गलती के लिए एक fix के साथ।" /><title> सबसे मजबूत on-page text है जिसे आप SERP (search engine results page, query द्वारा लौटाए गए results की list) पर क्या कहता है इसके लिए पूरी तरह से नियंत्रित करते हैं। इसे लेबल के रूप में नहीं, copy के रूप में मानने लायक है: विशिष्ट शब्द पहले जाते हैं, क्योंकि अंत truncated हो जाता है। character count जिसके बारे में सभी बात करते हैं वह वास्तव में लगभग 600 pixels की pixel-width limit है, इसलिए wide characters की title जल्दी कट जाती है। सर्च इंजन ऐसे titles को भी rewrite करते हैं जिन्हें वे unhelpful मानते हैं, उदाहरण के लिए एक जो प्रभाव के लिए एक शब्द को दोहराता है या query से match नहीं करता है, इसलिए एक स्पष्ट, सटीक title padded वाले से अधिक बार survive करता है।
description ranking में input नहीं है। इसकी पूरी job click-through है, लोगों का वह हिस्सा जो आपका result देखते हैं और इसे click करते हैं, और एक तेज description उस share को lift करता है। दो production rules length से ज्यादा मायने रखते हैं। पहला, हर पेज को अपना स्वयं का title और description मिलता है; एक पूरी templated site पर एक global pair ship करना मतलब है near-identical results जो एक-दूसरे के साथ compete करते हैं और boilerplate के रूप में पढ़ते हैं। दूसरा, एक site पर जो data से pages बनाता है, दोनों को fixed string के बजाय page के अपने fields से generate करें, इसलिए एक product page अपने product को name करता है और एक recipe page अपनी recipe को name करता है।
<title> आपका tab label है और हेडलाइन जो लोग सर्च results में क्लिक करते हैं, इसलिए इसे स्पष्ट बनाएं। <meta name="description"> नीचे का blurb है। दोनों head में रहते हैं, और हर पेज को अपना pair देना मेरे लिए मेरी expectation से बहुत कम effort लगा कि यह कितना मदद करता है। <title>, पहले distinctive words, लगभग 60 characters। Description ranking को प्रभावित नहीं करता, यह केवल click जीतता है, इसलिए एक global line के बजाय हर page के लिए एक विशिष्ट लिखें। इसे छोड़ दें और engine एक snippet invent करता है जिसे आपने चुना नहीं। Charset और viewport, दोबारा
Your first HTML page में skeleton दो meta tags से खुला जो copy करने और भूलने के लिए तेजी से हैं। वे एक दूसरे look के योग्य हैं, क्योंकि दोनों ही तरीका बदलते हैं जिसमें page को किसी भी content के दिखने से पहले read और render किया जाता है।
पहला tag character encoding है:
<meta charset="UTF-8" />यह ब्राउज़र को बताता है कि letters किस alphabet में लिखे गए हैं, इसलिए accented characters, curly quotes, और emoji सही तरीके से दिखाई देते हैं, अजीब symbols में बदलने के बजाय। हमेशा UTF-8 का उपयोग करें; यह हर language और हर emoji को cover करता है।
दूसरा tag viewport है, और यह page को phone screen पर fit करता है:
<meta name="viewport" content="width=device-width, initial-scale=1" />इसके बिना, एक phone मानता है कि page को wide desktop के लिए build किया गया था और पूरी चीज को shrink करता है जब तक text बहुत छोटा न हो जाए पढ़ने के लिए। इसके साथ, page device की width से match करता है। इसे ऐसे सोचें कि यह ब्राउज़र को बता रहा है कि paper की real size क्या है जिस पर यह print कर रहा है।
<meta charset="UTF-8"> character encoding set करता है, raw bytes से file के characters में mapping। यह early appear करना है, document के पहले 1024 bytes के अंदर और head में पहली चीज़ के रूप में, क्योंकि parser को encoding जानने की जरूरत है इससे पहले कि यह उसके बाद आने वाले text को decode करे। UTF-8 एकमात्र उत्तर है जिसका उपयोग करना चाहिए; यह हर language में हर character को encode करता है।
<meta name="viewport" content="width=device-width, initial-scale=1"> वह है जो एक page को phones पर responsive बनाता है। width=device-width page के layout width को device के अपने width से match करता है, और initial-scale=1 इसे normal zoom पर खोलता है, zoomed out के बजाय। इस tag को छोड़ दें और mobile browsers मान लेते हैं लगभग 980-pixel desktop layout, फिर इसे fit करने के लिए scale down करते हैं। user-scalable=no या maximum-scale को add न करें zoom को lock करने के लिए; यह लोगों को pinch करने से रोकता है text को enlarge करने के लिए, जिसका कई readers पर निर्भर करते हैं।
Charset declaration exist करता है क्योंकि parsing एक two-stage problem है: browser के पास bytes का एक stream है और उन्हें characters में बदलने के लिए एक encoding की जरूरत है। यदि encoding देर से declare किया जाता है, या उससे conflict करता है जिसे parser पहले bytes से अनुमान लगाता है, तो browser अपने काम को throw away कर सकता है और सही encoding के तहत top से फिर से parse कर सकता है, एक छोटी cost जिससे आप बचते हैं <meta charset="UTF-8"> को first रखकर। यदि response अपने HTTP Content-Type header में एक charset भी carry करता है, तो header wins करता है, लेकिन आप फिर भी meta tag को include करते हैं ताकि file सही हो जब बिना उस header के save या serve किया जाए। UTF-8 web का settled default है; कुछ और एक legacy situation है जिससे migrate करना है।
Viewport tag दो rendering modes के बीच switch है। इसके बिना एक mobile browser एक wide virtual canvas में render करता है (historically लगभग 980 CSS pixels) और result को down scale करता है, जो कि क्यों एक un-tagged page एक shrunken desktop जैसा दिखता है। width=device-width layout viewport को device से bind करता है, जो किसी भी responsive CSS के लिए behave करने की precondition है। user-scalable=no या low maximum-scale के साथ zoom को suppress करना एक accessibility failure है: यह WCAG में called out किया जाता है (Web Content Accessibility Guidelines, accessible web content के लिए standard reference, Accessibility में covered) क्योंकि यह लोगों को text को enlarge करने से blocks करता है जिसे वे अन्यथा नहीं पढ़ सकते।
<meta charset="UTF-8"> accented letters और emoji को gibberish में बदलने से रोकता है, इसलिए हमेशा इसे include करें। Viewport line page को phone पर fit करता है shrinking के बजाय एक tiny desktop में। दो tags जिन्हें आप एक बार copy करते हैं और फिर से rarely touch करते हैं, लेकिन उन्हें skip करना fast show up करता है। UTF-8 का use करें, कुछ और नहीं। Viewport tag width=device-width के साथ वह है जो responsive CSS को phones पर काम करता है, और कभी zoom को disable न करें, लोग इस पर निर्भर करते हैं। user-scalable=no के साथ lock करना WCAG को fail करता है, इसलिए इसे छोड़ दें। Open Graph और social cards
जब आप एक chat या social post में एक link paste करते हैं, तो अक्सर एक छोटा preview card दिखाई देता है जिसमें एक picture, एक title, और एक line of text होता है। वह card platform guess नहीं कर रहा है। Page इसे picture और words से hand करता है head में Open Graph नामक tags के एक set का उपयोग करके:
<meta property="og:title" content="शुरुआत के लिए साेरडो" />
<meta property="og:description" content="आपकी पहली डेक, चरण दर चरण।" />
<meta property="og:image" content="https://breadschool.example/loaf.jpg" />ध्यान दें कि ये property का उपयोग करते हैं जहां description tag पहले name का उपयोग करता था। यह Open Graph tags का shape है; pattern को copy करें और words और image address को बदलें। इसे page में एक छोटा preview pack करने के रूप में सोचें, जब भी कोई इसे share करने के लिए तैयार।
Open Graph meta tags का एक shared vocabulary है जो एक page को एक shareable object के रूप में describe करता है। यह Facebook पर शुरू हुआ और अब लगभग हर platform द्वारा read किया जाता है जो link previews दिखाता है। Tags property="og:..." का उपयोग करते हैं और essentials ये पांच हैं:
<meta property="og:title" content="शुरुआत के लिए साेरडो" />
<meta property="og:description" content="आपकी पहली डेक, चरण दर चरण, टाइमिंग के साथ।" />
<meta property="og:image" content="https://breadschool.example/loaf.jpg" />
<meta property="og:url" content="https://breadschool.example/sourdough" />
<meta property="og:type" content="article" />Twitter, अब X, अपने twitter: tags read करता है लेकिन Open Graph वाले पर fall back करता है, इसलिए आपको केवल वह piece add करने की जरूरत है जो layout को change करता है:
<meta name="twitter:card" content="summary_large_image" />यह आपको big-image card देता है, छोटे thumbnail के बजाय। og:image को लगभग 1200 by 630 pixels बनाएं ताकि यह card को cleanly भरे, और check करें आपका result एक platform के अपने link-preview debugger में इससे पहले कि आप इस पर rely करें।
इन tags का audience एक social scraper है: एक bot जो एक platform चलाता है जब एक link posted होता है, जो page को fetch करता है, केवल head को read करता है, और scroll, click, या usually JavaScript को run नहीं करता है। कैसे आप Open Graph लिखते हैं इसके बारे में सबकुछ उससे follows करता है। og:image एक absolute URL होना चाहिए, https:// और domain सहित, क्योंकि एक relative path जैसे /loaf.jpg के पास कोई page context नहीं है resolve करने के लिए जब एक remote scraper इसे read करता है। Tags property attribute का उपयोग करते हैं, name के बजाय, क्योंकि Open Graph एक RDFa में defined है, markup में structured data को embed करने के लिए एक older standard; practical takeaway केवल यह है कि og: tags property का उपयोग करते हैं और आपको उन्हें name में "correct" नहीं करना चाहिए।
दो production realities लोगों को catch करते हैं। पहला, platforms उस card को cache करते हैं जिसे उन्होंने scrape किया, इसलिए आपके tags को edit करना एक already-shared link को तब तक update नहीं करता जब तक आप platform के debugger के माध्यम से एक re-scrape force न करें। दूसरा, क्योंकि अधिकांश scrapers JavaScript को run नहीं करते हैं, Open Graph tags जो एक client द्वारा एक single-page app पर inject किए गए हैं अक्सर देखे ही नहीं जाते हैं; card एक bare title या कुछ नहीं पर fall back करता है। यदि आपके pages JavaScript द्वारा build किए गए हैं, तो fix है head को server पर render करना ताकि tags उस first response में present हों जिसे scraper read करता है। यह same constraint है जो crawling को shape करता है, जो next section में covered है।
og:title, og:description, और og:image। वे property के बजाय name का उपयोग करते हैं, जो पहली बार odd दिखता है लेकिन यह कैसे लिखा जाता है। उन्हें set करें और आपके links bare show up करना बंद कर देते हैं। og:title, og:description, og:image, og:url, og:type। Big image के लिए twitter:card को summary_large_image पर set करके add करें, और image को लगभग 1200 by 630 के around size करें। हमेशा card को एक platform debugger में check करें इससे पहले कि आप इस पर trust करें। og:image quietly fail करता है। Platforms card को cache करते हैं, इसलिए एक change को उनके debugger में एक forced re-scrape की जरूरत है। और client-rendered tags अक्सर कभी नहीं देखे जाते हैं, जो कि क्यों एक JavaScript app को head को server पर render करना पड़ता है। Favicons और अन्य link tags
ब्राउज़र tab में tiny icon, page title के बगल में, favicon है। यह है कि कैसे कोई आपके tab को दर्जनों अन्य लोगों के बीच spot करता है। आप एक <link> tag के साथ head में एक add करते हैं:
<link rel="icon" href="/favicon.png" />rel="icon" part ब्राउज़र को बताता है कि यह file page का icon है, और href image को point करता है। एक छोटी square image, लगभग 32 by 32 pixels, plenty है। यह एक छोटा touch है, और यह एक site को finished लगाता है।
<link> element आपके page को एक related file से connect करता है, और rel attribute बताता है कि वह file क्या है। Favicon rel="icon" का उपयोग करता है, और एक modern PNG या SVG पुरानी .ico format से बेहतर choice है। एक Apple touch icon भी add करें, जो image है जिसे iOS use करता है जब कोई आपकी site को अपनी home screen पर save करता है:
<link rel="icon" href="/favicon.svg" />
<link rel="apple-touch-icon" href="/apple-touch-icon.png" />एक और <link> यहां अपनी जगह के लायक है: canonical URL। जब same page एक से अधिक addresses पर reachable हो, उदाहरण के लिए trailing slash के साथ और बिना, या end पर tracking parameters के साथ, rel="canonical" उस एक address को name करता है जिसे आप real के रूप में treat करना चाहते हैं:
<link rel="canonical" href="https://breadschool.example/sourdough" />यह सर्च engines को बताता है कि सभी duplicates को उस single URL पर credit करें, rather than splitting page's standing को उनके across।
rel attribute एक relationship keyword है: यह states करता है कि linked resource इस document के लिए क्या है, जो कि एक element icons, canonicals, stylesheets, और preloads को cover करता है। Icons के लिए, browsers several accept करते हैं और size और format से choose करते हैं; एक SVG icon किसी भी display पर scale करता है एक separate file के बिना size per, एक PNG fallback के साथ older browsers के लिए। Legacy favicon.ico एक multi-resolution format है compatibility के लिए kept और अब reach for करने के लिए format नहीं है।
Canonical link वह है जिसके real ranking consequences हैं, इसलिए इसे exactly सही बनाना worth है। यह consolidates link equity, ranking value जो एक page की ओर point करने वाले links द्वारा passed होता है, उस URL पर जिसे आप nominate करते हैं, instead of scattering करने के बजाय alternate paths और parameters के across। Good practice एक self-referencing canonical है हर page पर (हर page अपने clean URL को name करता है), जो ambiguity को remove करता है जब parameters या alternate paths appear करते हैं। Failure mode एक canonical को wrong page पर point करना है: एक template जो एक section के पूरे पर एक canonical को hard-code करता है सर्च engines को बताता है कि हर page में यह एक का copy है, और बाकी index से drop कर जाते हैं। अन्य rel values जैसे preload और preconnect performance hints हैं जो एक resource को early fetch करते हैं या एक connection को warm up करते हैं; वे page-speed discussion के बजाय एक से belong करते हैं, इसलिए उन्हें एक pointer के रूप में treat करें, एक task यहां नहीं।
<link rel="icon"> के साथ add किया जाता है और एक छोटी square image। यह एक छोटी चीज़ है जो एक site को done feel कराती है। Head में <link> tag यह है कि कैसे आप एक page को इस तरह extra files पर point करते हैं। .ico के बजाय rel="icon" को एक PNG या SVG के साथ use करें, और saved-to-home-screen के लिए एक apple-touch-icon add करें। Canonical link, rel="canonical", real address को name करता है जब एक page कई पर reachable है, इसलिए सर्च engines एक URL को credit करते हैं इससे splitting के बजाय। rel एक relationship keyword है, जो कि क्यों एक element icons, canonicals, और preloads को handle करता है। एक SVG icon size per एक file के बिना scale करता है। Canonical high-stakes वाला है: एक self-referencing canonical per page safe है, लेकिन एक template जो हर page को एक URL पर point करता है बाकी को index से drop कर देता है। Crawlability basics
सर्च engines programs भेजते हैं जो web pages को visit करते हैं, उन्हें read करते हैं, और एक बड़ी list में उन्हें add करते हैं ताकि लोग उन्हें बाद में खोज सकें। वह program एक crawler है, और अधिकांश समय आप इसे अपना job करना चाहते हैं और आप कुछ नहीं करते। यदि आपके पास एक page है जिसे आप सर्च से बाहर रखना चाहते हैं, एक rough draft या एक private thank-you page, आप एक robots meta tag के साथ इसे say करते हैं:
<meta name="robots" content="noindex" />noindex मतलब है "कृपया इस page को सर्च results में list न करें।" Crawler को एक librarian के रूप में picture करें जो shelves पर चल रहा है और हर book को catalogue कर रहा है; यह tag एक note है जो librarian को इस को skip करने के लिए ask कर रहा है।
एक crawler आपके HTML को read करता है, वह links को follow करता है जो वह finds करता है more pages को reach करने के लिए, और content को index करता है ताकि यह इसे results में serve कर सके। आप इसे robots meta tag के साथ steer करते हैं। noindex एक page को results से रखता है, और nofollow crawler को बताता है कि page पर links के through ranking credit को pass न करें:
<meta name="robots" content="noindex, nofollow" />इसे robots.txt के साथ confuse न करें, एक अलग file आपकी site की root पर जो control करता है कि एक crawler किन pages को fetch करने की अनुमति है। Meta tag एक page की indexing को control करता है जो crawler पहले से reach कर चुका है; file access को control करता है।
Old <meta name="keywords"> tag को पूरी तरह से skip करें। यह एक बार pages को अपने keywords list करने देता था, सर्च engines ने इसे कई साल पहले trust करना बंद कर दिया, और यह आज कुछ नहीं करता। वह जो actually एक page को rank करने में मदद करता है ordinary good building है: एक clear title, real headings, semantic HTML जो page के हर part को name करता है, descriptive link text, और एक page जो quickly load करता है।
यह तीन steps को separate करने में मदद करता है जो एक सर्च engine लेता है, क्योंकि tags अलग-अलग ones पर act करते हैं। To crawl है fetch करने के लिए page। To index है store और understand करने के लिए later के लिए। To rank है order करने के लिए given query के लिए अन्य pages के against। Robots meta tag noindex के साथ indexing पर act करता है; robots.txt crawling पर act करता है; एक X-Robots-Tag HTTP header non-HTML files जैसे PDFs को same indexing rules apply कर सकता है। Classic mistake एक page को robots.txt में block करना और भी noindex को इसमें add करना है: crawler को page fetch करने की अनुमति नहीं है, इसलिए यह कभी noindex को नहीं देखता, और URL results में एक description के बिना linger कर सकता है। यदि आप एक page को index से बाहर चाहते हैं, इसे crawl होने दें और noindex को read होने दें।
Modern crawlers JavaScript को render करते हैं, लेकिन एक delay के अंदर और एक limited budget के अंदर, इसलिए content जो केवल एक client-side fetch के बाद appear करता है slow या not at all indexed है; reliable answer server-render करना है कुछ भी जिसे find होना चाहिए। एक page को एक form में describe करने के लिए जो एक सर्च engine directly use कर सके, add करें structured data, machine-readable facts page के बारे में। Standard way एक JSON-LD block है, structured data written JSON में using Schema.org vocabulary, placed head या body में एक <script type="application/ld+json"> tag के अंदर:
{
"@context": "https://schema.org",
"@type": "Recipe",
"name": "शुरुआत साेरडो",
"totalTime": "PT24H",
"recipeYield": "1 डेक"
}यह आपकी ranking को अपने आप raise नहीं करता; यह एक page को rich results के लिए eligible बनाता है, enhanced listings जिनमें stars, prices, या recipe details हैं जो SERP पर stand out करते हैं। अपने ranking के बारे में, अधिकांश जो लोग tune करते हैं वह myth है। keywords meta tag को लगभग 2009 के since ignore किया गया है। एक keyword को repeat करना ताकि वह अधिक relevant लगे detect किया जाता है और आपके खिलाफ काम करता है। Description ranking input नहीं है। जो consistently win करता है content है जो query का answer देता है, semantic markup जो structure को legible बनाता है, अन्य sites से links, और एक page जो fast और stable है load करने के लिए। इस chapter में tags एक page को presentable बनाते हैं और सही तरीके से समझे जाते हैं; वे page के rank होने के लिए worth के लिए substitute नहीं करते।
<meta name="robots" content="noindex">। यह main knob है जिसे आप इस stage पर कभी reach करेंगे, इसलिए बाकी के बारे में overthink करने की जरूरत नहीं है अभी। noindex, nofollow); अलग robots.txt file crawling को control करता है। Old keywords meta tag dead है, इसलिए इसे ignore करें। Real ranking एक clear title, semantic HTML, good links, और एक fast page से आता है, न कि एक magic tag से। robots.txt में block करना और noindex को add करना है, since crawler कभी page को fetch नहीं करता noindex को read करने के लिए। JSON-LD rich results earn करता है, एक ranking boost नहीं। Keywords meta dead है; content और semantics वह हैं जो actually win करते हैं। 
