reCAPTCHA Geçersiz Alan Adı Hatası: Site Anahtarı Uyarısı Nasıl Çözülür?

reCAPTCHA geçersiz alan adı hatası, formunuzdaki doğrulama kutusunun yerinde bir uyarı görmenize ya da formun hiç gönderilmemesine yol açar. Bu yazıda Talha Aslan ve ekibi olarak sorunu adım adım nasıl daraltacağınızı, hangi ayarı nerede kontrol edeceğinizi ve hatayı kalıcı olarak nasıl önleyeceğinizi anlatıyoruz.

Uyarının birebir metni sürüme ve dile göre değişebilir. Ekranda "site anahtarı için geçersiz alan adı" ya da benzeri bir uyarı görürsünüz. Google'ın resmi reCAPTCHA sık sorulan sorular sayfası ise yerel geliştirme ortamı için ayrı bir uyarıdan söz eder: localhost varsayılan olarak desteklenen alan adları arasında yer almaz.

Kısacası hata çoğu zaman kodda değil, ayardadır. Anahtar, adres ve sürüm üçlüsü birbirine uymadığında ortaya çıkar. Ardından gelen bölümlerde bu üçlüyü tek tek kontrol edeceğiz.

Hatanın hangi sayfada çıktığını da not edin. Sitede birden fazla form varsa ve yalnız biri uyarı veriyorsa sorun büyük olasılıkla o formun eklentisinde ya da sayfaya özel bir ayardadır. Tüm formlar etkileniyorsa genel anahtar ayarına odaklanın.

Hatayı ilk beş dakikada nasıl daraltırsınız?

Panik yapmadan önce sorunun nerede olduğunu bulmanız gerekir. Aşağıdaki sıra, en sık nedenden en nadire doğru ilerler. Böylece çoğu durumda ilk üç adımda çözüme ulaşırsınız.

1. Formun açıldığı tam adresi tarayıcının adres çubuğundan kopyalayın.
2. reCAPTCHA yönetim konsolunu açın ve bu siteye ait anahtarı bulun.
3. Anahtarın alan adı listesinde bu adresin kök alan adının yer aldığını kontrol edin.
4. Sitede kullandığınız site anahtarının konsoldaki anahtarla birebir aynı olduğunu doğrulayın.
5. Anahtarın türünü (v2 onay kutusu, v2 görünmez ya da v3) eklentinizdeki seçimle karşılaştırın.
6. Önbelleği temizleyin ve sayfayı gizli pencerede yeniden açın.
7. Çerez onayı aracınızın reCAPTCHA betiğini engelleyip engellemediğine bakın.

Ancak bu adımlardan sonra da sorun sürüyorsa sunucu tarafındaki doğrulamaya geçin. Örneğin gizli anahtar yanlışsa kutu görünür ama form yine gitmez. Bu ayrımı aşağıda ayrıca ele alıyoruz.

Alan adı listesi reCAPTCHA geçersiz alan adı uyarısına nasıl yol açar?

Google'ın alan adı doğrulama belgesi açıkça şunu söyler: web anahtarları, belirttiğiniz alan adlarıyla ve bunların birinci düzey alt alan adlarıyla sınırlıdır. Yani listeye yazdığınız ad, anahtarın çalışacağı sınırları çizer.

Belgedeki örneğe göre listeye kök alan adını yazdığınızda www sürümü ve birinci düzey alt alan adları da kapsama girer. Dolayısıyla çoğu sitede kök alan adını eklemek yeterlidir. Buna karşılık tamamen farklı bir alan adında, örneğin ayrı bir kampanya sitesinde aynı anahtarı kullanırsanız uyarı alırsınız.

Üstelik yazım hataları da sık karşınıza çıkar. Alan adının sonuna eğik çizgi, başına protokol ya da araya boşluk koymak listeyi bozabilir. Bu nedenle listeye yalnız çıplak alan adını yazın, örneğin example.com biçiminde.

• Doğru: example.com
• Gereksiz: www.example.com (kök ad zaten kapsar)
• Hatalı: https://example.com/ biçiminde protokol ve eğik çizgi
• Eksik: siteniz ikinci bir alan adında da yayındaysa o adı da ekleyin

