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

Technical SEO वह लेयर है जो तय करती है कि सर्च इंजन और AI असिस्टेंट आपके पेजों को क्रॉल, रेंडर, और ट्रस्ट कर सकते हैं या नहीं, इससे पहले कि कंटेंट या बैकलिंक्स का कोई असर हो। इसमें HTTP बिहेवियर, HTML सेमेंटिक्स, स्ट्रक्चर्ड डेटा, hreflang, कैनोनिकलाइजेशन, Core Web Vitals, और JavaScript रेंडरिंग शामिल है। इसे गलत करो और बाकी सारा निवेश डेड वेट हो जाता है।

2026 में डेफिनिशन बढ़ी है। दो बदलावों ने इसे आगे बढ़ाया। पहला, AI Overviews और ChatGPT-पावर्ड सर्च अब ज्यादातर यूजर्स और अंतर्निहित पेजों के बीच बैठते हैं, जिसका मतलब है कि साइटेशन-रेडीनेस रैंकिंग जितना ही महत्वपूर्ण है। दूसरा, मोडल साइट अब WordPress इंस्टॉल नहीं है, यह हेडलेस फ्रंट-एंड की कोई वैरायटी है जो Sanity, Strapi, Payload, Storyblok, Contentful, या हेडलेस WordPress बैकएंड से कंटेंट खींचती है। इनमें से प्रत्येक स्टैक अपने स्वयं के technical SEO फेलियर मोड्स लाता है जिन्हें पुरानी प्लेबुक कवर नहीं करती।

2026 में क्लाइंट्स के लिए मेरी वर्किंग डेफिनिशन: technical SEO वह सब कुछ है जो एक Lighthouse रन, एक Search Console क्रॉल रिपोर्ट, एक AI Overview साइटेशन चेक, और एक स्कीमा वैलिडेटर नोटिस देखता है, हर लोकेल, हर टेम्पलेट, हर रेंडर पाथ भर में। अगर इन चार सिग्नल्स में से कोई एक किसी रिप्रेजेंटेटिव URL पर फेल हो रहा है, तो एनगेजमेंट वहीं से शुरू होती है।

एक हेडलेस या Jamstack साइट पर, आपका फ्रंट-एंड फ्रेमवर्क रेंडरिंग के लिए जिम्मेदार है और आपका CMS कंटेंट के लिए जिम्मेदार है, और SEO उनके बीच की खाई में गिर सकता है। क्लासिक WordPress + Yoast मॉडल एक सर्वर, एक रेंडरर, एक रूल्स इंजन मानता था। WordPress से कंटेंट निकालो Next.js या Astro में और आप ये सब ऑटोमेटिकली इनहेरिट नहीं करते।

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

सबसे आम कॉन्फ़िगरेशन जो हम 2026 में देख रहे हैं: WP REST या WPGraphQL पोस्ट्स और पेजों को एक्सपोज कर रहा है, Next.js App Router या Astro उन्हें बिल्ड टाइम पर या ISR के माध्यम से पुल कर रहा है। जीत्स असली हैं, पेजेस कोई प्लगइन ब्लोट के बिना शिप होते हैं, Core Web Vitals को ग्रीन रखना आसान है, और एडिटर्स को एक परिचित एडमिन मिलता है। पिटफॉल्स भी असली हैं। Yoast कैनोनिकल्स और मेटा डेस्क्रिप्शन्स को API बाउंड्री के पार ट्रांसपोर्ट करना पड़ता है; WordPress में डिफाइन्ड रीडायरेक्ट्स को vercel.json या Netlify _redirects में लैंड करना पड़ता है; सितेमैप्स आमतौर पर फ्रंट-एंड बिल्ड पर रीजेनरेट करने पड़ते हैं, WordPress साइड पर नहीं; और सर्च कंसोल वेरिफिकेशन को पब्लिक ऑरिजिन पर होना चाहिए, wp-admin डोमेन पर नहीं।

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

एक Next.js + Sanity बिल्ड, एक Astro + Storyblok बिल्ड, एक Nuxt + Strapi बिल्ड, एक Next.js + Payload बिल्ड, सभी WordPress को पूरी तरह स्किप करते हैं। technical SEO का काम इस बात को सुनिश्चित करने पर शिफ्ट हो जाता है कि आपका CMS स्कीमा SEO फील्ड्स को मॉडल करता है जिनकी फ्रंट-एंड को जरूरत है (कैनोनिकल ओवरराइड, रीडायरेक्ट मैप, hreflang ग्रुप, स्कीमा-एक्सटेंशन JSON), और यह सुनिश्चित करने पर कि ऑन-डिमांड रीवैलिडेशन कंटेंट बदलने पर ट्रिगर होता है। ISR कैश पॉइजनिंग साइलेंट किलर है, एक पेज पब्लिश के घंटों बाद स्टेल सर्व होता है क्योंकि revalidatePath कभी वायर अप नहीं हुआ था।

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

