2022 में एक क्लायंट ने मुझे फोन किया — एक ब्रिटिश ई-कॉमर्स ऑपरेटर, जिसके पास लगभग 14,000 प्रोडक्ट पेज थे, और वह क्रोधित था क्योंकि उसने छह हफ्तों में 34% ऑर्गनिक ट्रैफिक खो दिया था। कोई मैनुअल पेनल्टी नहीं। कोई एल्गोरिथम घोषणा नहीं। बस एक धीमा, शांत पतन। हमने Screaming Frog से एक पूरी क्रॉल दौड़ाई और 90 मिनट के अंदर समस्या मिल गई: उनका पेजिनेशन हजारों near-duplicate URLs को ऑटो-जनरेट कर रहा था, Google ने उन सभी को क्रॉल किया था असली प्रोडक्ट पेजों की बजाय, और उनका क्रॉल बजट पूरी तरह खत्म हो गया था। बर्बाद। हर महीने।
मुख्य बात: 10,000 पृष्ठों वाली साइट का ऑडिट छोटी साइट के ऑडिट का बस एक बड़ा संस्करण नहीं है — विफलता के तरीके क्रॉल बजट, टेम्पलेट और स्केल पर इंडेक्सेशन हैं, और चेकलिस्ट भी तदनुसार बदल जाती है।
यही तो बड़ी साइटों की SEO के बारे में बात है। समस्याएं समझने में कठिन नहीं होती, बस उनके परिणाम आपदा-स्तरीय होते हैं। एक गलत तरीके से कॉन्फ़िगर किया गया कैनोनिकल टैग 20-पेज की साइट पर खीझ पैदा करने वाली होती है। 14,000-पेज की साइट पर, यह शांति से आपके पूरे इंडेक्स को दम घोंट सकती है।
यह वह ऑडिट चेकलिस्ट है जिसका मैं Seahawk Media में उपयोग करता हूँ जब कोई साइट 10,000-पेज के निशान को पार करती है। किसी भी विशेष महत्व के क्रम में नहीं, क्योंकि हर बड़ी साइट के पास अपनी त्रासदियों की अपनी पदानुक्रम होती है।
---
कीवर्ड्स नहीं, क्रॉल बजट से शुरू करें
ज्यादातर लोग बड़ी साइटों के ऑडिट को रैंकिंग देखकर शुरू करते हैं। गलत क्रम। बिल्कुल गलत। रैंकिंग इंडेक्सेशन के बाद आती है, और इंडेक्सेशन क्रॉल बजट के बाद आता है। ऑपरेशन का क्रम ठीक करो।
क्रॉल बजट, जिसे सादी भाषा में समझना जरूरी है: यह URLs की संख्या है जो Googlebot आपकी साइट पर किसी दिए गए समय के अंदर क्रॉल करेगा। Google का क्रॉल बजट पर अपना दस्तावेज़ सच में पढ़ने योग्य है यहाँ, वे काफी विशिष्ट हैं कि इसे क्या बर्बाद करता है।
तुम्हारा बजट क्या खा रहा है?
पहले अपने सर्वर लॉग निकालें। GSC डेटा नहीं, असली सर्वर लॉग। मैं बड़ी लॉग फाइलों पर त्वरित विश्लेषण के लिए GoAccess का उपयोग करता हूँ क्योंकि यह वॉल्यूम को बिना शिकायत के संभालता है। आप जो खोज रहे हैं:
- Faceted नेविगेशन URLs (उदाहरण के लिए, /shoes?colour=red&size=10&sort=price)
- URLs में जोड़े गए Session IDs
- Infinite scroll या "load more" implementations जो यूनिक पैरामीटर स्ट्रिंग्स बनाते हैं
- Duplicate paginated URLs (/page/1 और /) दोनों क्रॉल हो रहे हैं
- आंतरिक सर्च रिज़ल्ट पेजेस जो ब्लॉक नहीं हैं
10,000 पेजों से अधिक की कोई भी साइट एक सक्रिय फेसेटेड नेविगेशन के साथ लगभग निश्चित रूप से क्रॉल बजट को बर्बाद कर रही है। लगभग निश्चित रूप से। फिक्स चमकदार नहीं है, यह robots.txt पर पैरामीटर पैटर्न पर एक disallow है, या आदर्श रूप से, GSC के माध्यम से उचित URL पैरामीटर हैंडलिंग को फेसेटेड पेजों पर स्वयं कैनोनिकल टैग के साथ संयोजित करना है।
शुरुआती 2021 में, Seahawk का एक furniture retailer क्लाइंट था जिसके पास 23,000 product URLs थे। सतह पर ठीक दिख रहा था। लेकिन उनके log analysis से पता चला कि Googlebot अपने 61% crawl visits faceted filter combinations पर बिता रहा था जिनके पास zero search demand और zero unique content थे। उनके असली product pages को लगभग हर 14 दिन में एक बार crawl किया जा रहा था। Facet parameters को noindex, follow में switch किया और heavy combinatorial patterns को robots.txt में disallow किया। छः हफ्तों के भीतर, असली product pages पर average crawl frequency हर 3-4 दिनों में गिर गई।
---
इंडेक्सेशन ऑडिट: Google के इंडेक्स में असल में क्या है?
Google में site:yourdomain.com एक मोटा-मोटा आंकड़ा देता है। सटीकता के लिए इस पर निर्भर न रहें, लेकिन यह एक त्वरित sanity check है। GSC के Index Coverage report के साथ क्रॉस-रेफर करें।
"जो पेज आप इंडेक्स करवाना चाहते हैं" और "जो पेज Google ने इंडेक्स किए हैं" के बीच का अंतर ही वह जगह है जहां पैसा है। बड़ी साइट्स पर, यह अंतर आमतौर पर विशाल होता है और पूरी तरह से रोका जा सकता है।
चार स्थितियां जो आप के लिए मायने रखती हैं
- इंडेक्सड, कोई समस्या नहीं, ठीक है, इसे छोड़ दें
- Excluded: noindex, जानबूझकर? पुष्टि करें कि यह है
- बाहर रखे गए: क्रॉल किए गए, वर्तमान में इंडेक्स नहीं किए गए, यह वह है जो आपको सतर्क करना चाहिए
- बाहर रखे गए: खोजे गए, क्रॉल नहीं किए गए, क्रॉल बजट की समस्या, सेक्शन एक पर वापस आएं
"क्रॉल किया गया, वर्तमान में इंडेक्स नहीं किया गया" Google का यह कहने का तरीका है: मैं यहाँ पहुँचा, मैंने देखा, और मैंने फैसला किया कि परेशान होने की कोई बात नहीं है। इसका मतलब आमतौर पर पतली सामग्री है, लगभग-डुप्लिकेट सामग्री है, या एक गुणवत्ता संकेत इतना कमजोर है कि Google सक्रिय रूप से इसे छोड़ने का चुनाव कर रहा है। प्रोडक्ट पेजेस पर, यह अक्सर ऑटो-जेनरेटेड विवरण के साथ होता है जो बॉयलरप्लेट के तीन वाक्य हैं। Google ने "यह प्रोडक्ट कई रंगों में उपलब्ध है और 3-5 कार्य दिवसों के भीतर शिप होता है" के हजारों संस्करण देखे हैं। इसे एक और नहीं चाहिए।
---
Canonical Tags at Scale
कैनोनिकल्स वह जगह हैं जहाँ मैं बड़ी साइट्स पर सबसे शानदार आत्मघाती नुकसान देखता हूँ। इसलिए नहीं कि वे जटिल हों, वे नहीं हैं, बल्कि इसलिए कि 10,000+ पेजों पर, एक single template error तुरंत हजारों URLs में फैल जाती है।
दो failures जो मैं लगातार देखता हूँ:
Self-referencing canonicals जो असल में सही जगह पर point नहीं कर रहे हैं। खास उदाहरण: एक paginated category page जहाँ page/2 के पास एक canonical है जो खुद की ओर point कर रहा है बजाय page/1 या root category के। इसे 400 category pages से गुणा करें जिनके पास प्रत्येक 8 pages of pagination हैं और आपके पास 2,800+ pages हैं जिनमें broken canonical signals हैं।
Canonical chains। Page A, Page B को canonicalize करता है, जो Page C को canonicalize करता है। Google canonical chains को फॉलो करता है, लेकिन उसका इसमें उत्साह नहीं है। तीन hops पहले ही काफी है। मैंने साइट्स देखी हैं जिनमें पाँच-hop chains बनी हुई हैं जो सालों के migrations और redesigns के दौरान जमा हुई हैं। Screaming Frog का "Canonical" टैब आपको यह सीधे दिखाएगा, इसे export करें, chains के लिए filter करें।
हर template type पर अलग से एक full canonical audit run करें। Product pages। Category pages। Blog posts। Tag archives। Author pages। हर template का अपना failure mode है, और आप उन सभी को एक random sample से नहीं पकड़ सकते।
---
XML Sitemaps: लोगों से ज्यादा महत्वपूर्ण
10,000+ पेजों पर, एक single sitemap file एक समस्या बनने लगती है। Google की सीमा प्रति sitemap file 50,000 URLs या 50MB है, लेकिन इस सीमा तक पहुँचना मुद्दा नहीं है। मुद्दा यह है कि 40,000 URLs वाला एक monolithic sitemap monitor करना मुश्किल है और जब कुछ गलत होता है तो debug करना मुश्किल है।
इसे तोड़ दीजिए। एक sitemap index फ़ाइल का इस्तेमाल करें जो segmented sitemaps की ओर इशारा करे:
- Products sitemap
- Categories sitemap
- Blog/editorial sitemap
- Brand या manufacturer pages sitemap (अगर लागू हो)
Segmentation क्यों मायने रखती है? क्योंकि जब कुछ टूटता है, और यह होगा, आप समस्या को isolate कर सकते हैं। अगर Google अचानक आपके नए product pages को नहीं उठा रहा है, तो आप GSC में products sitemap crawl date को check करते हैं और वहाँ से debug करते हैं। एक monolithic sitemap आपको देखने के लिए कहीं नहीं देता।
साथ ही: अपने sitemap में सिर्फ वे URLs शामिल करें जिन्हें आप वास्तव में indexed देखना चाहते हैं। यह स्पष्ट लगता है। आप हैरान होंगे। मैंने साइट्स को audit किया है जहाँ sitemap किसी plugin द्वारा auto-generate किया गया था और उसमें tag pages, author archives, attachment pages, और आधा दर्जन अन्य URL types शामिल थे जिन पर noindex था। बेकार का शोर।
अगर आप structured data के साथ भी deal कर रहे हैं तो अपने sitemap को Google के Rich Results Test के साथ validate करें, और raw sitemap delivery को browser में check करें यह confirm करने के लिए कि आपका server 200 return कर रहा है, न कि 301 chain या, भगवान न करे, 404।
---
बड़े पैमाने पर Internal Linking: कम आंका जाने वाला एक
PageRank अभी भी असली है। यह internal links के ज़रिये बहता है। एक बड़ी साइट पर, आपकी internal linking की architecture प्रभावी रूप से यह तय करती है कि किन पेजों के पास authority है और कौन से अनाथ पन्ने किसी कोने में चुप-चाप मर रहे हैं।
Seahawk के पास 2023 में एक publishing client था, news और lifestyle vertical में मोटे तौर पर 18,000 articles। उनके top-funnel category pages को अच्छा ट्रैफिक मिल रहा था। लेकिन उनका deeper archival content, 2015 से 2019 की चीज़ें जिनमें अभी भी असली search demand थी, लगभग अदृश्य थी। इसलिए नहीं कि content ख़राब था। क्योंकि कुछ भी इसे link नहीं कर रहा था। उन्होंने अपने category navigation को तीन बार redesign किया था, और हर बार, पुराना content एक स्तर और गहरा दब जाता था।
समाधान आकर्षक नहीं था: हमने एक programmatic internal linking strategy बनाया जिसमें एक custom WordPress plugin था जो प्रासंगिक keyword overlap वाले articles को खोजता था और contextual links जोड़ता था। उनकी archival content पर click depth homepage से औसतन 7.2 clicks से गिरकर 3.1 रह गई। उन पेजों पर organic impressions अगली quarter में 28% बढ़ गए।
यहाँ बड़ी साइटों के लिए एक जल्दी से internal linking checklist है:
- कोई भी page जिसे आप indexed करना चाहते हैं, homepage से 3 clicks से ज़्यादा दूर नहीं होना चाहिए
- Orphan pages (जिन पर कोई internal links नहीं हैं) को एक emergency की तरह handle करें, न कि backlog item की तरह
- Breadcrumb navigation internal linking के रूप में counts करता है, सुनिश्चित करें कि इसे properly implement किया गया है और real anchor text का उपयोग करता है, न कि सिर्फ "Category > Subcategory" generic labels के साथ
- ऐसे पेजों को check करें जिनमें केवल एक internal link point कर रहा है, यह orphaned होने से ज़रा ही बेहतर है
---
बड़े पैमाने पर स्ट्रक्चर्ड डेटा और स्कीमा
अगर आपके पास 10,000+ प्रोडक्ट पेज हैं और उनमें से किसी में भी Product schema के साथ Offer, Review, और AggregateRating प्रॉपर्टीज नहीं हैं, तो आप SERP रीयल एस्टेट को बर्बाद कर रहे हैं।
लेकिन बड़े पैमाने पर स्ट्रक्चर्ड डेटा के अपने ऑडिट की जरूरतें भी होती हैं। किसी टेम्पलेट में स्कीमा की एक गलती का मतलब हजारों गलत मार्कअप इंस्टेंस हो सकते हैं। मैं स्ट्रक्चर्ड डेटा चेक करने के लिए दो टूल्स का कॉम्बिनेशन इस्तेमाल करता हूँ: व्यक्तिगत URL सैम्पलिंग के लिए Google का Rich Results Test, और सभी पेज टाइप्स में एक बल्क व्यू के लिए Screaming Frog में क्रॉल-लेवल स्कीमा एक्सट्रेक्शन (Configuration → Custom Extraction → XPath for JSON-LD blocks)।
क्या देखना है:
- आवश्यक प्रॉपर्टीज़ गायब हैं (खासकर Product पेजों पर price और priceCurrency, ये आम चूकें हैं)
- गलत स्ट्रक्चर्ड डेटा (स्कीमा एक प्रोडक्ट नाम कहता है, <title> दूसरा कहता है)
- Deprecated schema types, DataFeedElement और कुछ पुराने itemscope microdata patterns को audit करना लायक है
- ऐसा schema देखें जो Google के review snippet guidelines का उल्लंघन करता हो, first-party reviews को third-party के रूप में markup किया गया हो, या बहुत छोटे sample sizes से aggregated scores
---
बड़े पैमाने पर पेज स्पीड: जो ठीक नहीं कर सकते उसका ऑडिट मत करें
Core Web Vitals महत्वपूर्ण हैं। लेकिन यहाँ वह बात है जो पर्याप्त कही नहीं जाती: 10,000 पेजों के across CWV को audit करना और हर individual URL को fix करने की कोशिश करना एक मूर्खतापूर्ण काम है। आप template के आधार पर audit करते हैं, फिर template के आधार पर fix करते हैं।
अपने template type के अनुसार 20-30 URLs के एक sample को PageSpeed Insights या WebPageTest के ज़रिए चलाएँ। अगर आपके product pages का औसत LCP 4.8s है, तो ये एक template-level की समस्या है। समाधान आपके image delivery pipeline में है, आपके critical CSS में, या आपके server response time में, individual pages को छेड़ने में नहीं।
बड़ी WordPress sites पर specifically (जो Seahawk पर हम ज्यादातर काम करते हैं), scale पर usual culprits ये हैं:
- Unoptimised WooCommerce product images जो WebP conversion के बिना serve होते हैं
- बहुत अधिक HTTP requests poorly-scoped plugin enqueues से उन pages पर जिन्हें इन scripts की जरूरत नहीं है
- Hosting tiers जो site growth के साथ scale नहीं हुए हैं, एक plan जो 2,000 products पर ठीक था वो अक्सर 12,000 पर डूब रहा होता है
पहले अपनी hosting सही करो। बाकी सब कुछ सजावट है।
---
Redirect Audit: The Migration Debt Problem
बड़ी sites redirect chains को उसी तरह जमा करती हैं जैसे पुरानी घरें dodgy wiring जमा करती हैं। हर redesign, हर domain migration, हर URL restructure एक और layer जोड़ता है। चार या पाँच साल के बाद, चार या पाँच hops गहरी redirect chains खोजना असामान्य नहीं है।
हर hop समय लेता है। हर hop PageRank signal को कमजोर करता है। और कुछ बहुत पुराने 302s जो temporary होने के लिए बने थे, अब भी वहाँ बैठे हैं और permanent नुकसान कर रहे हैं।
मेरी process:
- Screaming Frog से crawl करें, सभी 3xx responses export करें
- chains के लिए filter करें (A → B → C, या इससे लंबे)
- सभी source links को सीधे final destination की ओर point करने के लिए update करें
- Confirm करें कि final destination 200 है, किसी और redirect का नहीं
- किसी भी 302 को flag करें जो 301 होना चाहिए और उन्हें server level पर बदलवाएँ
यह भी check करें: क्या आपके XML sitemap के URLs कोई redirects return कर रहे हैं? क्योंकि यह एक common है। एक sitemap में केवल वे URLs होने चाहिए जो 200s return करते हों। अगर आपका sitemap 301s से भरा है, तो आप Google का काम अपने ऊपर ले रहे हैं और उसे बुरी तरह कर रहे हैं।
---
FAQ
10,000+ पेज वाली साइट के लिए technical SEO audit में कितना समय लगता है?
ईमानदारी से कहें, तो यह इस बात पर निर्भर करता है कि साइट कितनी अच्छी तरह इंस्ट्रुमेंटेड है। अगर उनके पास GSC सही तरीके से सेटअप है, सर्वर लॉग्स एक्सेसिबल हैं, और Screaming Frog खुद को रेट-लिमिट किए बिना क्रॉल कर सकता है, तो अकेले डेटा कलेक्शन और विश्लेषण फेज़ के लिए एक थोरो ऑडिट मुझे लगभग 3-5 कार्य दिन लगते हैं। रिपोर्टिंग अतिरिक्त 1-2 दिन है। कोई भी जो आपको बताए कि वे एक दोपहर में एक महत्वपूर्ण बड़ी साइट ऑडिट कर सकते हैं, वह सैंपलिंग कर रहा है, ऑडिट नहीं।
क्या मुझे हर एक पेज का audit करना है या samples से काम चल सकता है?
Individual pages से नहीं, templates से काम करें। 12,000 product pages वाली एक site के पास शायद 4-6 meaningful page templates होते हैं। हर template type को एक representative sample (कम से कम 20-30 URLs) के साथ अच्छी तरह audit करें, और आपकी findings पूरे template पर लागू होंगी। Exception है orphan page identification और redirect chain discovery, इन्हें sampling नहीं, पूरे crawl coverage की ज़रूरत है।
ज्यादातर बड़ी साइट्स पर सबसे ज्यादा impact वाली single fix कौन सी है?
Crawl budget, नौ में से नौ बार। खासकर faceted navigation URLs को block या canonicalise करना जिनके पास कोई search demand नहीं है और कोई unique content नहीं है। मैंने बड़ी catalogues वाली e-commerce sites पर इस एक ही fix को किसी दूसरे change से ज़्यादा असर डालते हुए देखा है। ये unglamorous काम है, robots.txt edits, canonical tags, parameter configurations, लेकिन अक्सर ये content या link-building effort जितनी तेज़ नतीजे देता है।
बड़ी साइट्स के लिए क्या Screaming Frog या Sitebulb use करूँ?
दोनों अच्छे हैं। मैं अपने ज्यादातर क्रॉल काम के लिए Screaming Frog का इस्तेमाल करता हूँ क्योंकि मैं सालों के इस्तेमाल के बाद इसके एक्सपोर्ट फॉर्मेट को अच्छी तरह जानता हूँ, और इसके कस्टम एक्सट्रैक्शन ऑप्शन बेहतरीन हैं। Sitebulb का विजुअलाइजेशन लेयर वाकई बेहतर है और इसकी ऑडिट रिपोर्ट क्लाइंट्स के लिए ज्यादा पठनीय है। 50,000 पेजों से अधिक साइट्स के लिए, आप DeepCrawl (अब Lumar) को भी देख सकते हैं क्लाउड-बेस्ड क्रॉलिंग के लिए जो आपकी लोकल मशीन की RAM पर निर्भर नहीं है।
बड़ी साइट्स के audits में सबसे ज्यादा commonly missed issue कौन सी है?
Internal linking depth। सब लोग broken links और canonicals check करते हैं। बहुत कम लोग systematically उन pages को identify करते हैं जो homepage से छः या सात clicks दूर हैं और पूछते हैं कि वे कुछ competitive के लिए rank करने की उम्मीद क्यों रखते हैं। Click depth एक proxy है crawl priority और authority distribution का। हर बार इसे audit करो।
---
Large-site SEO एक अलग discipline नहीं है, यह वही principles हैं उस scale पर जहाँ neglect के नतीजे तेज़ी से compound होते हैं। ऊपर दी गई checklist static नहीं रहेगी। हर site का अपना particular chaos होता है। लेकिन अगर आप crawl budget, indexation, canonicals, sitemaps, internal linking, structured data, page speed, और redirects के उस rough order में काम करते हैं, तो आपको एक single keyword भी देखने से पहले ही 80% broken चीज़ें मिल जाएँगी।
इंफ्रास्ट्रक्चर से शुरु करें। रैंकिंग उसके बाद आएंगी।