तकनीकी SEO जो AI Overviews, headless rebuilds, और आपके अगले algorithm update को survive करे।

तकनीकी SEO वह layer है जो तय करता है कि search engines और AI assistants आपके pages को crawl, render, और trust कर सकें — content या backlinks का कोई असर होने से पहले। यह HTTP behaviour, HTML semantics, structured data, hreflang, canonicalisation, Core Web Vitals, और JavaScript rendering को cover करता है। इसे गलत करो और बाकी का पूरा investment व्यर्थ है।

2026 में definition बढ़ गई है। दो बदलावों ने इसे push किया। पहला, AI Overviews और ChatGPT-powered search अब ज्यादातर users और underlying pages के बीच बैठते हैं, जिसका मतलब citation-readiness ranking जितना ही जरूरी है। दूसरा, modal site अब WordPress install नहीं है — यह कोई न कोई headless front-end है जो Sanity, Strapi, Payload, Storyblok, Contentful, या headless WordPress backend से content pull करता है। उन में से हर stack अपने technical SEO failure modes introduce करता है जो पुराने playbook में cover नहीं है।

2026 में clients के लिए मेरी working definition: तकनीकी SEO वह सब कुछ है जो एक Lighthouse run, एक Search Console crawl report, एक AI Overview citation check, और एक schema validator notice देखते हैं — हर locale, हर template, हर render path में। अगर किसी representative URL पर ये चारों signals में से कोई एक fail हो रहा है, तो engagement वहीं से शुरू होती है।

हेडलेस या Jamstack साइट पर, आपका फ्रंट-एंड फ्रेमवर्क रेंडरिंग को नियंत्रित करता है और आपका CMS कंटेंट को नियंत्रित करता है — और SEO उनके बीच के अंतराल में गिर सकता है। क्लासिक WordPress + Yoast मॉडल एक सर्वर, एक रेंडरर, एक rules engine मानता था। WordPress से कंटेंट को Next.js या Astro में निकालें और आप स्वचालित रूप से इनमें से कुछ भी विरासत में नहीं पाते।

Headless WordPress को Next.js या Astro के साथ जोड़ा गया

2026 में हम जो सबसे आम कॉन्फ़िगरेशन देख रहे हैं: WP REST या WPGraphQL पोस्ट और पेज को expose कर रहे हैं, Next.js App Router या Astro बिल्ड टाइम पर या ISR के माध्यम से उन्हें pull कर रहे हैं। जीत वास्तविक हैं — पेज कोई प्लगइन bloat के बिना ship होते हैं, Core Web Vitals को हरा रखना आसान है, और एडिटर एक परिचित admin को बनाए रखते हैं। नुकसान भी वास्तविक हैं। Yoast canonicals और meta descriptions को API boundary के पार ले जाने की जरूरत है; WordPress में परिभाषित redirects को vercel.json या Netlify _redirects में उतरने की जरूरत है; sitemaps आमतौर पर WordPress की ओर से नहीं, फ्रंट-एंड बिल्ड पर regenerate करने की जरूरत है; और search console verification को wp-admin डोमेन पर नहीं, सार्वजनिक origin पर होने की जरूरत है।

शुद्ध आधुनिक stacks

एक Next.js + Sanity बिल्ड, एक Astro + Storyblok बिल्ड, एक Nuxt + Strapi बिल्ड, एक Next.js + Payload बिल्ड — सभी WordPress को पूरी तरह skip करते हैं। तकनीकी SEO का काम यह सुनिश्चित करने में बदल जाता है कि आपका CMS schema उन SEO fields को मॉडल करता है जिनकी फ्रंट-एंड को जरूरत है (canonical override, redirect map, hreflang group, schema-extension JSON), और on-demand revalidation को trigger करने के लिए सुनिश्चित करता है जब कंटेंट बदलता है। ISR cache poisoning silent killer है — एक पेज publish के बाद घंटों तक stale serve होता है क्योंकि revalidatePath कभी wire नहीं किया गया था।

वास्तव में पहले क्या टूटता है