www ve alt alan adları neden sorun çıkarır?

Sitenizin hem example.com hem de magaza.example.com gibi adreslerde çalıştığını düşünün. Kök alan adını listeye eklediyseniz ikisi de genellikle sorunsuz çalışır. Ancak listeye yalnız alt alan adını yazdıysanız kök adres kapsam dışında kalır.

Öte yandan çok katmanlı alt alan adlarında durum değişebilir. Resmi belge birinci düzey alt alan adlarından söz eder. Bu yüzden test.magaza.example.com gibi derin bir adres kullanıyorsanız onu ayrıca denemeniz ve gerekirse listeye eklemeniz akıllıca olur.

Örnek senaryo: bir firma sitesini www adresinden çıplak adrese taşıyor ve eski anahtarda yalnız www sürümü kayıtlı kalıyor. Bu durumda yönlendirme sonrası form uyarı verir. Çözüm basittir; listeye kök alan adını eklersiniz.

Test ortamı ve localhost için ne yapmalısınız?

Geliştirme ortamında hata almak çok yaygındır. Google, localhost adresinin varsayılan olarak desteklenmediğini belirtir. Ayrıca geliştirme ve canlı ortam için ayrı anahtar kullanmanızı önerir.

Bu nedenle canlı anahtarın listesine test adreslerini eklemek yerine ikinci bir anahtar açın. Böylece test ortamındaki yoğun deneme trafiği canlı sitenizin istatistiklerini kirletmez. Üstelik v3 kullanıyorsanız skor verileriniz de daha temiz kalır.

• Canlı anahtar: yalnız gerçek alan adınız.
• Test anahtarı: localhost, hazırlık (staging) adresi ve geçici alt alan adları.
• Ortam değişkeni: anahtarları koda gömmek yerine ortama göre seçin.

Google, v2 için her zaman geçen özel test anahtarları da sunar. Ancak bu anahtarlar kutuda bir uyarı gösterir; amaç canlı trafikte kullanılmalarını önlemektir. Yani siteyi yayına alırken test anahtarını unutursanız ziyaretçi uyarı görür.

Kendi başınıza çözemediğinizde ne yapmalısınız?

Yukarıdaki adımlar çoğu sorunu çözer. Ancak bazı sitelerde reCAPTCHA hatası daha derin bir yapı sorununun belirtisidir: tema içinde gömülü anahtarlar, birbirini ezen eklentiler, belgelenmemiş önbellek katmanları. Bu tür durumlarda deneme yanılma zaman kaybettirir.

Sıfırdan sağlam bir yapı kurmak istiyorsanız web sitesi yaptırmak konusundaki yaklaşımımıza göz atabilirsiniz. Formları, doğrulama katmanını ve önbellek kurallarını baştan uyumlu kurduğumuzda bu hatayla karşılaşma olasılığınız belirgin biçimde azalır.

Bu tür yapılarda her yeni eklenti ya da tema güncellemesi aynı sorunu yeniden doğurabilir. Dolayısıyla tek seferlik bir düzeltme yerine yapının sadeleştirilmesini hedeflemek daha kalıcı sonuç verir. Yine de önce aşağıdaki teknik bölümleri okuyun; çoğu durumda sorunu kendiniz bulursunuz.

Öte yandan yardım alacaksanız gizli anahtarı mesajla paylaşmayın. Bunun yerine yöneticinin konsola erişim izni vermesi daha güvenlidir.

v2 ve v3 anahtarlarını karıştırmak neye yol açar?

reCAPTCHA'nın farklı türleri farklı anahtarlar kullanır. v2 onay kutusu için açtığınız anahtar, v3 bekleyen bir eklentide çalışmaz. Tersi de geçerlidir. Bu karışıklık çoğu zaman alan adı uyarısına benzeyen bir hata ya da boş bir kutu olarak karşınıza çıkar.

Örneğin form eklentiniz v3 seçiliyken konsolda v2 anahtarı ürettiyseniz görünür kutu çıkmaz, form da doğrulamayı geçemez. Dolayısıyla eklenti ayarında seçtiğiniz tür ile konsoldaki anahtar türü aynı olmalıdır.

