WordPress में ads.txt त्रुटि कैसे ठीक करें

जब समस्या WordPress में हो, ads.txt की सामग्री में नहीं

कभी-कभी फ़ाइल मौजूद होती है, फिर भी चेतावनी बनी रहती है। यही सबसे परेशान करने वाली बात है। समस्या हमेशा फ़ाइल के भीतर के टेक्स्ट में नहीं होती; WordPress में, असफलता अक्सर एक स्तर नीचे होती है—साइट उस फ़ाइल को क्रॉलर तक कैसे पहुँचाती है, इसमें।

अगर आपने ads.txt पहले ही जोड़ दिया है और Adgora फिर भी शिकायत कर रहा है, तो पहले WordPress के व्यवहार पर ध्यान दें: URL routing, redirects, cached copies, host rules, और security filters। किसी publisher के पास डिस्क पर सही फ़ाइल हो सकती है, फिर भी WordPress में ads.txt error दिख सकती है, क्योंकि request सही response तक पहुँच ही नहीं रही होती।

यह उन साइटों पर आम है जहाँ theme builder, CDN, और caching plugin तीनों एक साथ सक्रिय हों। एक setting response बदल देती है, दूसरी उसे cache कर देती है, और तीसरी browser को सब कुछ ठीक दिखाती है जबकि crawler को कुछ और मिलता है।

फ़ाइल को फिर से लिखने से शुरुआत न करें। पहले path, host, और response code जाँचें। इससे समय बचता है।

सबसे पहले Adgora में failure का सटीक प्रकार अलग करें

Adgora अलग-अलग तरह की समस्याएँ दिखा सकता है, और हर एक कुछ खास बताती है। Missing file, stale crawl से अलग है, और host mismatch redirect loop से अलग है।

चेतावनी ध्यान से पढ़ें। अगर Adgora कहता है कि फ़ाइल missing है, तो यह सीधे retrieval की समस्या है। अगर वह कहता है कि फ़ाइल मौजूद है लेकिन status गलत है, तो समस्या caching या response delivery में हो सकती है। अगर चेतावनी किसी खास domain variant का नाम लेती है, तो वह संकेत किसी भी सामान्य ads.txt troubleshooting checklist से ज़्यादा अहम है, खासकर जब संदेश ads.txt not found WordPress जैसा दिखे।

सिर्फ browser में जल्दी से जाँच करना पर्याप्त नहीं है। आपका browser local cache से लोड हुई फ़ाइल दिखा सकता है, जबकि Adgora का crawler live URL को fresh तरीके से request करता है। यही अंतर कई false alarms की वजह बनता है।

कुछ भी बदलने से पहले 4 चीज़ें लिख लें: exact warning text, वह URL जो Adgora अपेक्षित मान रहा है, वर्तमान live URL, और क्या फ़ाइल पिछले 24 घंटों में अपडेट हुई थी। ये विवरण failure को जल्दी सीमित कर देते हैं।

अगर dashboard एक host दिखा रहा है और आपकी साइट दूसरे पर जवाब दे रही है, तो आप एक समस्या नहीं देख रहे। आप दो endpoints देख रहे हैं।

जाँचें कि WordPress root domain और common variants कैसे serve करता है

WordPress एक ही साइट को कई addresses पर जवाब देने दे सकता है: www और non-www, HTTP और HTTPS, और कभी-कभी multisite setup से mapped domain भी। Adgora एक version की जाँच कर सकता है, जबकि आप किसी और version को टेस्ट कर रहे हों।

यह इसलिए मायने रखता है क्योंकि ads.txt root पर discover होता है। https://example.com/ads.txt के लिए request, https://www.example.com/ads.txt जैसी नहीं होती, भले ही front page एक जैसी दिखे। एक redirect सामान्य है; दो या तीन redirect crawler को भ्रमित कर सकते हैं, खासकर अगर chain किसी ऐसे page पर पहुँच जाए जो फ़ाइल है ही नहीं।

WordPress settings में site की canonical form जाँचें, फिर उसे Adgora द्वारा उपयोग किए जा रहे URL से मिलाएँ। अगर WordPress Address और Site Address अलग हैं, तो उस अंतर को नोट करें। यह फ़ाइल पर विचार होने से पहले ही request को गलत host पर भेज सकता है।

Trailing slash का व्यवहार भी असर डाल सकता है। /ads.txt से /ads.txt/ पर redirect ideal नहीं है, क्योंकि crawler को root पर एक साधारण text file चाहिए, directory-जैसे path की नहीं। छोटी बात, बड़ी परेशानी।

Domain-mapped installations में, mapped domain posts के लिए काम कर सकता है, जबकि root host file requests पर fail कर देता है। Multisite networks पर यह उम्मीद से ज़्यादा अक्सर होता है।

ऐसी caching layers देखें जो पुराना या खाली version परोस रही हों