लगभग 200 headless audits में जो हमने run किए हैं, सिंगल सबसे आम production-breaking issue canonical conflict है — फ्रंट-एंड एक canonical URL emit कर रहा है जबकि CMS metadata या sitemap दूसरा emit कर रहा है। Google एक को pick करता है, लगभग हमेशा वह नहीं जो आप चाहते थे, और गलत URL index में खत्म हो जाता है। हम इसे build-time linter के साथ पकड़ते हैं जो canonical-emitted-from-template को canonical-stored-in-CMS के विरुद्ध पेजों के एक sample के लिए compare करता है और mismatch पर बिल्ड को fail करता है।

WordPress आपको सबसे ज्यादा प्लगइन firepower और अपने आप को shoot करने के सबसे ज्यादा तरीके देता है। क्लासिक WordPress साइट पर तकनीकी SEO playbook ज्यादातर subtraction के बारे में है — duplicate canonicals को हटाना, Yoast और RankMath और किसी third plugin के बीच schema fights को kill करना जिसे कोई भी install करते हुए याद नहीं रखता, page builders को tame करना जो 2 MB CSS ship करते हैं, और redirect chains को clear करना जो आठ साल के लिए बढ़ गई हैं।

वह default stack जिसकी हम 2026 में recommend करते हैं: एक single SEO प्लगइन (RankMath या Yoast, कभी दोनों नहीं), एक managed host जिसमें proper edge caching है (Cloudways, Kinsta, WP Engine), Bricks Builder नई builds के लिए जहां performance मायने रखती है या native Gutenberg with Kadence या Blocksy, एक redirect manager जो portable format में export करता है, और Perfmatters या FlyingPress asset cleanup के लिए। audit का काम यह खोजना है कि उन decisions में से कौन से आपकी साइट पर अलग तरीके से किए गए थे और परिणामों को unwind करना है।

हेडलेस साइड पर, काम घटाव से निर्माण की ओर बढ़ता है। कोई Yoast नहीं है, इसलिए meta clamping को बनाना पड़ता है। कोई plugin schema नहीं है, इसलिए JSON-LD को template करना पड़ता है। कोई built-in sitemap नहीं है, इसलिए इसे generate और stream करना पड़ता है। SEO के लिए जो code हम एक headless project में जोड़ते हैं, वह आमतौर पर उतना है जितना एक WordPress साइट पहले से ही free में आपको देती है — लेकिन वह code owned है, version-controlled है, testable है, और next plugin update पर टूटता नहीं है।

GEO और AEO दो अलग तरीकों के नाम हैं जिनसे AI features search traffic को खाते हैं। AEO (Answer Engine Optimisation) पुराना शब्द है — इसमें Google की features जैसे Featured Snippets, People Also Ask, और Knowledge Panels शामिल हैं जो आपके पेज से एक passage निकालते हैं और इसे answer के रूप में दिखाते हैं। GEO (Generative Engine Optimisation) नया शब्द है — AI Overviews, ChatGPT search, Perplexity, और Bing Copilot के लिए optimize करना, जहाँ assistant एक paragraph generate करता है और आपके पेज को source के रूप में cite करता है।

संरचनात्मक दृष्टि से इसका मतलब क्या है

दोनों surfaces एक ही चीज़ चाहते हैं: एक citation-ready passage। संरचनात्मक नियम जो सभी में जीतते हैं वही हैं। अपने H2 के लिए topic label की जगह question का उपयोग करें। answer को heading के बाद के पहले एक या दो sentences में रखें। उस answer को 250 शब्दों के अंदर रखें। यह सुनिश्चित करें कि answer server-side render हो, न कि JavaScript component के अंदर जो page load के बाद hydrate होता है। AI crawlers और Google extractors ज़्यादातर JavaScript चलाते नहीं हैं — अगर आपका answer को JS की ज़रूरत है दिखने के लिए, तो आप invisible हैं।

GEO कहाँ AEO से अलग होता है

GEO के लिए विशेष रूप से तीन चीज़ें मायने रखती हैं। Entity authority — Google और LLMs एक graph बनाते हैं कि कौन किस बारे में बात कर सकता है, और unlinked brand mentions इसे feed करते हैं। Schema with about और mentions arrays — ये आपके पेज को एक entity graph का हिस्सा बनाते हैं, न कि text की दीवार। और llms.txt — /llms.txt पर एक उभरता हुआ standard file जो AI tools को आपकी साइट का एक curated map देता है, जिस तरह robots.txt और sitemap.xml search crawlers की मदद करते हैं। हम जो साइट बनाते हैं उसमें हर एक पर llms.txt deploy करते हैं और जब कोई major page लैंड होता है तो इसे update करते हैं।