Kısacası tabloyu bir teşhis haritası gibi kullanın. Belirtiyi bulun, ardından yalnız o satırdaki kontrolü yapın. Böylece her şeyi aynı anda değiştirip hangi adımın işe yaradığını kaybetmezsiniz.

Gizli anahtar hatası nasıl anlaşılır?

Her reCAPTCHA kaydında iki anahtar yer alır. Site anahtarı tarayıcıda, gizli anahtar ise sunucuda çalışır. Kutu sorunsuz görünüp form yine de gönderilmiyorsa sorun büyük olasılıkla gizli anahtardadır.

Google'ın yanıt doğrulama belgesi sunucunun aldığı hata kodlarını listeler. Örneğin gizli anahtar eksikse ya da hatalıysa yanıtta buna karşılık gelen bir hata kodu döner. Yanıt çok eskiyse ya da daha önce kullanıldıysa ayrı bir kod görürsünüz.

Bu yüzden form eklentinizin günlük (log) kaydına bakın. Birçok eklenti doğrulama hatasını ayrıntısıyla kaydeder. Ayrıca site anahtarı ile gizli anahtarı yanlışlıkla yer değiştirmek sanıldığından sıktır; iki alanı yeniden kopyalayıp yapıştırmak çoğu zaman sorunu çözer.

Not: gizli anahtarı hiçbir zaman sayfa kaynağına, e-postaya ya da paylaşılan bir belgeye yazmayın. Sızdığını düşünüyorsanız konsoldan yeni anahtar üretin.

Ardından değişikliği kaydedin ve formu farklı bir cihazdan bir kez daha deneyin. İki ortamda da sonuç aynıysa sorunu doğru yerde aradığınızı bilirsiniz.

Önbellek reCAPTCHA hatasını neden sürdürür?

Anahtarı ya da alan adı listesini düzelttiniz ama uyarı hâlâ görünüyor olabilir. Bunun en yaygın nedeni önbellektir. Sayfa önbelleği, eski anahtarı içeren sayfayı ziyaretçilere sunmaya devam eder.

Ayrıca reCAPTCHA belirteci (token) kısa ömürlüdür ve yalnız bir kez doğrulanabilir. Önbelleğe alınmış bir sayfa eski bir belirteç taşırsa sunucu bunu reddeder. Bu nedenle form içeren sayfaları tam sayfa önbelleğinden çıkarmayı ya da belirteci gönderim anında üretmeyi düşünün.

1. Eklenti ya da sunucu önbelleğini temizleyin.
2. CDN kullanıyorsanız ilgili sayfayı orada da temizleyin.
3. Tarayıcı önbelleğini atlamak için gizli pencerede test edin.
4. Betik birleştirme ve geciktirme ayarlarında reCAPTCHA betiğini hariç tutun.

Özellikle betik geciktirme özellikleri reCAPTCHA'yı kullanıcı etkileşimine kadar bekletebilir. Böylece kutu geç yüklenir ya da form doğrulamasız gider ve sunucu onu geri çevirir.

Çerez onayı reCAPTCHA'yı nasıl engeller?

Çerez onay araçları, onay gelene kadar üçüncü taraf betikleri bekletebilir. reCAPTCHA da bir Google betiğidir. Dolayısıyla aracınız onu pazarlama ya da analiz kategorisine koyduysa ziyaretçi reddettiğinde kutu hiç yüklenmez.

Bu durum alan adı hatasıyla karışır, çünkü kullanıcı yalnız çalışmayan bir form görür. Sorunu ayırmak için çerezleri kabul edip formu yeniden deneyin. Kabulden sonra form çalışıyorsa sorun onay ayarındadır.

Ancak bu noktada hukuki bir karar da vermeniz gerekir. reCAPTCHA'yı hangi kategoriye koyacağınız ve aydınlatma metninde nasıl anlatacağınız sizin sorumluluğunuzdadır. Bu yazı hukuki danışmanlık değildir; kararı hukuk danışmanınızla birlikte verin. Bant tasarımı için çerez bandı tasarımı rehberimize göz atabilirsiniz.

