2022 में एक क्लाइंट ने मुझे फोन किया -- एक यूके-आधारित ई-कॉमर्स ऑपरेटर था जिसके पास लगभग 14,000 प्रोडक्ट पेज थे -- गुस्से में कि उन्होंने छः हफ्तों में अपने 34% ऑर्गेनिक ट्रैफिक खो दिए थे। कोई manual penalty नहीं। कोई एल्गोरिदम announcement नहीं। बस एक धीमा, शांत गिरावट। हमने Screaming Frog से एक पूरी crawl चलाई और 90 मिनटों के अंदर समस्या मिल गई: उनके pagination ने हजारों near-duplicate URLs को auto-generate कर दिया था, Google ने उन सभी को crawl किया था असली product pages की जगह, और उनका crawl budget बिल्कुल समाप्त हो गया था। बर्बाद। हर महीने।
मुख्य बात: 10,000 पृष्ठों वाली साइट का ऑडिट छोटी साइट के ऑडिट का बस एक बड़ा संस्करण नहीं है — विफलता के तरीके क्रॉल बजट, टेम्पलेट और स्केल पर इंडेक्सेशन हैं, और चेकलिस्ट भी तदनुसार बदल जाती है।Auditing a 10,000-page site is not a bigger small-site audit: the failure modes are crawl budget, templates, and indexation at scale, and the checklist changes accordingly.
बड़ी साइट SEO का यही मामला है। समस्याएं समझने में ज्यादा कठिन नहीं हैं -- वे बस परिणाम में विनाशकारी रूप से बड़ी होती हैं। एक canonical tag गलत configure किया गया 20-page साइट पर तो परेशानी है। 14,000-page साइट पर, यह शांति से आपके पूरे index को घोंट सकता है।
यह वह audit चेकलिस्ट है जिसका इस्तेमाल मैं Seahawk Media पर करता हूँ जब कोई साइट 10,000-page के निशान को पार करती है। किसी खास महत्व के क्रम में नहीं -- क्योंकि हर बड़ी साइट के अपने विनाश की श्रृंखला होती है।Seahawk Media when a site crosses the 10,000-page mark. In no particular order of importance -- because every large site has its own hierarchy of disasters.
---
Crawl Budget से शुरू करें -- Keywords नहीं
ज्यादातर लोग बड़ी साइटों के ऑडिट को रैंकिंग देखकर शुरू करते हैं। गलत क्रम। बिल्कुल गलत। रैंकिंग इंडेक्सेशन के बाद आती है, और इंडेक्सेशन क्रॉल बजट के बाद आता है। ऑपरेशन का क्रम ठीक करो।
Crawl budget, किसी के लिए जिसे सरल संस्करण चाहिए: यह URLs की संख्या है जिन्हें Googlebot एक निर्धारित समय सीमा के भीतर आपकी साइट पर crawl करेगा। Google के खुद के crawl budget दस्तावेज़ वाकई यहाँ पढ़ने लायक हैं -- वे काफी specific हैं कि क्या इसे बर्बाद करता है।Google's own documentation on crawl budget is genuinely worth reading here -- they're quite specific about what wastes it.
तुम्हारा बजट क्या खा रहा है?
पहले अपने server logs खींचें। GSC डेटा नहीं -- असली server logs। मैं GoAccess का इस्तेमाल बड़ी log files पर quick analysis के लिए करता हूँ क्योंकि यह volume को handle करता है बिना रोए। जो आप ढूंढ रहे हैं:GoAccess for quick analysis on large log files because it handles volume without crying. What you're looking for:
- Faceted नेविगेशन URLs (उदाहरण के लिए, /shoes?colour=red&size=10&sort=price)
/shoes?colour=red&size=10&sort=price) - URLs में जोड़े गए Session IDs
- Infinite scroll या "load more" implementations जो यूनिक पैरामीटर स्ट्रिंग्स बनाते हैं
- Duplicate paginated URLs (/page/1 और /) दोनों क्रॉल हो रहे हैं
/page/1and/) both being crawled - आंतरिक सर्च रिज़ल्ट पेजेस जो ब्लॉक नहीं हैं
10,000 pages से ऊपर कोई भी साइट active faceted navigation के साथ लगभग निश्चित रूप से crawl budget को बर्बाद कर रही है। लगभग निश्चित। इसका fix ग्लैमरस नहीं है -- यह parameter patterns पर robots.txt disallow है, या आदर्श रूप से, GSC के माध्यम से proper URL parameter handling combined faceted pages पर canonical tags के साथ।proper URL parameter handling via GSC combined with canonical tags on the faceted pages themselves.
शुरुआती 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 दिनों में गिर गई।noindex, follow and disallowed the heavy combinatorial patterns in robots.txt. Within six weeks, average crawl frequency on real product pages dropped to every 3-4 days.
---
इंडेक्सेशन ऑडिट: Google के इंडेक्स में असल में क्या है?
Google में site:yourdomain.com एक मोटा-मोटा आंकड़ा देता है। सटीकता के लिए इस पर निर्भर न रहें, लेकिन यह एक त्वरित sanity check है। GSC के Index Coverage report के साथ क्रॉस-रेफर करें। in Google gives you a rough figure. Don't rely on it for precision, but it's a quick sanity check. Cross-reference with GSC's Index Coverage report.
"जो पेज आप इंडेक्स करवाना चाहते हैं" और "जो पेज Google ने इंडेक्स किए हैं" के बीच का अंतर ही वह जगह है जहां पैसा है। बड़ी साइट्स पर, यह अंतर आमतौर पर विशाल होता है और पूरी तरह से रोका जा सकता है।
चार स्थितियां जो आप के लिए मायने रखती हैं
- Indexed, कोई समस्या नहीं -- ठीक है, इसे छोड़ दें -- fine, leave it
- बाहर रखा गया: noindex -- क्या यह जानबूझकर है? पुष्टि करें कि यह है। -- intentional? Confirm it is
- बाहर रखा गया: क्रॉल किया गया, वर्तमान में इंडेक्स नहीं किया गया -- यह वह है जो आपको चिंतित करना चाहिए। -- this is the one that should alarm you
- बाहर रखा गया: खोजा गया, क्रॉल नहीं किया गया -- क्रॉल बजट की समस्या, पहले सेक्शन में वापस आएं। -- crawl budget problem, come back up to section one
"क्रॉल किया गया, वर्तमान में इंडेक्स नहीं किया गया" Google का यह कहने का तरीका है: मैं यहाँ पहुँचा, मैंने देखा, और मैंने फैसला किया कि परेशान होने की कोई बात नहीं है। इसका मतलब आमतौर पर पतली सामग्री है, लगभग-डुप्लिकेट सामग्री है, या एक गुणवत्ता संकेत इतना कमजोर है कि Google सक्रिय रूप से इसे छोड़ने का चुनाव कर रहा है। प्रोडक्ट पेजेस पर, यह अक्सर ऑटो-जेनरेटेड विवरण के साथ होता है जो बॉयलरप्लेट के तीन वाक्य हैं। Google ने "यह प्रोडक्ट कई रंगों में उपलब्ध है और 3-5 कार्य दिवसों के भीतर शिप होता है" के हजारों संस्करण देखे हैं। इसे एक और नहीं चाहिए।I got here, I looked around, and I decided not to bother.That usually means thin content, near-duplicate content, or a quality signal so weak Google is making an active choice to skip it. On product pages, this often happens with auto-generated descriptions that are three sentences of boilerplate. Google has seen a thousand versions of "This product is available in multiple colours and ships within 3-5 working days." It doesn't want another one.
---
Canonical Tags at Scale
Canonicals वह जगह है जहाँ मैं बड़ी साइटों पर सबसे शानदार आत्म-निर्मित नुकसान देखता हूँ। क्योंकि वे जटिल हैं इसलिए नहीं -- वे नहीं हैं -- बल्कि इसलिए कि 10,000+ पेजों पर, एक एकल टेम्पलेट त्रुटि तुरंत हजारों 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 हैं।Classic example: a paginated category page where page/2 has a canonical pointing to itself instead of page/1 or the root category. Multiply that by 400 category pages with 8 pages of pagination each and you've got 2,800+ pages with broken canonical signals.
Canonical chains। पेज A, पेज B को canonicalise करता है, जो पेज C को canonicalise करता है। Google canonical chains को फॉलो करता है, लेकिन वह उनके बारे में उत्साही नहीं है। तीन हॉप्स पहले से ही इसे आगे बढ़ा रहे हैं। मैंने साइटों को पाँच-हॉप chains के साथ देखा है जो वर्षों के माइग्रेशन और रीडिज़ाइन में बने हैं। Screaming Frog का "Canonical" टैब आपको यह सीधे दिखाएगा -- इसे एक्सपोर्ट करें, chains के लिए फ़िल्टर करें।Page A canonicalises to Page B, which canonicalises to Page C. Google follows canonical chains, but it's not enthusiastic about them. Three hops is already pushing it. I've seen sites with five-hop chains built up over years of migrations and redesigns. Screaming Frog's "Canonical" tab will show you this directly -- export it, filter for chains.
हर 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+ पेजों पर, एक एकल sitemap फ़ाइल एक समस्या बनने लगती है। Google की सीमा प्रति sitemap फ़ाइल 50,000 URLs या 50MB है -- लेकिन उस सीमा को हिट करना बात नहीं है। बात यह है कि 40,000 URLs के साथ एक मोनोलिथिक sitemap की निगरानी करना मुश्किल है और जब चीजें गलत हो जाती हैं तो उसे डीबग करना मुश्किल है।
इसे तोड़ दीजिए। एक sitemap index फ़ाइल का इस्तेमाल करें जो segmented sitemaps की ओर इशारा करे:
- Products sitemap
- Categories sitemap
- Blog/editorial sitemap
- Brand या manufacturer pages sitemap (अगर लागू हो)
सेगमेंटेशन महत्वपूर्ण क्यों है? क्योंकि जब कुछ टूटता है -- और यह होगा -- आप समस्या को अलग कर सकते हैं। यदि Google अचानक आपके नए प्रोडक्ट पेजों को नहीं उठा रहा है, तो आप GSC में products sitemap क्रॉल तारीख को देखें और वहाँ से डीबग करें। एक मोनोलिथिक sitemap आपको देखने के लिए कहीं नहीं देता।
साथ ही: अपने sitemap में सिर्फ वे URLs शामिल करें जिन्हें आप वास्तव में indexed देखना चाहते हैं। यह स्पष्ट लगता है। आप हैरान होंगे। मैंने साइट्स को audit किया है जहाँ sitemap किसी plugin द्वारा auto-generate किया गया था और उसमें tag pages, author archives, attachment pages, और आधा दर्जन अन्य URL types शामिल थे जिन पर noindex था। बेकार का शोर।only include URLs you actually want indexed in your sitemap.This sounds obvious. You'd be surprised. I've audited sites where the sitemap was auto-generated by a plugin and included tag pages, author archives, attachment pages, and half-a-dozen other URL types that had noindex on them. Pointless noise.
यदि आप structured data के साथ भी काम कर रहे हैं तो Google के Rich Results Test के साथ अपने sitemap की वैधता की जांच करें -- और ब्राउज़र में raw sitemap डिलीवरी को देखें यह पुष्टि करने के लिए कि आपका सर्वर 200 लौटा रहा है, न कि 301 chain या, भगवान न करे, 404।Google's Rich Results Test if you're also dealing with structured data -- and check raw sitemap delivery in a browser to confirm your server is returning a 200, not a 301 chain or, god forbid, a 404.
---
बड़े पैमाने पर Internal Linking: कम आंका जाने वाला एक
PageRank अभी भी असली है। यह internal links के ज़रिये बहता है। एक बड़ी साइट पर, आपकी internal linking की architecture प्रभावी रूप से यह तय करती है कि किन पेजों के पास authority है और कौन से अनाथ पन्ने किसी कोने में चुप-चाप मर रहे हैं।
Seahawk के पास 2023 में एक पब्लिशिंग क्लाइंट था -- मोटे तौर पर एक न्यूज़ और लाइफस्टाइल वर्टिकल में 18,000 आर्टिकल। उनके टॉप-फनल कैटेगरी पेजेस को अच्छा ट्रैफिक मिल रहा था। लेकिन उनकी गहरी archival सामग्री -- 2015 से 2019 तक का सामान जिसके पास अभी भी असली सर्च डिमांड था -- लगभग अदृश्य था। इसलिए नहीं कि सामग्री बुरी थी। क्योंकि कुछ भी इसे अब link नहीं कर रहा था। वे अपने कैटेगरी नेविगेशन को तीन बार रीडिज़ाइन कर चुके थे, और हर बार, पुरानी सामग्री एक और गहराई में दफन हो जाती थी।
समाधान आकर्षक नहीं था: हमने एक 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% बढ़ गए।WordPress plugin that identified articles with relevant keyword overlap and inserted contextual links. Click depth on their archival content dropped from an average of 7.2 clicks from the homepage to 3.1. Organic impressions on those pages rose 28% over the following quarter.
यहाँ बड़ी साइटों के लिए एक जल्दी से internal linking checklist है:
- कोई भी page जिसे आप indexed करना चाहते हैं, homepage से 3 clicks से ज़्यादा दूर नहीं होना चाहिए
- Orphan pages (जिन पर कोई internal links नहीं हैं) को एक emergency की तरह handle करें, न कि backlog item की तरह
- ब्रेडक्रंब नेविगेशन को इंटरनल लिंकिंग के रूप में गिना जाता है -- सुनिश्चित करें कि इसे सही तरीके से लागू किया गया है और असली एंकर टेक्स्ट का उपयोग किया जा रहा है, केवल "Category > Subcategory" जैसे जेनेरिक लेबल नहीं
- ऐसे पेजों की जांच करें जिनके पास केवल एक इंटरनल लिंक है -- यह लगभग उतना ही बुरा है जितना कि ऑर्फन पेज
---
बड़े पैमाने पर स्ट्रक्चर्ड डेटा और स्कीमा
अगर आपके पास 10,000+ प्रोडक्ट पेज हैं और उनमें से किसी में भी Product schema के साथ Offer, Review, और AggregateRating प्रॉपर्टीज नहीं हैं, तो आप SERP रीयल एस्टेट को बर्बाद कर रहे हैं।Product schema with Offer,Review, and AggregateRating properties, you're leaving SERP real estate on the table.
लेकिन बड़े पैमाने पर स्ट्रक्चर्ड डेटा के अपने ऑडिट की जरूरतें भी होती हैं। किसी टेम्पलेट में स्कीमा की एक गलती का मतलब हजारों गलत मार्कअप इंस्टेंस हो सकते हैं। मैं स्ट्रक्चर्ड डेटा चेक करने के लिए दो टूल्स का कॉम्बिनेशन इस्तेमाल करता हूँ: व्यक्तिगत URL सैम्पलिंग के लिए Google का Rich Results Test, और सभी पेज टाइप्स में एक बल्क व्यू के लिए Screaming Frog में क्रॉल-लेवल स्कीमा एक्सट्रेक्शन (Configuration → Custom Extraction → XPath for JSON-LD blocks)।
क्या देखना है:
- आवश्यक प्रॉपर्टीज़ का अभाव (विशेषकर प्रोडक्ट पेजों पर price और priceCurrency -- ये आम छूटें हैं)
priceandpriceCurrencyon Product pages -- these are common omissions) - गलत स्ट्रक्चर्ड डेटा (स्कीमा एक प्रोडक्ट नाम कहता है, <title> दूसरा कहता है)
<title>says another) - पुरानी स्कीमा टाइप -- DataFeedElement और कुछ पुराने itemscope माइक्रोडेटा पैटर्न को ऑडिट करने के लायक हैं
DataFeedElementand some olderitemscopemicrodata patterns are worth auditing out - ऐसी स्कीमा की समीक्षा करें जो Google की रिव्यू स्निपेट गाइडलाइनों का उल्लंघन करती है -- फर्स्ट-पार्टी रिव्यूज़ को थर्ड-पार्टी के रूप में मार्क किया गया, या छोटे सैंपल साइज़ से एकत्रित स्कोरGoogle's review snippet guidelines -- first-party reviews marked up as third-party, or aggregated scores from tiny sample sizes
---
बड़े पैमाने पर पेज स्पीड: जो ठीक नहीं कर सकते उसका ऑडिट मत करें
Core Web Vitals महत्वपूर्ण हैं। लेकिन यहाँ वह बात है जो पर्याप्त कही नहीं जाती: 10,000 पेजों के across CWV को audit करना और हर individual URL को fix करने की कोशिश करना एक मूर्खतापूर्ण काम है। आप template के आधार पर audit करते हैं, फिर template के आधार पर fix करते हैं। matter. But here's the thing that doesn't get said enough: auditing CWV across 10,000 pages and trying to fix every individual URL is a fool's errand. You audit by template, then fix by template.
प्रति टेम्पलेट टाइप 20-30 URL का सैंपल PageSpeed Insights या WebPageTest के माध्यम से चलाएँ। अगर आपके प्रोडक्ट पेजों का औसत LCP 4.8s है, तो यह एक टेम्पलेट-स्तरीय समस्या है। समाधान आपकी इमेज डिलीवरी पाइपलाइन, आपके क्रिटिकल CSS, या आपके सर्वर रिस्पांस टाइम में है -- व्यक्तिगत पेजों को छूने में नहीं।WebPageTest. If your product pages have an average LCP of 4.8s, that's a template-level problem. The fix is in your image delivery pipeline, your critical CSS, or your server response time -- not in touching individual pages.
बड़ी WordPress sites पर specifically (जो Seahawk पर हम ज्यादातर काम करते हैं), scale पर usual culprits ये हैं:
- Unoptimised WooCommerce product images जो WebP conversion के बिना serve होते हैं
- बहुत अधिक HTTP requests poorly-scoped plugin enqueues से उन pages पर जिन्हें इन scripts की जरूरत नहीं है
- होस्टिंग टियर जो साइट के विकास के साथ स्केल नहीं हुए हैं -- एक प्लान जो 2,000 प्रोडक्ट्स पर ठीक था, अक्सर 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 से काम चल सकता है?
व्यक्तिगत पेजों से नहीं, टेम्पलेट्स से काम करें। 12,000 प्रोडक्ट पेजों वाली साइट के पास शायद 4-6 सार्थक पेज टेम्पलेट हैं। प्रत्येक टेम्पलेट टाइप को एक प्रतिनिधि सैंपल (न्यूनतम 20-30 URL) के साथ गहराई से ऑडिट करें, और आपके निष्कर्ष पूरे टेम्पलेट में लागू होंगे। अपवाद ऑर्फन पेज पहचान और रीडायरेक्ट चेन डिस्कवरी है -- इन्हें सैंपलिंग नहीं, पूरा क्रॉल कवरेज चाहिए।
ज्यादातर बड़ी साइट्स पर सबसे ज्यादा impact वाली single fix कौन सी है?
क्रॉल बजट, नौ में से नौ बार। विशेषकर, फेसेटेड नेविगेशन URL को ब्लॉक करना या कैनोनिकलाइज़ करना जिनके पास कोई सर्च डिमांड नहीं है और कोई यूनिक कंटेंट नहीं है। मैंने इस एक फिक्स को e-कॉमर्स साइट्स पर बड़े कैटलॉग्स के साथ किसी भी अन्य चेंज से कहीं अधिक प्रभावशाली देखा है। यह अनाकर्षक काम है -- robots.txt एडिट्स, कैनोनिकल टैग्स, पैरामीटर कॉन्फ़िगरेशन -- लेकिन यह अक्सर किसी भी कंटेंट या लिंक-बिल्डिंग प्रयास की तुलना में तेजी से परिणाम देता है।
बड़ी साइट्स के लिए क्या Screaming Frog या Sitebulb use करूँ?
दोनों अच्छे हैं। मैं अपने ज्यादातर क्रॉल काम के लिए Screaming Frog का इस्तेमाल करता हूँ क्योंकि मैं सालों के इस्तेमाल के बाद इसके एक्सपोर्ट फॉर्मेट को अच्छी तरह जानता हूँ, और इसके कस्टम एक्सट्रैक्शन ऑप्शन बेहतरीन हैं। Sitebulb का विजुअलाइजेशन लेयर वाकई बेहतर है और इसकी ऑडिट रिपोर्ट क्लाइंट्स के लिए ज्यादा पठनीय है। 50,000 पेजों से अधिक साइट्स के लिए, आप DeepCrawl (अब Lumar) को भी देख सकते हैं क्लाउड-बेस्ड क्रॉलिंग के लिए जो आपकी लोकल मशीन की RAM पर निर्भर नहीं है।DeepCrawl (now Lumar)for cloud-based crawling that doesn't depend on your local machine's 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 करो।
---
बड़ी साइट के लिए SEO कोई अलग विषय नहीं है -- यह वही सिद्धांत हैं, बस उस पैमाने पर जहाँ लापरवाही के परिणाम तेज़ी से जमा होते हैं। ऊपर दी गई चेकलिस्ट स्थिर नहीं रहेगी। हर साइट का अपना खास अव्यवस्था है। लेकिन अगर आप crawl budget, indexation, canonicals, sitemaps, internal linking, structured data, page speed, और redirects को इसी क्रम में काम करते हैं -- तो आप एक भी keyword देखने से पहले 80% समस्याएँ खोज लेंगे।
इंफ्रास्ट्रक्चर से शुरु करें। रैंकिंग उसके बाद आएंगी।