आपको ज़्यादातर plugins से कम schema types की ज़रूरत है, लेकिन जो आप ship करते हैं वह valid और consistent होने चाहिए। एक छोटी सी list नौ में से दस projects को cover करती है।

• Organization — आपके layout में एक single sitewide graph, जिसमें logo, sameAs (केवल real social accounts), address, और contactPoint हो। इसे कभी भी per page duplicate न करें।
• WebSite — लेआउट में एक बार, यदि आपके पास ऑन-साइट सर्च है तो sitelinks search के लिए potentialAction के साथ।
• BreadcrumbList — हर गैर-होम पेज पर, लोकेल-सही URL के साथ (एक फ्रेंच पेज को /en/ के बजाय /fr/ पूर्वजों की ओर इशारा करना चाहिए)।
• Article या BlogPosting — लंबे-फॉर्म कंटेंट पर, entity-graph सुदृढ़ीकरण के लिए about और mentions arrays के साथ।
• Service — वाणिज्यिक पेजों पर, serviceType, provider, areaServed, audience, और जब आप कीमत सीमा प्रकाशित कर सकते हैं तो offers.priceSpecification के साथ।
• Product — ई-कॉमर्स पर, offers.priceCurrency, availability, और aggregateRating के साथ केवल यदि आपके पास वास्तविक समीक्षाएं हों।
• FAQPage — जब पेज पर कम से कम दो वास्तविक प्रश्न हों। स्कीमा मार्कअप जीतने के लिए FAQ बनाना सबसे आम manual-action trigger है जिसे हम साफ करते हैं।
• LocalBusiness या इसके सबटाइप — भौतिक-स्थान पेजों पर, geo निर्देशांक और openingHoursSpecification के साथ।

तीन चीजें प्रोडक्शन में स्कीमा को नष्ट करती हैं। ऐसे गुण बनाना जो schema.org परिभाषित नहीं करता। sameAs के लिए नकली मान बनाना (नकली LinkedIn URL, परित्यक्त Twitter हैंडल)। और कई प्लगइन से विरोधाभासी Organization ग्राफ जहाज़ पर लाना। हम बिल्ड लिंटर में स्कीमा वेलिडेटर चलाते हैं और इन तीनों पैटर्न में से किसी पर भी बिल्ड विफल करते हैं।

Hreflang स्केल पर विफल हो जाता है क्योंकि बाध्यता द्विदिशात्मक है और डेटासेट विरल है। किसी पेज के प्रत्येक लोकेल वेरिएंट को स्व-संदर्भ होना चाहिए, हर दूसरे वेरिएंट को संदर्भित करना चाहिए, और हर दूसरे वेरिएंट द्वारा वापस संदर्भित होना चाहिए। एक लोकेल में एक पेज पर एक दिशा मिस करें और Google चुप-चाप क्लस्टर को डाउनग्रेड करता है।

वह पैटर्न जो स्केल करता है

हर अनुवादयोग्य पंक्ति पर एक content_group_id (या समतुल्य) स्टोर करें। किसी पेज के सभी लोकेल वेरिएंट एक ID शेयर करते हैं। hreflang एमिटर, sitemap एमिटर, और canonical एमिटर सभी अपना क्लस्टर उस ID से निकालते हैं। कभी भी URL पैटर्न मिलान से अकेले hreflang की गणना न करें — यह edge cases पर टूट जाता है (एक Spanish पेज जिसका कोई Hindi अनुवाद नहीं है, क्लस्टर को तोड़ देगा अगर आपका कोड मानता है कि "अगर पेज X लोकेल A में मौजूद है, तो यह B में भी है")।

hreflang को व्यावहारिक रूप से क्या मारता है

