Staging'e işaret eden bir kanonik URL'yi düzeltme
Staging'e işaret eden bir kanonik, neredeyse her zaman bir sürümle veya bir veritabanı kopyasıyla birlikte taşınan bir temel URL yapılandırma değeridir; değeri üretim ortamı için düzeltin, veya kanoniği saklanan bir sabit yerine istek ana bilgisayarından oluşturun. Canlı sayfalar tüm süre boyunca 200 döndürmeye devam eder, bu yüzden bu genellikle bir uyarıda değil bir trafik grafiğinde bulunur.
Belirti neye benzer
Canlı sitedeki her sayfa, farklı bir ana bilgisayarı adlandıran bir kanonik sunar:
curl -s https://example.com/pricing | grep -i 'rel="canonical"'
<link rel="canonical" href="https://staging.example.com/pricing">
Search Console bunu "Yinelenen, Google kullanıcıdan farklı bir kanonik seçti" olarak, veya hiç doğrulamadığınız bir ana bilgisayardaki kullanıcı tarafından bildirilmiş bir kanonikle sonuçlardan düşen sayfalar olarak gösterir. Staging ana bilgisayarı normalde erişilemez, şifreyle korunmuş veya noindex olduğundan, birleşmenin inebileceği bir hedef yoktur, bu yüzden canlı sayfalar her yeniden taramada birer birer sıralanmayı bırakır. Hiçbir şey 500 vermez ve hiçbir çalışma süresi kontrolü bunu fark etmez, ki bu da onu pahalıya mal eden şeydir.
Yanlış temel URL nereden gelir
- Staging'den geri yüklenen bir veritabanı. WordPress'te
siteurlvehomeseçenek satırları, staging ana bilgisayar adını üretime taşır, ve oluşturulan her URL onları izler. - Dağıtılan derlemedeki bir ortam değişkeni. Derleme zamanında gömülen bir site URL'si, bu yüzden çalışma zamanı ortamı ne derse desin derlenmiş çıktı staging'in değerini taşır.
- Ortam başına yapılandırılmış bir çerçeve varsayılan ana bilgisayarı, staging'inki güncellendikten sonra üretim yapılandırmasının hiç güncellenmediği.
- Paylaşılan bir düzende veya SEO eklenti ayarında sabit kodlanmış mutlak bir URL, bir göç sırasında yazılmış ve hiç yeniden ziyaret edilmemiş.
- Yanlış ana bilgisayarda oluşturulmuş önbelleğe alınmış bir sayfa. Bir staging derlemesiyle doldurulmuş bir CDN veya tam sayfa önbelleği, yapılandırma düzeltildikten çok sonra bile staging kanoniğiyle bayat HTML sunar.
Değeri düzeltin, sonra hata sınıfını kaldırın
- Saklanan temel URL'yi üretim için, yukarıdaki yerlerden hangisi geçerliyse orada düzeltin. WordPress'te bu, iki seçenek satırı artı staging kopyası tarafından gönderi içeriğine yazılmış herhangi bir mutlak URL'dir.
- Değer derlenmişse yeniden derleyin ve yeniden dağıtın. Yeniden derleme olmadan bir ortam değişkenini değiştirmek, eski değeri gönderilen pakette bırakır.
- Yoldaki her önbelleği temizleyin, uygulama, CDN ve edge dahil. Staging HTML'iyle dolu bir önbelleğin arkasındaki düzeltilmiş bir kaynak, önbellek yaşadığı sürece düzeltilmemiş görünür.
- Saklanan bir sabiti okumak yerine kanoniği istek ana bilgisayarından türetmeyi tercih edin. İsteği sunan ana bilgisayardan oluşturulan bir kanonik, sunulduğu ortamda yanlış olamaz, ki bu da bu örneği değil tüm hata sınıfını ortadan kaldırır.
- Staging'i başka yollarla indeksin dışında tutun. Staging ana bilgisayarını koruması gereken şey HTTP kimlik doğrulaması veya bir IP izin listesidir, bir kanonik değil, ve bir yapılandırma dosyasıyla birlikte taşınabilen bir noindex değil.
Düzeltmeyi üretimde doğrulayın
Şablonu değil yanıtı okuyun, çünkü eklentiler, edge worker'lar ve önbellekler hepsi deponuzda görünmeyen kanonikler ekler:
curl -s https://example.com/pricing | grep -i 'rel="canonical"'
curl -sI https://example.com/pricing | grep -i '^link:'
Sonra birden fazla sayfa kontrol edin. Kanonik bir şablon tarafından oluşturulur, bu yüzden ana sayfayı doğru yapmak ürün sayfaları, sayfalanmış listeler veya farklı bir düzenle oluşturulan herhangi bir şey hakkında hiçbir şey kanıtlamaz. Search Console'da, URL İnceleme, kullanıcı tarafından bildirilen kanoniği Google'ın seçtiğinin yanında gösterir, ve bir yeniden taramadan sonra ikisinin uyuşması önemli olan doğrulamadır. O yeniden tarama günler sürer, bu yüzden düzeltilmiş bir kanonik trafiği aynı öğleden sonra geri getirmez.
Yeniden gönderilmesini önleyin
İki koruma neredeyse hiçbir şeye mal olmaz. İlki bir dağıtım zamanı doğrulamasıdır: bir sürümden sonra, birkaç üretim URL'si getirin ve herhangi bir kanonik üretim olanından başka bir ana bilgisayarı adlandırıyorsa dağıtımı başarısız kılın. İkincisi, sonrasında izlemeye devam etmektir, çünkü arıza bir kod dağıtımıyla olduğu kadar bir veritabanı geri yüklemesiyle veya bir eklenti ayarıyla da gelme olasılığı yüksektir. HostTracker'ın HTTP kontrolleri, yanıt gövdesine ve başlıklarına karşı iddialarda bulunabilir, bu yüzden bir sayfadaki kanonik etiket beklediğiniz şey olmadığında zamanlanmış bir kontrolün başarısız olması sağlanabilir, ve o başarısızlık diğer her şey gibi uyarır.
Her şablonu kontrol edin, tek bir sayfayı değil
Ücretsiz kanonik kontrol aracında etkilenen bir URL ile başlayın: kanoniği çözer ve başka bir ana bilgisayara işaret edeni işaretler, ki bu da tam olarak bir staging kanoniğinin nasıl göründüğüdür. Sonra hepsine bir kerede bakarak sorunun tek bir sayfa mı yoksa tek bir düzen mi olduğunu görün. Ücretsiz site tarama aracı siteyi gezer ve URL başına bir kanonik durumu, genellikle kötü bir dağıtıma eşlik eden noindex bayrakları ve yinelenen gövdelerle birlikte raporlar. Bir sonrakini gönderildiği gün yakalamak için, anahtar sayfalarınız için bir HTTP monitöründe İndekslenebilirlik seçeneğini açın: her kontrolde kanoniği okur ve değiştiğinde bir bildirim gönderir. SEO izleme, bunun nasıl çalıştığını kapsar.