एक क्लाइंट ने मुझे एक साइट भेजी थी जिसे "एक प्रोफेशनल एजेंसी द्वारा SEO-optimize" किया गया था 18 महीने के लिए। रैंकिंग flat थी। ट्रैफिक साल-दर-साल कम था। एजेंसी की रिपोर्ट 47 पेज लंबी थी और इसमें "brand voice alignment" पर एक सेक्शन था। जो इसमें शामिल नहीं था वह यह तथ्य था कि 3,400 पेज 200 status codes रिटर्न कर रहे थे लेकिन उनके मेटा में noindex टैग बेक किए हुए थे। तीन और आधा हजार पेज। गायब। अदृश्य। एजेंसी ने कभी भी साइट को क्रॉल नहीं किया।
मैंने इसे एक हफ्ते में ठीक कर दिया। Screaming Frog और Google Search Console के साथ।
Technical SEO के बारे में यह बात है — यह उन लोगों को reward देता है जो वास्तव में डेटा को देखते हैं उसके बारे में बात करने के बजाय। और ईमानदारी से, Seahawk के माध्यम से मैं जिन 90% साइटों का ऑडिट करता हूँ, मुझे उन समस्याओं को खोजने के लिए Ahrefs, Semrush, या किसी भी बड़े प्लेटफॉर्म की जरूरत नहीं है जो सचमुच प्रदर्शन को नुकसान पहुंचा रहे हैं। दो टूल्स। एक प्रक्रिया। यह है।Seahawk, I don't need Ahrefs, Semrush, or any of the big platforms to find the problems that are genuinely hurting performance. Two tools. One process. Here it is.
---
कुछ भी क्रॉल करने से पहले, Screaming Frog को सही तरीके से सेट अप करें
ज्यादातर लोग Screaming Frog खोलते हैं, एक URL पेस्ट करते हैं, और शुरू करते हैं। 50 पेज के ब्लॉग के लिए यह ठीक है। इससे बड़ी किसी भी चीज़ के लिए, आप 40 मिनट का इंतज़ार करेंगे एक क्रॉल के लिए जो गलत डेटा देता है।
कॉन्फ़िगरेशन क्रॉलिंग स्पीड से ज्यादा मायने रखती है
मैं सबसे पहले यह करता हूँ: Configuration > Spider पर जाता हूँ और सुनिश्चित करता हूँ कि मैं सही प्रोटोकॉल क्रॉल कर रहा हूँ। अगर साइट HTTPS पर है (होना चाहिए), तो मैं canonical HTTPS होमपेज से शुरू करता हूँ। मैं कुछ फाइल टाइप्स — PDFs, इमेजेज़, वीडियोज़ — की क्रॉलिंग भी बंद कर देता हूँ, जब तक मैं खास तौर पर उन्हें ऑडिट करना न चाहूँ। इससे क्रॉल टाइम आधा हो जाता है।Configuration > Spider and make sure I'm crawling the correct protocol. If the site is on HTTPS (it should be), I'm starting from the canonical HTTPS homepage. I also turn off crawling of certain file types — PDFs, images, videos — unless I specifically want to audit those. It halves the crawl time.
फिर मैं Configuration > Respect Canonical Tags को off कर देता हूँ। उलटा लगता है, मुझे पता है। लेकिन मैं हर canonicalised URL देखना चाहता हूँ ताकि मैं ऑडिट कर सकूँ कि canonicalisation असल में सही है या नहीं। अगर Screaming Frog canonicalised पेजेज़ को स्किप कर देता है, तो आप कभी नहीं जान पाएँगे कि वो मौजूद हैं।Configuration > Respect Canonical Tags to off. Counter-intuitive, I know. But I want to see every canonicalised URL so I can audit whether the canonicalisation is actually correct. If Screaming Frog skips canonicalised pages, you'll never know they exist.
एक और चीज़: Configuration > Custom Extraction के तहत, मैं एक extraction rule सेट करता हूँ ताकि raw <title> और meta description को सीधे HTML source से निकाल सकूँ। क्यों? क्योंकि कुछ WordPress साइट्स — खासकर जो Yoast के साथ एक page builder चलाते हैं — दो title tags output करते हैं। Screaming Frog का डिफ़ॉल्ट कॉलम सिर्फ पहला दिखाता है। Extraction rule सब कुछ दिखाता है।Configuration > Custom Extraction, I set up an extraction rule to pull the raw <title> and meta description directly from the HTML source. Why? Because some WordPress sites — particularly ones running Yoast alongside a page builder — output two title tags. Screaming Frog's default column only shows you the first one. The extraction rule shows you everything.
---
पहला पास: क्रॉल डेटा में मैं क्या देखता हूँ
जब क्रॉल खत्म हो जाता है, तो मैं टूटे हुए लिंक्स के साथ शुरू नहीं करता। सब लोग टूटे हुए लिंक्स के साथ शुरू करते हैं। मैं Response Codes टैब के साथ शुरू करता हूँ और 3xx redirects के लिए फिल्टर करता हूँ।Response Codes tab and filter for 3xx redirects.
2021 में वापस, Seahawk ने एक e-commerce क्लाइंट लिया — एक mid-sized फर्नीचर रिटेलर, करीब 8,000 URLs। उनकी dev team दो सालों से redirects को ad hoc तरीके से संभाल रही थी। हमें 19 redirect chains मिलीं, कुछ उनमें से चार hops लंबी थीं। Page A, Page B को redirect करता था, जो Page C को redirect करता था, जो Page D को redirect करता था। Google कहता है कि वह 10 hops तक फॉलो करता है, लेकिन व्यावहारिक रूप से, दो hops से परे कुछ भी crawl budget को बर्बाद करता है और link equity को कमजोर करता है। हमने सब कुछ single-hop redirects में collapse कर दिया। यह अकेले — कोई content changes नहीं, कोई link building नहीं — तीन category pages को page 3 से page 1 पर छह हफ्तों में ले आया।Google says it follows up to 10 hops, but in practice, anything beyond two hops wastes crawl budget and dilutes link equity. We collapsed everything to single-hop redirects. That alone — no content changes, no link building — moved three category pages from page 3 to page 1 within six weeks.
जिस क्रम में मैं tabs के साथ काम करता हूँ
- प्रतिक्रिया कोड → 3xx — रीडायरेक्ट चेन और लूप — redirect chains and loops
- प्रतिक्रिया कोड → 4xx — टूटे हुए पेज (इनलिंक्स के आधार पर फ़िल्टर करें) — broken pages (filter by inlinks to prioritise)
- इंडेक्सेबिलिटी → गैर-इंडेक्सेबल — noindex, दूसरी जगह की ओर इंगित करने वाले canonicals, robots.txt द्वारा ब्लॉक किए गए — noindex, canonicals pointing elsewhere, blocked by robots.txt
- पेज टाइटल — गुम, डुप्लिकेट, या 60 से ज्यादा वर्णों वाले — missing, duplicated, over 60 characters
- मेटा विवरण — गुम या डुप्लिकेट (रैंकिंग कारक नहीं, लेकिन क्लिक-थ्रू मायने रखता है) — missing or duplicated (not a ranking factor, but click-through matters)
- H1 — गुम, डुप्लिकेट, या प्रति पेज एक से अधिक — missing, duplicated, or more than one per page
- इमेज → alt टेक्स्ट गुम — तेज़ जीत, खासकर प्रोडक्ट साइट्स के लिए — quick win, especially for product sites
- निर्देश → Canonical — जाँचें कि ये वास्तविक इंडेक्सेबल URL से मेल खाते हैं — check these match the actual indexable URL
वह क्रम जानबूझकर है। मैं संरचनात्मक समस्याओं (रीडायरेक्ट्स, टूटे पेज) से शुरुआत करके पेज-दर-पेज मुद्दों तक काम करता हूँ। एक टूटी हुई रीडायरेक्ट चेन को ठीक करने से उस चेन में हर पेज को मदद मिलती है। एक गुम मेटा विवरण को ठीक करने से एक पेज को मदद मिलती है।
---
सर्च कंसोल में लेयरिंग: जहां चीजें दिलचस्प होती हैं
Screaming Frog आपको बताता है कि साइट पर क्या है। सर्च कंसोल आपको बताता है कि गूगल को क्या लगता है साइट पर है। इन दोनों डेटा सेट के बीच का अंतर ही वह जगह है जहां असली समस्याएं रहती हैं।
ओपन कवरेज (या इंडेक्सिंग → नए इंटरफेस में पेजेस)। आप चार चीजों को देख रहे हैं:Coverage (or Indexing → Pages in the newer interface). You're looking at four things:
- एरर — पेजेस जिन्हें गूगल इंडेक्स करने की कोशिश कर रहा था लेकिन नहीं कर सका — pages Google tried to index and couldn't
- वैलिड विथ वार्निंग्स — अक्सर "सबमिटेड यूआरएल कैनोनिकल के रूप में सिलेक्ट नहीं किया गया," जो एक गड़बड़ी है जिसे आपको सुलझाना होगा — often "Submitted URL not selected as canonical," which is a mess you need to untangle
- एक्सक्लूडेड — पेजेस जिन्हें गूगल इंडेक्स नहीं करना चुना (क्रॉल किया गया लेकिन इंडेक्स नहीं किया गया, noindexed, आदि) — pages Google chose not to index (crawled but not indexed, noindexed, etc.)
- वैलिड — पेजेस जिन्हें गूगल ने इंडेक्स किया है — pages Google has indexed
"एक्सक्लूडेड" बकेट का उपयोग अपराध की तरह कम होता है। ज्यादातर लोग इसे नजरअंदाज कर देते हैं। मैं सीधे वहां जाता हूं। "क्रॉल्ड — फिलहाल इंडेक्स नहीं किया गया" से फिल्टर करें। यह गूगल कह रहा है: मुझे यह पेज मिला, मैंने इसे पढ़ा, और मैंने फैसला किया कि यह इंडेक्स करने के लायक नहीं है। यह लगभग हमेशा एक थिन कंटेंट समस्या है। या यह एक पेज है जो वास्तव में ठीक है लेकिन दूसरे पेज के बहुत समान है — फेसेटेड नेविगेशन या टैग आर्काइव के साथ एक क्लासिक समस्या।I found this page, I read it, and I decided it wasn't worth indexing. That's almost always a thin content problem. Or it's a page that's genuinely fine but is too similar to another page — a classic issue with faceted navigation or tag archives.
जीएससी एक्सक्लूजन्स को अपने Screaming Frog क्रॉल से मेल खाना
अपने Screaming Frog क्रॉल को सीएसवी में एक्सपोर्ट करें। सर्च कंसोल से "एक्सक्लूडेड" यूआरएल एक्सपोर्ट करें। दोनों को गूगल शीट्स में लोड करें और वीएलूकअप चलाएं। कोई भी यूआरएल जो Screaming Frog क्रॉल में दिखाई देता है और जीएससी एक्सक्लूडेड लिस्ट में है, एक प्राथमिकता की जांच है।and in the GSC excluded list is a priority investigation.
मुझे पता है कि लोग इसके लिए Python scripts का इस्तेमाल करते हैं। आपको करने की जरूरत नहीं है। Sheets में VLOOKUP चार मिनट में आपको वही जवाब दे देता है।
---
Crawl Budget: सिर्फ अगर आपकी साइट वाकई बड़ी है तो मायने रखता है
ठीक है, चलिए सच कहते हैं। अगर आपकी साइट के 1,000 से कम पेज हैं, तो crawl budget आपकी समस्या नहीं है। आप इसके बारे में चिंता करना बंद कर सकते हैं।
लेकिन जब आप लगभग 10,000 URLs से ऊपर जाते हैं — और बहुत सारे WooCommerce या Magento स्टोर सिर्फ product variants और filtered URLs से ही इस तक पहुंच जाते हैं — crawl budget काटने लगता है। Crawl budget पर Google Search Central का documentation असल में एक सबसे स्पष्ट चीज है जो उन्होंने लिखी है। इसे ठीक से पढ़ने की कोशिश करें।Google Search Central documentation on crawl budget is actually one of the clearer things they've written. Worth reading properly.
Search Console में आपके पास दो levers हैं — Crawl Stats रिपोर्ट और URL Inspection tool। Crawl Stats आपको Google की 90 दिन की crawl activity दिखाता है: रोज crawl किए गए पेज, response times, response codes। अगर आप किसी खास तारीख पर 404s में स्पाइक देखते हैं, तो वह deployment है जो गलत हुई। अगर average crawl time 2 सेकंड से ऊपर है, तो आपका सर्वर समस्या है, SEO नहीं।Crawl Stats report and the URL Inspection tool. Crawl Stats shows you Google's crawl activity over 90 days: pages crawled per day, response times, response codes. If you see a spike in 404s on a specific date, that's a deployment that went wrong. If average crawl time is above 2 seconds, your server is the problem, not your SEO.
---
Internal Linking: वह चीज जिसे Agencies हमेशा मिस करती हैं
मैंने Seahawk में सौ से ज्यादा साइटों का ऑडिट किया है जहां क्लायंट link building पर असली पैसे खर्च कर रहे थे — guest posts, digital PR, सब कुछ — और उनके पास orphaned pages थे जिन पर कोई internal link नहीं था। Google उस चीज को प्राथमिकता नहीं दे सकता जो वह आपकी साइट की संरचना के माध्यम से खोज नहीं सकता।orphaned pages that no internal link pointed to. Google can't prioritise what it can't find through your site structure.
Screaming Frog में, crawl को Inlinks = 0 से filter करें। कोई भी पेज जिसके पास शून्य internal links हैं, एक orphan है। इसे Search Console के indexed pages से क्रॉस-रेफरेंस करें। अगर पेज indexed है लेकिन internal links नहीं हैं, तो इसका मतलब है कि Google को यह एक XML sitemap या एक external backlink के माध्यम से मिला। यह नाजुक है। इसे एक relevant page से एक internal link दें और आप Google को एक structural signal दे रहे हैं कि यह पेज महत्वपूर्ण है।Inlinks = 0. Any page with zero internal links is an orphan. Cross-reference it against Search Console's indexed pages. If the page is indexed but has no internal links, it means Google found it through an XML sitemap or an external backlink. That's fragile. Give it an internal link from a relevant page and you're giving Google a structural signal that this page matters.
आंतरिक लिंकिंग पर मैं कुछ बातें देखता हूँ
- पेजिनेशन पेज जो प्रोडक्ट/आर्टिकल पेज को लिंक करते हैं लेकिन वे पेज कैटेगरी पेज पर वापस लिंक नहीं करते
- 2019 में प्रकाशित ब्लॉग पोस्ट जिनको कभी नई कंटेंट से लिंक नहीं किया गया
- ऐसे पेज जिनमें दर्जनों इनबाउंड इंटरनल लिंक हैं लेकिन GSC में ट्रैफिक बहुत कम है — अक्सर यह संकेत है कि पेज के साथ समस्या है, लिंकिंग के साथ नहीं
---
Core Web Vitals: डेटा पढ़ें, घबराएँ नहीं
Search Console में Core Web Vitals रिपोर्ट है। यह Chrome UX Report डेटा से खींचता है, जो फील्ड डेटा है — असली उपयोगकर्ता असली डिवाइस पर, लैब सिमुलेशन नहीं। यह एक बार की Lighthouse चलाने से ज्यादा अर्थपूर्ण है।Core Web Vitals report. It pulls from real-user Chrome UX Report data, which is field data — actual users on actual devices, not a lab simulation. This is more meaningful than what you'd get from a one-off Lighthouse run.
रिपोर्ट URLs को LCP, FID (अब INP द्वारा प्रतिस्थापित), और CLS के अनुसार "अच्छा," "सुधार की जरूरत," और "ख़राब" में बाँटती है। सब कुछ एक साथ ठीक करने की कोशिश न करें। "ख़राब" ग्रुप को सॉर्ट करें और देखें कि किस URL पैटर्न के पास सबसे अधिक फेलिंग पेज हैं। आमतौर पर यह एक ही टेम्पलेट है — सभी प्रोडक्ट पेज CLS फेल कर रहे हैं, या सभी कैटेगरी पेज धीमी LCP के साथ। टेम्पलेट ठीक करें, सैकड़ों पेज एक बार में ठीक करें।
एक चीज जो मैंने कठिन तरीके से सीखी है: विज्ञापन या कुकी बैनर वाली साइटों पर CLS समस्याएँ लगभग हमेशा एलिमेंट्स की वजह से होती हैं जो इनिशियल पेंट के बाद ऐबव द फोल्ड इंजेक्ट करते हैं। Screaming Frog इसे नहीं पकड़ेगा। आपको असली पेज को देखना होगा। Chrome DevTools का उपयोग करें जिसमें Layout Shift regions Rendering में सक्षम हो।
---
रोबोट्स.टेक्स्ट और साइटमैप चेक (10 मिनट लगते हैं, हफ्तों की बचत करते हैं)
yourdomain.com/robots.txt पर जाएँ। हर लाइन पढ़ें। मैंने अपनी आँखों से एक लाइव प्रोडक्शन साइट देखी है जिसमें robots.txt में Disallow: / था। कोई स्टेजिंग साइट नहीं। प्रोडक्शन। सात साल पुरानी कंपनी। उनके डेवलपर ने माइग्रेशन के दौरान स्टेजिंग robots.txt कॉपी कर दिया था और कभी चेक नहीं किया। वे चार महीने तक गूगल से अनिवार्य रूप से अदृश्य रहे थे इससे पहले कि उन्हें पता चले।yourdomain.com/robots.txt . Read every line. I have seen, with my own eyes, a live production site with Disallow: / in the robots.txt. Not a staging site. Production. A seven-year-old business. Their developer had copied the staging robots.txt during a migration and never checked it. They had been essentially invisible to Google for four months before they noticed.
Search Console में, Sitemaps पर जाएँ। देखें कि क्या सबमिट किया गया है। चेक करें कि गूगल ने इसे आखिरी बार कब फेच किया। अगर साइटमैप एक हफ्ते से अधिक समय से नहीं फेच हुआ है, तो कुछ गड़बड़ है। सबमिट किए गए URL काउंट को इंडेक्स किए गए URL काउंट से भी चेक करें — अगर आपने 4,000 URLs सबमिट किए हैं और केवल 1,200 इंडेक्स हैं, तो यह तकनीकी सुधार के बारे में नहीं, कंटेंट की गुणवत्ता के बारे में बातचीत है।Sitemaps. Check what's been submitted. Check the last time Google fetched it. If the sitemap hasn't been fetched in over a week, something is broken. Also check the submitted URL count vs the indexed URL count — if you've submitted 4,000 URLs and only 1,200 are indexed, that's a conversation you need to have about content quality, not about technical fixes.
---
FAQ
क्या मुझे Screaming Frog का पेड वर्जन चाहिए?
फ्री वर्जन की सीमा 500 URLs पर है। उससे अधिक कुछ भी — जो कि ज्यादातर साइट्स की ऑडिट के लिए काबिल है — आपको पेड लाइसेंस चाहिए। लेखन के समय यह £259 प्रति वर्ष है। यह एजेंसी के एक घंटे के समय के करीब है। इसे खरीद लें।£259 per year as of writing. That's about the price of a single hour of agency time. Buy it.
मुझे तकनीकी ऑडिट कितनी बार चलाना चाहिए?
सक्रिय साइट्स जो नियमित रूप से प्रकाशित करती हैं या बार-बार प्रोडक्ट बदलती हैं, मैं कहूँगा तिमाही में। छोटी, अधिक स्थिर साइट्स के लिए, साल में दो बार ठीक है। एक बार ऑडिट चलाना और इसे "पूरा" मानना ऐसा है जैसे कार में तेल बदला हो और उम्मीद करो कि वह हमेशा चलती रहेगी।
Screaming Frog 200 स्टेटस दिखाता है लेकिन GSC दिखाता है कि पेज इंडेक्स नहीं है — क्यों?
लगभग हमेशा तीन चीजों में से कोई एक: एक noindex मेटा टैग, एक noindex HTTP हेडर, या कहीं और की ओर इशारा करने वाला canonical टैग। URL को Search Console के URL Inspection टूल में चलाएँ और यह आपको बिल्कुल बताएगा कि उसे क्या मिला। यह टूल कम आंका जाता है — यह आपको Google के पेज का आखिरी crawled संस्करण दिखाता है, जिसमें rendered HTML भी शामिल है, जो JavaScript-injected noindex टैग को पकड़ता है जिसे एक basic HTTP request नहीं देख सकता।last crawled version of the page, including the rendered HTML, which catches JavaScript-injected noindex tags that a basic HTTP request wouldn't see.
JavaScript-rendered साइटों के बारे में क्या?
Screaming Frog के पास Configuration > Spider > Rendering के तहत एक JavaScript rendering mode है। JS-heavy साइटों के लिए इसे चालू करें। यह धीमा है — काफी हद तक धीमा — लेकिन यह JavaScript द्वारा injected content या links के साथ समस्याओं को पकड़ने का एकमात्र तरीका है जो initial HTML load के बाद आते हैं। React या Next.js साइट के लिए, हमेशा JS rendering mode में crawl करें।Configuration > Spider > Rendering. Turn it on for JS-heavy sites. It's slower — significantly slower — but it's the only way to catch issues with content or links that are injected by JavaScript after the initial HTML loads. For a React or Next.js site, always crawl in JS rendering mode.
क्या Google Search Console कीवर्ड रिसर्च के लिए काफी है?
यह पता लगाने के लिए कि आपके मौजूदा पेज किन queries के लिए rank करते हैं, हाँ, यह बेहतरीन है। नए keyword opportunities की खोज के लिए, नहीं — आपको कुछ और की जरूरत होगी। लेकिन यह एक technical audit के दायरे से बाहर है।existing pages rank for, yes, it's excellent. For discovering new keyword opportunities, no — you'll need something else. But that's out of scope for a technical audit.
---
दो टूल। एक स्प्रेडशीट। कुछ घंटे। यह सचमुच इतना ही लगता है। महंगे platforms के अपनी जगह है — मैं उनके खिलाफ नहीं हूँ — लेकिन मैंने बहुत सारे site owners को यह मान लेते देखा है कि ज्यादा खर्च करने का मतलब ज्यादा खोजना है। समस्याएँ लगभग हमेशा बेसिक्स में होती हैं। उन्हें बस किसी को actual देखना होता है।