तीन पैटर्न जो हम बार-बार देखते हैं। Locale regex ऑर्डरिंग — आपके locale detection regex में "zh" को "zh-Hant" से पहले रखना, जो गलत locale को कैप्चर करता है और broken hreflang लिखता है। x-default भूलना — हर क्लस्टर को एक x-default fallback की जरूरत है, आमतौर पर English संस्करण की ओर इशारा करता है। Cluster ID drift — एक अनुवाद को source ID को inherit करने की बजाय एक नया ID मिलता है, चुपचाप एक single क्लस्टर को दो असंबंधित क्लस्टर में विभाजित करता है, जिनमें से कोई भी पूर्ण reciprocal set नहीं रखता।

हम हमेशा एक build-time hreflang linter जोड़ते हैं जो पेजों के एक नमूने को crawl करता है, जिन hreflang क्लस्टर्स का वे संदर्भ देते हैं उन्हें walk करता है, और अगर कोई क्लस्टर incomplete या asymmetric है तो build को fail करता है।

प्रोग्रामेटिक SEO एक structured data source और एक template से हजारों पेज generate करना है — directories, comparison pages, location pages, glossary pages। सही तरीके से किया जाए तो यह single-author content नहीं match कर सकता लंबी tail को scale पर hit कर सकता है। गलत तरीके से किया जाए तो यह एक manual action trigger करता है और रातों-रात आपके ज्यादातर indexed पेजों को हटा देता है।

एक clean programmatic build को thin-content वाले से क्या अलग करता है

तीन चीजें। हर पेज पर real data — हर URL के पास कम से कम एक fact, number, या detail है जो उसके लिए अनोखा है; thin programmatic pages अपने content का 95% शेयर करते हैं। एक meaningful template — template unique data के चारों ओर context, comparison, recommendation, या aggregation जोड़ता है, सिर्फ एक search-optimised wrapper नहीं। और quality gating — insufficient unique data वाले पेजों को sitemap से रखा जाता है, index से blocked किया जाता है, या draft state में रखा जाता है जब तक data layer fill नहीं हो जाता।

इसे scale पर चलाने से हमने क्या सीखा है

मैंने HostList.io को एक प्रोग्रामेटिक SEO प्लेटफॉर्म के रूप में बनाया है जिसमें Next.js और Supabase पर लगभग 28,000 वेब होस्टिंग कंपनी के पेज हैं। जो पेज Google के दो साल के अपडेट को सहते रहे, वे वही थे जिनके पास प्रत्येक URL के लिए कम से कम तीन यूनिक डेटा पॉइंट थे, साथ ही एक टेम्प्लेट जो उस डेटा के आधार पर तुलना, स्कोरिंग या सिफारिश करता था। जिन पेज को हमने de-index किया, वे थे जहां यूनिक डेटा सिर्फ एक नाम और कीमत था। पतले पेजों को इंडेक्स से निकालने की कीमत कम थी; उन्हें छोड़ने की कीमत मार्च 2024 के helpful content अपडेट आने पर साइटव्यापी रैंकिंग पेनल्टी थी।

हम वह ऑपरेटिंग प्लेबुक क्लाइंट प्रोग्रामेटिक बिल्ड्स में लाते हैं — Next.js या Astro फ्रंट-एंड, Supabase या Postgres डेटा, एक इनजेस्ट पाइपलाइन जो पेजों को पब्लिश से पहले यूनिकनेस पर स्कोर करती है, एक साइटमैप जो चंक्स में स्ट्रीम करता है क्योंकि 50,000 से अधिक URL एक एकल sitemap.xml में फिट नहीं हो सकते, और एक इंटरनल-लिंक ग्राफ जो हर लीफ को एक टॉपिकल क्लस्टर में खींचता है।

फील्ड डेटा के 75वें पर्सेंटाइल पर Core Web Vitals पास करें, कंट्रोल्ड लैब Lighthouse रन में नहीं। CrUX से फील्ड डेटा वह है जो Google उपयोग करता है; Lighthouse एक डीबगिंग टूल है। दोनों अक्सर रीयल साइट्स पर 30% या उससे अधिक से असहमत होते हैं।

बजट वास्तव में कहां जाता है