Caching तब तक उपयोगी है जब तक वह समस्या न बने। CDN, host cache, plugin cache, और browser cache—ये सब फ़ाइल की पुरानी प्रति, या बिल्कुल कोई फ़ाइल नहीं, भी परोस सकते हैं, भले ही live version ठीक कर दिया गया हो।

Visitor के सबसे नज़दीकी cache से शुरू करें। अगर WordPress के सामने CDN है, तो पहले उसे purge करें। फिर host cache, फिर कोई page cache plugin, फिर अपना browser। क्रम मायने रखता है, क्योंकि cached 404 सही upload के बाद भी घंटों तक बना रह सकता है।

सब कुछ clear करने से पहले evidence इकट्ठा करें। browser में फ़ाइल का एक screenshot, Adgora की warning का एक screenshot, और आख़िरी update का एक timestamp सहेज लें। ये तीन चीज़ें यह साबित करने में मदद करती हैं कि crawler ने जाँच के समय stale copy देखी थी या नहीं।

WordPress monetization teams अक्सर भूल जाती हैं कि cache rules /ads.txt को सामान्य pages से अलग treat कर सकते हैं। कोई page cache HTML को छोड़ सकता है, लेकिन server rule या CDN edge cache फिर भी पुराना text response दे सकता है। यहीं एक छोटी फ़ाइल बड़ी देरी बन जाती है।

अगर आपका host edge caching देता है, तो पूछें कि क्या text files अलग से cache होती हैं। कुछ में होती हैं, कुछ में नहीं। फ़ाइल खराब मानने से पहले जवाब चाहिए।

सत्यापित करें कि WordPress tooling फ़ाइल को rewrite या hide तो नहीं कर रही

कई WordPress tools साफ़ ads.txt response में बाधा डाल सकते हैं। Security plugins direct file access block कर सकते हैं। Performance plugins static paths को compress या rewrite कर सकते हैं। Multilingual plugins किसी ऐसे URL को localize करने की कोशिश कर सकते हैं जिसे plain और exact ही रहना चाहिए।

Staging-to-live deployment tools भी जोखिम हैं। कोई deployment live root को फ़ाइल के पुराने version से overwrite कर सकता है, या केवल कुछ paths deploy करके ads.txt को पीछे छोड़ सकता है। Managed hosting rules भी फ़ाइल को move कर सकते हैं या root directory को protect कर सकते हैं, और यह miss करना आसान है क्योंकि dashboard फिर भी सामान्य दिखता है।

देखें कि क्या किसी plugin में file protection feature है। कोई भी setting जो root-level requests को plain text files के लिए rewrite करती हो, उसे बंद करें। फिर दोबारा test करें। एक setting दस मिनट के सावधानीपूर्वक काम को बिगाड़ सकती है।

Scheduled tasks भी जाँचें। कुछ optimization plugins timer पर फ़ाइलें regenerate करते हैं। अगर ads.txt बदलता है और फिर एक घंटे बाद वापस पुराना हो जाता है, तो संभव है कि कोई cron job पुरानी copy restore कर रहा हो।

अगर साइट multilingual layer का उपयोग करती है, तो पुष्टि करें कि ads.txt किसी language folder या translated route से serve नहीं हो रहा। इसे root पर ही रहना चाहिए, /en/ या किसी और subpath के नीचे नहीं।

Direct-response checks का उपयोग करें ताकि पता चले crawler वास्तव में क्या प्राप्त कर रहे हैं

फ़ाइल को browser में खोलना केवल इतना बताता है कि आपके browser ने क्या देखा। इससे यह साबित नहीं होता कि crawler ने क्या देखा। Direct-response checks बेहतर हैं, क्योंकि वे request के लिए सटीक HTTP result दिखाते हैं।

/ads.txt inspect करें और देखें कि response 200, 301, 302, 403, या 404 है या नहीं। 200 लक्ष्य है। 301 या 302 का मतलब है कि फ़ाइल पढ़े जाने से पहले ही उसे move किया जा रहा है। 403 का मतलब block है। 404 का मतलब request को उपयोगी फ़ाइल मिली ही नहीं।

Response body भी देखें। अगर body में HTML, theme page, या maintenance notice है, तो crawler को plain ads.txt file नहीं मिली। यही फर्क browser testing को अपने-आप भ्रामक बना सकता है।

एक direct URL और एक www prefix वाला variant जाँचें। अगर एक काम करता है और दूसरा नहीं, तो समस्या फ़ाइल की सामग्री में नहीं है। समस्या host handling में है।

यहीं कई टीमें अंदाज़ा लगाना छोड़कर मापना शुरू करती हैं। अच्छा कदम।

Direct check में क्या रिकॉर्ड करें