Öte yandan onay reddedildiğinde formu tamamen kapatmak yerine kullanıcıya açık bir mesaj gösterin. Böylece ziyaretçi neden gönderim yapamadığını anlar.

v3 skor eşiği formu neden reddeder?

reCAPTCHA v3 kullanıcıya kutu göstermez. Bunun yerine her etkileşime bir skor verir. Google'ın v3 belgesine göre skor 0,0 ile 1,0 arasındadır; 1,0 büyük olasılıkla gerçek bir etkileşimi, 0,0 ise büyük olasılıkla bir botu gösterir.

Belge başlangıç için 0,5 eşiğini önerir. Ayrıca önce hiçbir işlem yapmadan trafiği izlemenizi, ardından eşiği ayarlamanızı tavsiye eder. Yani eşiği ilk günden yüksek tutarsanız gerçek ziyaretçileri de reddedebilirsiniz.

Örnek senaryo: bir site eşiği çok yüksek ayarlıyor ve VPN kullanan ya da çerezleri sık temizleyen ziyaretçilerin formu geri dönüyor. Bu kişiler alan adı uyarısı görmez ama formu gönderemez. Çözüm, konsoldaki skor dağılımına bakarak eşiği kademeli düşürmektir.

Üstelik v3'te eylem (action) adını da doğrulamanız gerekir. Belge, dönen eylemin beklediğinizle eşleşmesini kontrol etmenizi söyler. Eylem uyuşmazsa sunucunuz isteği reddedebilir.

Alan adı doğrulamasını kapatmak çözüm mü?

Konsolda alan adı doğrulamasını kapatma seçeneği yer alır. Google bunu çok uzun ya da sürekli değişen alan adı listeleri için sunar. Ancak aynı belge bunun ciddi bir güvenlik riski yarattığını açıkça söyler.

Doğrulamayı kapattığınızda anahtarınızı herhangi bir site kullanabilir. Bu yüzden Google, bu durumda her doğrulama yanıtındaki ana makine (hostname) alanını kontrol etmenizi ve beklenmeyen kaynakları reddetmenizi şart koşar. Yani kontrolü Google'dan alıp kendi sunucunuza taşırsınız.

Kısacası tek bir sitesi olan işletmeler için bu yol gereksizdir. Alan adını listeye doğru eklemek hem daha güvenli hem de daha az bakım ister. Doğrulamayı kapatmayı yalnız çok sayıda alan adı yöneten ve sunucu tarafını kontrol edebilen ekipler düşünmelidir.

WordPress form eklentilerinde reCAPTCHA geçersiz alan adı hatası nasıl giderilir?

WordPress sitelerde reCAPTCHA çoğu zaman form eklentisi ya da ayrı bir güvenlik eklentisi üzerinden gelir. Sorun da sıklıkla burada başlar: iki eklenti aynı sayfaya iki farklı anahtar yükler.

1. Sitede reCAPTCHA ekleyen tüm eklentileri listeleyin.
2. Yalnız birinin reCAPTCHA yüklemesine izin verin.
3. Bu eklentide site ve gizli anahtarı yeniden girin.
4. Seçilen sürümün konsoldaki türle aynı olduğunu kontrol edin.
5. Önbelleği temizleyip formu gizli pencerede gönderin.

Örneğin hem form eklentiniz hem de giriş sayfasını koruyan güvenlik eklentiniz reCAPTCHA ekliyorsa sayfada iki betik çakışır. Böylece biri v2, diğeri v3 isteyebilir. Dolayısıyla tek kaynağa inmek en temiz çözümdür.

Formdan e-posta gelmiyorsa sorun reCAPTCHA olmayabilir. Bu durum için iletişim formundan mail gelmiyor rehberimize bakın.

Form tasarımı doğrulama hatalarını nasıl etkiler?

Doğrulama hatası teknik bir sorundur ama kullanıcı onu tasarım olarak yaşar. Form gönderilmediğinde ziyaretçi genellikle neden olduğunu bilmez. Bu yüzden hata anında net bir mesaj göstermek, kaybı ciddi ölçüde azaltır.