LCP लगभग हमेशा हीरो इमेज है और लगभग हमेशा WebP को 80% क्वालिटी पर फिर से एन्कोड करके, असली डिस्प्ले डाइमेंशन्स प्लस 2x रेटिना में साइज करके, head में एक preload टैग जोड़कर, और fetchpriority="high" सेट करके हल हो जाता है। 1 MB हीरो इमेज जो 30 KB WebP बन जाता है, वह अधिकांश प्रोजेक्ट्स पर सबसे अधिक प्रभाव वाला एकल परिवर्तन है। CLS इमेज और ads से आता है जिनके पास explicit dimensions नहीं हैं — हर इमेज पर explicit width और height attributes, फिक्स्ड-हाइट ad slots, और किसी भी क्लाइंट-साइड widget के लिए रिज़र्व्ड स्पेस। INP interaction पर भारी JavaScript से आता है — आमतौर पर एक third-party tag manager या एक over-eager analytics library। फिक्स debouncing, lazy-loading, या एक हल्के equivalent से बदलना है।

अधिकांश प्रोजेक्ट्स कहां मिस करते हैं

दो पैटर्न। पहला, Carousel component या एक JavaScript-driven layout के अंदर एक LCP इमेज — इमेज सिर्फ JS चलने के बाद render होती है, और आपका LCP carousel का loading skeleton है, फोटो नहीं। दूसरा, वेब फॉन्ट्स लोड किए गए हैं font-display: swap के बिना और preload के बिना — जबकि फॉन्ट्स डाउनलोड हो रहे हैं, टेक्स्ट 200-400 ms के लिए invisible है, और आपका LCP 2.5 s थ्रेशहोल्ड पास हो जाता है, भले ही इमेज तेज़ हो। दोनों एक CrUX फील्ड-डेटा रिव्यू द्वारा पकड़े जाते हैं, एक एकल Lighthouse रन से नहीं।

एक build-time SEO linter एक स्क्रिप्ट है जो आपकी बिल्ड के अंत में चलती है, आउटपुट डायरेक्टरी से render किए गए HTML फाइलों के एक स्लाइस को सैंपल करती है, और अगर उसे ऐसे पैटर्न मिलते हैं जो प्रोडक्शन में SEO को degrade करेंगे तो बिल्ड को fail करती है। यह क्लाइंट कोडबेसेस में जोड़ने के लिए सबसे अधिक प्रभाव वाली आदत है।

हमारी जांचें क्या करती हैं

• हर पेज का एक्जैक्ट एक H1 होता है।
• हर indexable URL पर Meta description 120 से 155 characters के बीच होना चाहिए।
• html lang attribute, locale path से मेल खाता है (एक /fr/ पेज का lang="fr" होता है)।
• Hreflang clusters translatable routes पर complete और bidirectional होते हैं।
• हर पेज पर JSON-LD schema.org definitions के विरुद्ध valid होता है।
• कोई banned content patterns नहीं — sameAs में fake social URLs, hardcoded test placeholder text, banned generic copywriting words।
• Template द्वारा emitted Canonical URL, CMS में stored canonical से मेल खाता है।
• Image WebP और explicit dimensions की जांच templates के एक sample पर।

Linter npm run build के आखिरी step के रूप में चलता है। कोई भी violation build को fail करता है, जो deploy को fail करता है। इसके बिना, हर regression — एक meta description जो limit से बड़ा हो गया, एक SEO field जिसे किसी ने सेट करना भूल गया, एक schema emitter जो property के rename होने पर टूट गया — चुपचाप ship हो जाता है। इसके साथ, regression developer के laptop को छोड़ने से पहले ही पकड़ा जाता है।

हर प्रासंगिक पेज को उद्धरण के लिए तैयार अंशों के स्टैक के रूप में लिखकर उद्धृत किए जाएं। उद्धरण-तैयार अंश एक H2 प्रश्न-रूप है, तुरंत बाद में एक सीधा एक या दो वाक्य का उत्तर है, अगले 100-200 शब्दों के लिए सहायक बारीकियां हैं, और उत्तर ब्लॉक में कोई JavaScript-रेंडर की गई सामग्री नहीं है। AI एक्सट्रैक्टर उस उद्घाटन वाक्य को उठाते हैं और पेज का हवाला देते हैं।

अंश संरचना से परे क्या मदद करता है