करीब 200 हेडलेस ऑडिट्स जो हमने रन किए हैं, सबसे आम प्रोडक्शन-ब्रेकिंग इश्यू कैनोनिकल कॉन्फ्लिक्ट है, फ्रंट-एंड एक कैनोनिकल URL एमिट कर रहा है जबकि CMS मेटाडेटा या सितेमैप दूसरा एमिट कर रहा है। Google एक को पिक करता है, लगभग हमेशा वह नहीं जिसे आप चाहते थे, और गलत URL इंडेक्स में खत्म हो जाता है। हम इसे एक बिल्ड-टाइम लिंटर से कैच करते हैं जो कैनोनिकल-एमिटेड-फ्रॉम-टेम्पलेट को कैनोनिकल-स्टोर्ड-इन-CMS के खिलाफ पेजों के एक सैम्पल के लिए तुलना करता है और मिसमैच पर बिल्ड को फेल करता है।

WordPress आपको सबसे ज्यादा प्लगइन फायरपावर और अपने आप को शूट करने के सबसे ज्यादा तरीके देता है। एक क्लासिक WordPress साइट पर technical SEO प्लेबुक ज्यादातर सबट्रैक्शन के बारे में है, डुप्लिकेट कैनोनिकल्स निकालना, Yoast और RankMath और किसी तीसरे प्लगइन के बीच स्कीमा फाइट्स को मारना जिसे कोई याद नहीं करता कि इंस्टॉल किया, पेज बिल्डर्स को तामना जो 2 MB CSS शिप करते हैं, और रीडायरेक्ट चेन्स को क्लीयर करना जो आठ साल तक बढ़ी हैं।

वह 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 नहीं है, तो मेटा क्लैम्पिंग को बनाना पड़ता है। कोई प्लगइन स्कीमा नहीं है, तो JSON-LD को टेम्पलेट किया जाना चाहिए। कोई बिल्ट-इन सितेमैप नहीं है, तो इसे जेनरेट और स्ट्रीम किया जाना चाहिए। SEO के लिए एक हेडलेस प्रोजेक्ट में जो कोड वॉल्यूम हम ऐड करते हैं वह आमतौर पर एक WordPress साइट जो पहले से ही फ्री देता है उसका तीन से पांच गुना है, लेकिन वह कोड ओन्ड है, वर्जन-कंट्रोल्ड है, टेस्टेबल है, और अगली प्लगइन अपडेट पर ब्रेक नहीं होता।

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

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

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

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

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

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

• Organization, आपके layout में एक single sitewide ग्राफ, logo, sameAs (सिर्फ real social accounts), address, और contactPoint के साथ। इसे कभी हर पेज पर duplicate न करें।
• WebSite, एक बार, layout में, potentialAction के साथ sitelinks search के लिए अगर आपके पास on-site search है।
• BreadcrumbList, हर non-home पेज पर, locale-correct URLs के साथ (एक फ्रेंच पेज को /en/ ancestors की बजाय /fr/ ancestors को point करना चाहिए)।
• Article या BlogPosting, long-form content पर, entity-graph reinforcement के लिए about और mentions arrays के साथ।
• Service, commercial pages पर, serviceType, provider, areaServed, audience, और offers.priceSpecification के साथ जब आप कोई price range publish कर सकें।
• Product, ecommerce पर, offers.priceCurrency, availability, और aggregateRating के साथ सिर्फ अगर आपके पास real reviews हों।
• FAQPage, जब पेज पर कम से कम दो genuine सवाल हों। Schema markup जीतने के लिए fake FAQs बनाना सबसे common manual-action trigger है जिसे हम साफ़ करते हैं।
• LocalBusiness या इसके किसी subtypes को physical-location pages पर use करें, geo coordinates और openingHoursSpecification के साथ।

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

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

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

हर translatable row पर एक content_group_id (या equivalent) store करें। एक page के सभी locale variants एक ही ID share करते हैं। hreflang emitter, sitemap emitter, और canonical emitter सभी अपना cluster इसी ID से derive करते हैं। कभी भी URL pattern matching से alone hreflang compute न करें, यह edge cases पर टूट जाता है (एक Spanish page जिसका Hindi translation नहीं है, आपके code को break कर देगा अगर वह "अगर pageX locale A में है, तो B में भी है" assume करे)।

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