Örneğin "Doğrulama tamamlanamadı, lütfen sayfayı yenileyip tekrar deneyin" gibi açık bir uyarı, sessiz bir başarısızlıktan çok daha iyidir. İyi hata metinleri için form hata mesajları rehberimize bakabilirsiniz.

Ayrıca formun genel kurgusu da önemlidir. Gereksiz alanlar ve karmaşık adımlar, doğrulama sorunu olmasa da dönüşümü düşürür. Bu konuyu form tasarımında dönüşümü artıran unsurlar yazımızda ayrıntılı anlattık.

Ayrıca formun başarı sayfası da ölçüm için önemlidir. Gönderim sonrası ayrı bir teşekkür sayfası kullanırsanız doğrulama sorunlarını analiz verilerinde daha kolay fark edersiniz. Örneğin teşekkür sayfasına gelen ziyaret aniden düştüyse ilk bakacağınız yer reCAPTCHA ayarları olmalıdır.

reCAPTCHA yerine hangi doğrulama yöntemlerini düşünebilirsiniz?

reCAPTCHA tek seçenek değildir. Piyasada gizlilik dostu doğrulama araçları da var. Bu araçlar genellikle daha az veri toplar ve bazıları kullanıcıya hiç bulmaca göstermez.

Ancak araç değiştirmek her zaman sorunu çözmez. Alan adı listesi, anahtar uyumu ve önbellek mantığı benzer araçların çoğunda aynı biçimde çalışır. Dolayısıyla temel kontrolleri öğrenmek, hangi aracı kullanırsanız kullanın işinize yarar.

• Gizli alan (honeypot): botların doldurduğu, kullanıcının görmediği bir alan.
• Zaman kontrolü: formun çok hızlı doldurulmasını şüpheli sayma.
• Sunucu tarafı filtre: bilinen spam kalıplarını ayıklama.
• Gizlilik dostu doğrulama araçları: daha az veriyle çalışan alternatif servisler.

Spam ile mücadelenin bütününü iletişim formu spam nasıl durdurulur yazımızda ele aldık.

Site taşıma sonrası reCAPTCHA geçersiz alan adı uyarısı neden çıkar?

Alan adı değişikliği, bu hatanın en sık tetikleyicilerinden biridir. Siteyi yeni adrese taşırsınız, içerik ve ayarlar aynen gelir. Ancak reCAPTCHA anahtarı hâlâ eski alan adına kayıtlıdır.

Bu yüzden taşıma kontrol listenize reCAPTCHA'yı da ekleyin. Yeni alan adını mevcut anahtarın listesine eklemek genellikle yeterlidir. Eski adresten yönlendirme sürdüğü sürece iki adı birlikte tutabilir, yönlendirme kalktıktan sonra eskisini silebilirsiniz.

Benzer bir durumla ajans ya da geliştirici değişikliğinde de karşılaşırsınız. Önceki ekip anahtarı kendi Google hesabında açmış olabilir. Böylece siz konsola erişemezsiniz. Bu durumda kendi hesabınızda yeni bir anahtar açıp siteye girmek en temiz yoldur.

Görsellerde de taşıma sonrası benzer sorunlarla karşılaşabilirsiniz; bulanık logo için logo ve görseller bulanık görünüyor rehberimize göz atın.

Tarayıcı geliştirici araçlarıyla hatayı nasıl doğrularsınız?

Ekrandaki uyarı her zaman tüm hikâyeyi anlatmaz. Bu yüzden tarayıcının geliştirici araçlarını açmak, sorunun kaynağını hızla gösterir. Çoğu tarayıcıda sayfaya sağ tıklayıp incele seçeneğiyle bu panele ulaşırsınız.

Konsol sekmesinde reCAPTCHA ile ilgili kırmızı satırlara bakın. Örneğin betik yüklenemiyorsa ağ hatası, anahtar uyuşmuyorsa ilgili uyarı burada çıkar. Ardından ağ sekmesinde Google'ın reCAPTCHA adreslerine giden isteklerin başarılı dönüp dönmediğini kontrol edin.