• एंटिटी प्राधिकार — Wikipedia उपस्थिति, सुसंगत organisation schema, असली sameAs खाते, खुली वेब में ब्रांड उल्लेख।
• साइट रूट पर llms.txt — AI टूल के लिए साइट का एक क्यूरेटेड मानचित्र, जो पारंपरिक क्रॉलर को सेवा देने वाले robots.txt और sitemap.xml से अलग है।
• लंबे-रूप सामग्री पर about और mentions के साथ Schema — इस बात को घोषित करता है कि पेज किस एंटिटी ग्राफ के अंदर है।
• AI-क्रॉलर robots.txt अनुमति सूची — स्पष्ट रूप से GPTBot, PerplexityBot, ClaudeBot, OAI-SearchBot, Google-Extended, Applebot-Extended, CCBot, और Anthropic-AI को अनुमति दें। इनमें से किसी को भी ब्लॉक करना आत्म-निर्मित उद्धरण आउटेज है।
• लंबे-रूप पेजों के उत्तर-समृद्ध अनुभागों पर Speakable schema प्रॉपर्टी — वॉइस और AI एक्सट्रैक्टर के लिए एक संकेत कि यह उद्धरण योग्य अंश है।

उद्धरणों को ट्रैक करना वह हिस्सा है जिसे अधिकांश टीमें छोड़ देती हैं। Otterly, Profound, और AthenaHQ डोमेन द्वारा AI Overview और Perplexity उद्धरण शेयर को ट्रैक करते हैं। हम हर engagement के शीर्ष पर साप्ताहिक उद्धरण ट्रैकिंग जोड़ते हैं और इसे organic traffic के साथ रिपोर्ट करते हैं। यदि आप उद्धरणों को माप नहीं रहे हैं तो आप यह नहीं बता सकते कि आपका GEO कार्य कुछ कर रहा है या नहीं।

AI crawlers आपकी साइट को केवल तभी पढ़ सकते हैं जब आपकी robots.txt उनके user-agent को स्पष्ट रूप से अनुमति दे और आपकी होस्टिंग लेयर उन्हें नेटवर्क edge पर ब्लॉक न करे। दोनों जांचें पास होनी चाहिए। डिफ़ॉल्ट Cloudflare सेटिंग्स, डिफ़ॉल्ट Vercel WAF नियम, और डिफ़ॉल्ट WordPress सुरक्षा प्लगइन अक्सर बिना किसी चेतावनी के AI बॉट्स को ब्लॉक करते हैं।

robots.txt allow-list जो हम शिप करते हैं

GPTBot और ChatGPT-User और OAI-SearchBot ChatGPT और OpenAI सर्च प्रोडक्ट्स के लिए। PerplexityBot और Perplexity-User। ClaudeBot और Claude-Web और anthropic-ai। Google-Extended Bard और AI Overviews के लिए। Applebot-Extended। CCBot Common Crawl के लिए, जो कई ओपन-सोर्स मॉडल्स को फीड करता है। Cohere-AI। Meta-ExternalAgent। Bytespider — TikTok का crawler — आमतौर पर ब्लॉक किया जाता है क्योंकि यह आक्रामक है और अधिकांश प्रोजेक्ट्स नहीं चाहते कि TikTok उनकी content उठाए।

आपको और क्या करना है

Robots.txt आवश्यक है लेकिन पर्याप्त नहीं है। तीन अन्य जांचें। Cloudflare bot fight mode और bot management — जो AI agents को ब्लॉक करते हैं उन्हें बंद करें, या IP और user-agent के आधार पर whitelist करें। Vercel WAF और Edge Middleware — सुनिश्चित करें कि वे generic regex पर AI user agents से match न करें। WordPress सुरक्षा प्लगइन्स जैसे Wordfence — वे अक्सर ऐसे नियम के साथ आते हैं जो डिफ़ॉल्ट रूप से GPTBot और PerplexityBot को ब्लॉक करते हैं; स्पष्ट रूप से whitelist करें। तीन प्रतिनिधि URLs के विरुद्ध प्रत्येक user agent को curl करके और 200 response की पुष्टि करके परीक्षण करें।