तीन patterns जो हम repeatedly देखते हैं। Locale regex ordering, आपके locale detection regex में "zh" को "zh-Hant" से पहले रखना, जो गलत locale को capture करता है और broken hreflang लिखता है। x-default को भूलना, हर cluster को एक x-default fallback की जरूरत है, आमतौर पर English version की ओर pointing करता है। Cluster ID drift, एक translation को source ID को inherit करने की जगह एक नया ID मिल जाता है, silently एक single cluster को दो unrelated clusters में split कर देता है, दोनों के पास ही full reciprocal set नहीं होता।

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

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

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

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

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

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

हम उस operating playbook को client programmatic builds में लाते हैं, Next.js या Astro front-end, Supabase या Postgres data, एक ingest pipeline जो pages को publish से पहले uniqueness पर score करता है, एक sitemap जो chunks में stream करता है क्योंकि 50,000 URLs से ज्यादा एक single sitemap.xml में fit नहीं हो सकते, और एक internal-link graph जो हर leaf को एक topical cluster में खींचता है।

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

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

LCP लगभग हमेशा hero image होता है और लगभग हमेशा WebP पर 80% quality पर re-encode करके, actual display dimensions plus 2x retina के लिए size करके, head में एक preload tag add करके, और fetchpriority="high" set करके solve होता है। एक 1 MB hero image जो 30 KB WebP बन जाता है, यह most projects पर single highest-impact change है। CLS images और ads से आता है जिनके पास explicit dimensions नहीं हैं, हर image पर explicit width और height attributes, fixed-height ad slots, और किसी भी client-side widget के लिए reserved space। INP heavy JavaScript से interaction पर आता है, आमतौर पर एक third-party tag manager या एक over-eager analytics library। Fix debouncing, lazy-loading, या एक lighter equivalent से replace करना है।

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

दो patterns। पहला, एक LCP image एक Carousel component या एक JavaScript-driven layout के अंदर, image केवल JS run करने के बाद render होता है, और आपका LCP carousel का loading skeleton है, photo नहीं। दूसरा, web fonts loaded हैं font-display: swap के बिना और preload के बिना, text 200-400 ms के लिए invisible है जबकि fonts download होते हैं, और आपका LCP 2.5 s threshold के पास push हो जाता है भले ही image fast हो। दोनों एक CrUX field-data review से caught होते हैं, न कि एक single Lighthouse run से।

एक 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 के last step के रूप में चलता है। कोई भी violation build को fail करता है, जो deploy को fail करता है। इसके बिना, हर regression, एक meta description जो limit के ऊपर बढ़ गया, एक SEO field जिसे किसी ने set करना भूल गया, एक schema emitter जो break हुआ जब एक property rename हुई, silently ship करता है। इसके साथ, regression को developer के laptop से बाहर निकलने से पहले catch कर लिया जाता है।

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

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

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

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

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

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

हम ऐसे तकनीकी SEO की बुनियाद बनाते हैं जो UK Government Digital Service Standard और GOV.UK Design System के साथ संरेखित हो। GDS Service Standard सार्वजनिक प्रांत में सबसे कठोरता से प्रलेखित डिजिटल-सेवा गुणवत्ता सिद्धांतों का समूह है: प्रगतिशील वर्द्धन, WCAG 2.2 AA तक पहुंच, प्रदर्शन, सिमैंटिक HTML, और JavaScript विफल होने पर सुंदर अपह्रास। हम Seahawk की हर तकनीकी 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 से अलग करता है जो निम्न मान तक पहुंचाते हैं।

तीन से दस सप्ताह, तीन चरण, निर्धारित मूल्य। चरण एक ऑडिट है, पूर्ण क्रॉल, GSC और Ahrefs समीक्षा, JSON-LD सत्यापन, hreflang क्लस्टर जांच, Core Web Vitals क्षेत्र-डेटा पुल, AI उद्धरण बेसलाइन। चरण दो उपचार है, हम सुधार प्रदान करते हैं, आपकी टीम या हमारी। चरण तीन linter और निगरानी परत है जो प्रतिगमन को रोकता है।

audit चरण deliverables

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

उपचार चरण

निश्चित दायरे का काम। हर टिकट की एक स्पष्ट शुरुआती अवस्था और अंतिम अवस्था है। हम उन्हें प्राथमिकता के क्रम में रिलीज़ करते हैं और आप बजट खत्म हो जाने पर किसी भी मील के पत्थर पर एनगेजमेंट बंद कर सकते हैं। पहला बैच जो हम रिलीज़ करते हैं वह हमेशा वह आइटम्स होते हैं जो build linter को फेल करते हैं — इनका value तक पहुँचना सबसे कम समय लेता है क्योंकि linter के बिना ये बार-बार रिग्रेस होते रहेंगे, और एक बार linter लग जाने के बाद, हर fix स्थायी रहता है।

निगरानी चरण

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