• İstek hiç yoksa: betik sayfaya eklenmemiş ya da bir eklenti onu engelliyor.
• İstek engellenmiş görünüyorsa: reklam engelleyici, çerez aracı ya da güvenlik politikası devrede.
• Yanıt başarılı ama uyarı sürüyorsa: sorun büyük olasılıkla alan adı listesinde ya da anahtar türünde.

Böylece tahmin yürütmek yerine kanıta dayanarak ilerlersiniz. Üstelik bir geliştiriciden yardım alacaksanız bu ekran görüntüleri işi ciddi ölçüde hızlandırır; yalnız gizli anahtarın görüntüde yer almadığından emin olun.

Reklam engelleyiciler ve gizlilik eklentileri neden karışıklık yaratır?

Bazı ziyaretçiler formu sorunsuz kullanırken bazıları hiç kutu görmez. Bu tablo genellikle alan adı ayarına değil, ziyaretçinin tarayıcısına işaret eder. Reklam engelleyiciler ve gizlilik eklentileri Google betiklerini engelleyebilir.

Dolayısıyla hatayı tek bir bilgisayarda gördüyseniz önce o tarayıcının eklentilerini kapatıp deneyin. Ardından aynı sayfayı başka bir tarayıcıda ve mobil veri bağlantısıyla açın. Sorun yalnız tek ortamda çıkıyorsa sitenizdeki ayarlar büyük olasılıkla doğrudur.

Ancak bu ziyaretçileri tamamen göz ardı etmeyin. Kutu yüklenmediğinde formun altına kısa bir açıklama koymak işe yarar. Örneğin doğrulama yüklenmezse engelleyiciyi bu site için kapatmayı ya da sizinle telefon veya e-posta üzerinden iletişime geçmeyi önerebilirsiniz.

Bu yaklaşım, talep kaybını teknik sorundan bağımsız olarak azaltır. Yani doğrulama başarısız olsa bile müşteri size ulaşmanın bir yolunu bulur.

İçerik güvenlik politikası reCAPTCHA'yı engelleyebilir mi?

Evet, engelleyebilir. İçerik güvenlik politikası (Content Security Policy, kısaca CSP), tarayıcıya hangi kaynaklardan betik, çerçeve ve bağlantı yükleyebileceğini söyleyen bir güvenlik başlığıdır. Sunucunuzda bu başlık sıkı tanımlıysa ve Google'ın reCAPTCHA adresleri izinli listede değilse kutu yüklenmez.

Bu durumda konsolda politika ihlaline dair açık bir uyarı görürsünüz. Çözüm, Google'ın reCAPTCHA için kullandığı alan adlarını betik ve çerçeve kurallarına eklemektir. Güncel adres listesini Google'ın resmi belgelerinden kontrol edin, çünkü bu liste zamanla değişebilir.

Öte yandan güvenlik başlıklarını çoğu zaman barındırma paneli, güvenlik eklentisi ya da CDN ekler. Bu yüzden hangi katmanın başlığı yazdığını bulmanız gerekir. Aksi halde bir yerde düzelttiğiniz kural başka bir katmanda yeniden ezilir.

Not: güvenlik başlıklarını tamamen kaldırmak hızlı bir çözüm gibi görünse de sitenizi başka risklere açar. Kuralı daraltarak düzeltmek her zaman daha doğrudur.

Anahtarın sahibi kim olmalı ve erişimi nasıl yönetirsiniz?

reCAPTCHA anahtarları bir Google hesabına bağlıdır. Anahtarı kim açtıysa konsol üzerinde o kişi yetkilidir. Bu yüzden anahtarın kimin hesabında olduğu, hatayı çözüp çözemeyeceğinizi doğrudan belirler.

Örnek senaryo: siteyi yıllar önce bir serbest geliştirici kurmuş ve anahtarı kendi hesabında açmış. Şimdi alan adı değişti ama kimse konsola giremiyor. Bu durumda eski anahtarı onarmanın yolu yoktur; yeni bir anahtar açmanız gerekir.

Bu nedenle anahtarları şirketin kurumsal Google hesabında açın. Ayrıca konsolda birden fazla yöneticiye erişim tanımlamak, tek bir kişiye bağımlılığı ortadan kaldırır. Böylece çalışan ya da tedarikçi değiştiğinde formlarınız sahipsiz kalmaz.