• माँगा गया exact URL, जिसमें www या non-www शामिल हो।
• HTTP status code।
• कोई भी redirect target।
• Response body की पहली 5 पंक्तियाँ।
• Headers में server या CDN का नाम।

WordPress monetization पर असर: चेतावनी को revenue risk कब मानें

हर ads.txt warning का मतलब यह नहीं कि अभी पैसा खो रहा है। कभी-कभी चेतावनी पुरानी होती है, और फ़ाइल पहले ही सही हो चुकी होती है। कभी यह पिछले crawl की false alarm होती है।

फिर भी, अगर चेतावनी एक से अधिक crawl cycle तक बनी रहती है, या कई buyer-facing tools mismatch रिपोर्ट करते हैं, तो इसे गंभीरता से लें। यहीं buyer trust और monetization workflows प्रभावित होने लगते हैं, खासकर अगर आप कई ad sources चलाते हैं और supply paths साफ़ रखने के लिए ads.txt verification पर निर्भर हैं, या यदि आपने WordPress ads.txt warning fix लागू करने के बाद भी अलर्ट नहीं हटे हैं।

अगर आपकी साइट subscriptions, sponsorships, या programmatic demand से जुड़ी है, तो यह फ़ाइल सिर्फ़ सजावट नहीं है। यह revenue setup का हिस्सा है। एक broken response purchase checks को रोक सकता है, approvals देर से कर सकता है, या buyer को inventory path पर सवाल उठाने को मजबूर कर सकता है।

अगर चेतावनी live root domain पर दिख रही है और cache clearing के बाद भी बनी रहती है, तो इस fix को अपने WordPress monetization checklist के ऊपर रखें। अगर चेतावनी आती-जाती रहती है, तो उसे 24 घंटे तक monitor करें, इससे पहले कि आप मान लें कि समस्या हल हो गई है।

हर alert महँगा नहीं होता। कुछ सिर्फ़ शोर होते हैं। लेकिन जो 2 साफ़ checks के बाद भी बना रहे, उसे तुरंत ध्यान चाहिए।

अगर आप अन्य ad formats भी manage करते हैं, तो file issue को campaign planning से अलग रखें। उदाहरण के लिए, जो टीमें वेब पुश विज्ञापनों के लिए क्रिप्टो पर काम करती हैं, वे अक्सर traffic और CTR पर ध्यान देती हैं, और फिर background में हर buyer check को प्रभावित करने वाली root-level delivery problem मिस कर देती हैं।

Unresolved WordPress-specific मामलों के लिए escalation path

अगर फ़ाइल सही है और चेतावनी फिर भी साफ़ नहीं हो रही, तो support को evidence का एक सघन पैकेज भेजें। सिर्फ screenshot न भेजें। इससे सभी की गति धीमी पड़ती है।

Live URL, redirect chain, response headers, cache status, और एक या दो screenshots शामिल करें। अगर आपने www और non-www दोनों जाँचे हैं, तो दोनों सूचीबद्ध करें। अगर CDN शामिल है, तो उसका नाम लिखें। अगर कोई plugin फ़ाइल को rewrite कर रहा है, तो वह भी बताएं।

जब support को exact path दिखता है, तो वे तेज़ी से verify कर सकते हैं। “यह अभी भी काम नहीं कर रहा” जैसी धुंधली बात एक और सवाल-जवाब का दौर शुरू कर देती है। https://example.com/ads.txt का https://www.example.com/ads.txt पर 302 redirect होना, फिर host cache से 403 आना, कहीं ज़्यादा उपयोगी जानकारी है।

अगर आप कई pages चलाते हैं जो साफ़ ad delivery पर निर्भर हैं, तो अन्य resources के लिए भी यही path document करें। WordPress साइट जो /ads.txt को ठीक से handle नहीं करती, वह अन्य root-level files को भी गलत handle कर सकती है, और यह ad operations के लिए महत्वपूर्ण है।

Adgora या अपने host को क्या भेजें

• वह exact live URL जो ads.txt serve करना चाहिए।
• Redirect chain की copy, अगर कोई हो।
• Response status code और headers।
• Last cache purge का timestamp।
• दो screenshots: browser result और Adgora warning।

अगर आप broader ad setup choices के साथ गहरा comparison चाहते हैं, तो क्रिप्टो विज्ञापन नेटवर्क लक्ष्यीकरण विकल्प गाइड यह समझने में मदद कर सकती है कि delivery issues audience issues से कैसे अलग हैं, जो तब उपयोगी है जब support ticket दोनों को मिला रहा हो।

कई ad products एक साथ चलाने वाले publishers के लिए, एक साफ़ फ़ाइल भी छूट सकती है अगर site पर एक खराब edge node या एक security rule हो। इसी वजह से आख़िरी जाँच हमेशा live HTTP response होनी चाहिए, न कि WordPress के editor के अंदर का view।

और अगर response गलत है, तो पहले response को ठीक करें।