हम ऐसे तकनीकी SEO की बुनियाद बनाते हैं जो UK Government Digital Service Standard और GOV.UK Design System के साथ संरेखित हो। GDS Service Standard सार्वजनिक प्रांत में सबसे कठोरता से प्रलेखित डिजिटल-सेवा गुणवत्ता सिद्धांतों का समूह है: प्रगतिशील वर्द्धन, WCAG 2.2 AA तक पहुंच, प्रदर्शन, सिमैंटिक HTML, और JavaScript विफल होने पर सुंदर अपह्रास। हम Seahawk की हर तकनीकी SEO engagement पर इसका पालन करते हैं।Government Digital Service Standard and the GOV.UK Design System. The GDS Service Standard is the most rigorously documented set of digital-service quality principles in the public domain: progressive enhancement, accessibility to WCAG 2.2 AA, performance, semantic HTML, and graceful degradation when JavaScript fails. We follow it on every Seahawk technical SEO engagement.

SEO के लिए विशेष रूप से यह क्यों महत्वपूर्ण है: GDS-संरेखित साइटें Core Web Vitals को लगातार पास करती हैं, classic organic में अच्छी रैंक करती हैं, और AI Overview citation के लिए विशिष्ट रूप से उपयुक्त हैं क्योंकि GDS जो संरचनात्मक स्पष्टता मांगता है वही संरचनात्मक स्पष्टता है जो AI सर्फेस निकालता है। यह मानक AI search युग से पहले का है लेकिन इसके साथ बिल्कुल मेल खाता है।

UK enterprise, public sector, और regulated-industry clients के लिए, GDS alignment एक वास्तविक procurement signal है। बाकी सभी के लिए, यह एक गुणवत्ता marker है जो काम को उन agencies से अलग करता है जो निम्न मान तक पहुंचाते हैं।

तीन से दस हफ्ते, तीन चरण, fixed price। चरण एक है audit — पूर्ण crawl, GSC और Ahrefs समीक्षा, JSON-LD validation, hreflang cluster check, Core Web Vitals field-data pull, AI citation baseline। चरण दो है remediation — हम fixes ship करते हैं, आपकी टीम या हमारी। चरण तीन है linter और monitoring layer जो regressions को रोकता है।

audit चरण deliverables

• Screaming Frog का पूर्ण crawl CSV में साथ ही उन मुद्दों पर एक लिखित brief जो महत्वपूर्ण हैं, impact द्वारा ranked।
• Search Console export — coverage report, queries, page-level performance — जो कि anomalous है उस पर annotations के साथ।
• templates के एक नमूने पर Schema validator pass और हर उस type पर एक लिखित note जो broken या missing है।
• अनुवादयोग्य रूट्स पर Hreflang क्लस्टर इंटीग्रिटी रिपोर्ट।
• CrUX से Core Web Vitals फील्ड-डेटा पुल, पिछले 25 हफ्तों का प्रति मीट्रिक चार्ट सहित।
• AI Overview और Perplexity साइटेशन बेसलाइन — वर्तमान शेयर, तीन नामित प्रतियोगियों के विरुद्ध गैप विश्लेषण।

उपचार चरण

निश्चित-स्कोप कार्य। प्रत्येक टिकट का एक स्पष्ट पहले-की-स्थिति और बाद-की-स्थिति होती है। हम उन्हें प्राथमिकता क्रम में शिप करते हैं और यदि बजट समाप्त हो जाए तो आप किसी भी माइलस्टोन पर एनगेजमेंट रोक सकते हैं। जो पहला बैच हम शिप करते हैं वह हमेशा वे आइटम होते हैं जो बिल्ड लिंटर में विफल होते हैं — उनका मूल्य का रास्ता सबसे छोटा होता है क्योंकि वे लिंटर के बिना फिर से रिग्रेस होते रहेंगे, और एक बार लिंटर चालू हो जाने के बाद, हर फिक्स स्टिक रहता है।

निगरानी चरण

स्टेजिंग और प्रोडक्शन पर साप्ताहिक स्वचालित लिंटिंग, मासिक Core Web Vitals रिपोर्ट, मासिक AI साइटेशन ट्रैकिंग, और एक सक्रिय Slack चैनल जहां मैं Google या आपकी टीम द्वारा फ्लैग किए गए कुछ भी का जवाब देता हूं। हम क्लोज पर डैशबोर्ड हैंड ऑफ करते हैं ताकि आप यह विजिबिलिटी रखें कि आप नवीनीकरण करें या नहीं।