Kısacası anahtar yönetimi teknik bir ayrıntı gibi görünse de iş sürekliliğinin bir parçasıdır. Erişim listesini yılda en az bir kez gözden geçirmek iyi bir alışkanlıktır.

Sorunu kalıcı olarak nasıl önlersiniz?

Hatayı bir kez çözmek yetmez; tekrarlamaması için küçük bir düzen kurmanız gerekir. Aşağıdaki liste, ekibimizin form içeren her projede uyguladığı temel kontrollerdir.

• Anahtarları şirketin kendi Google hesabında açın, kişisel hesapta değil.
• Canlı ve test ortamı için ayrı anahtar kullanın.
• Alan adı listesini her taşıma ya da yeni alt alan adında güncelleyin.
• Formu her eklenti güncellemesinden sonra gerçek bir gönderimle test edin.
• Form içeren sayfaları tam sayfa önbelleğinden hariç tutun.
• Sunucu tarafında ana makine ve eylem alanlarını doğrulayın.

Böylece hata çıktığında hangi ayarın değiştiğini hızla bulursunuz. Üstelik anahtarların kimde olduğu sorusu da ortadan kalkar.

Bu listeyi bir belgeye yazıp ekiple paylaşmak, kişiye bağlı bilgi riskini de azaltır. Ardından her yeni projede aynı belgeyi şablon olarak kullanırsınız. Böylece reCAPTCHA geçersiz alan adı uyarısı, yayına alma gününde sizi şaşırtmaz.

Hangi durumda yeni bir anahtar üretmelisiniz?

Bazen mevcut anahtarı onarmak yerine yenisini açmak daha hızlıdır. Google'ın sık sorulan sorular sayfası, geçersiz site anahtarı uyarısında anahtarın artık geçerli olmadığını ve yeni bir anahtar kaydetmeniz gerektiğini belirtir.

Ayrıca konsola erişiminiz yoksa, gizli anahtarın sızdığından şüpheleniyorsanız ya da sürüm değiştirmek istiyorsanız yeni anahtar açın. Ardından eski anahtarı siteden tamamen kaldırın ki iki anahtar çakışmasın.

Not: yeni anahtar ürettikten sonra hem site anahtarını hem gizli anahtarı aynı anda değiştirin. Yalnız birini değiştirmek, kutunun görünüp formun gitmediği tipik tabloyu yeniden yaratır.

Ayrıca yeni anahtara geçtikten sonra konsoldaki istatistikleri birkaç gün izleyin. İstek sayısı beklediğiniz düzeydeyse ve hata görünmüyorsa geçiş tamam demektir. Aksi halde sitede eski anahtarı yükleyen bir kalıntı kalmış olabilir; tema dosyalarını ve eklenti ayarlarını yeniden tarayın.

Profesyonel destek hangi noktada mantıklı olur?

Basit bir alan adı eksikliğini birkaç dakikada kendiniz çözebilirsiniz. Ancak hata birden fazla eklentiye, özel temaya ve farklı önbellek katmanlarına yayıldıysa sorunu izole etmek uzmanlık ister. Bu noktada yanlış ayar, spam kapısını tamamen açabilir.

Formlarınızın güvenilir çalışması, doğrudan müşteri talebi demektir. Bu yüzden form altyapısını, doğrulamayı ve önbellek kurallarını birlikte ele alan profesyonel web tasarım desteği, uzun vadede sizi tekrar eden hatalardan korur. Ekibimiz kurulumdan sonra da formların test edilebilir kalmasını önemser.

Formlarınızı düzenli test etmek de bu desteğin parçasıdır. Ekibimiz yayına alma öncesinde her formu gerçek bir gönderimle dener, ardından bildirim e-postasının ulaştığını kontrol eder. Böylece sorun ziyaretçiden önce bizim karşımıza çıkar.

Sonuç olarak reCAPTCHA geçersiz alan adı hatası korkutucu görünse de çoğu zaman tek bir ayar satırına iner. Adımları sırayla izleyin, her değişiklikten sonra test edin ve anahtarlarınızı kendi hesabınızda tutun.