GitHub ile SEO Düzeltmesi: Pull Request ile Otomatik Onarım

Kendi kodunuzla çalışan bir siteniz varsa, SEO düzeltmelerinin en sağlam yeri sitenin deposudur. Değişiklik kodun içine girer, siteyle birlikte yayınlanır ve Google sayfayı ilk okuduğunda düzeltilmiş HTML'i görür. GitHub ile seo düzeltmesi tam olarak bunu yapar: Otopilot hazırladığı düzeltmeleri deponuzda ayrı bir dala yazar, size bir pull request açar ve kararı size bırakır. Siz inceleyip birleştirirsiniz, site yeniden yayınlanır, düzeltmeler canlıya çıkar.

Bu yazıda GitHub kanalının hangi sitelere uygun olduğunu, nasıl bağlandığını, pull request'in yaşam döngüsünü ve yeni Yayın betikleri sekmesinden bir sürümü nasıl geri alacağınızı anlatıyoruz. Kanal, SEO Onarım'ın kanallarından biridir; genel işleyişi SEO onarım sayfasında bulabilirsiniz.

GitHub kanalı hangi sitelere uygun?

Otopilot'un en kolay kurulan kanalı Pixel'dir. Ama Pixel düzeltmeleri ziyaretçinin tarayıcısında, sayfa açıldıktan sonra uygular. Google sayfayı önce sunucunun gönderdiği ilk HTML'den okur, JavaScript'i çalıştırma aşaması ise her zaman hemen gelmez. Pixel ayrıca robots.txt gibi sunucuda duran dosyalara ya da yönlendirmelere hiç dokunamaz.

GitHub kanalı farklı bir yoldan gider. Düzeltme sitenin içine girmez; sitenin okuduğu bir kural dosyasına yazılır. Sitenizdeki Next.js bağlayıcı paketinin yardımcıları bu dosyayı sunucu tarafında okur ve başlığı, meta açıklamayı, yapısal veriyi sayfa daha tarayıcıya gitmeden yerine koyar. Bu yüzden kanal, Kanallar ekranında sunucu tarafı kanal olarak işaretlidir.

Kanallar bölümündeki Önerilen kanal sekmesi sitenizin altyapısına bakar. GitHub kanalını yalnızca Next.js, Nuxt ve statik sitelerde ya da altyapısı tespit edilemeyen sitelerde önerir. WordPress ya da hazır bir mağaza altyapısı kullanıyorsanız GitHub listede çıkmaz; orada eklenti ya da mağaza kanalı daha doğru yoldur. Etkin kanalınız Pixel ise kart, düzeltmelerin Google'ın ilk okumasında görüneceğini ayrıca belirtir.

Kısa bir karşılaştırma işinize yarayabilir:

Cloudflare arkasındaki siteler için diğer sunucu tarafı yolu Cloudflare Worker yazımızda anlattık.

GitHub ile SEO düzeltmesi nasıl çalışır?

İşleyiş dört adımlık bir döngüdür.

Birincisi, Otopilot bu kanala atanmış ve uygulanmaya hazır düzeltmeleri toplar. Her düzeltmeyi kanalın anlayabildiği kurallara çevirir ve sayfa yoluna göre gruplar. İkincisi, deponuzda otopilot/seo-duzeltmeleri adlı bir dal açar; dal zaten varsa ve açık bir pull request yoksa dalı taban dalınızın son haline göre yeniler. Bu dalda yalnızca kural dosyası değişir, başka hiçbir dosyaya dokunulmaz. Commit mesajı kaç düzeltmenin eklendiğini yazar.

Üçüncüsü, bu daldan taban dalınıza "Otopilot: SEO düzeltmeleri" başlıklı bir pull request açılır. Açıklamada kaç sayfa düzeltmesinin hangi dosyada olduğu, birleştirince ne olacağı ve nasıl geri alınacağı yazar. Dördüncüsü, siz birleştirir ve siteyi yeniden yayınlarsınız. Next.js bağlayıcı paketinin pageOverrides, siteFile ve redirectFor yardımcıları kural dosyasını okur ve düzeltmeleri sunucu tarafında uygular.

Kanalın yazabildiği alanlar sınırlıdır. Bu sınır koddadır ve panelde de aynen gösterilir:

• Başlık etiketi ve meta açıklama
• Canonical bağlantısı ve robots meta etiketi
• Open Graph başlığı ve açıklaması
• Yapısal veri (JSON-LD şema)
• Yönlendirmeler
• robots.txt ve site haritası

Sayfa içeriği, ara başlıklar, görsel alt metinleri, iç bağlantılar, güvenlik başlıkları ve blog yazısı yayını bu kanalla yapılmaz. Bu alanlardan birine dokunan bir düzeltme pull request'e girmez; kurulum kartı kaç düzeltmenin bu yüzden dışarıda kaldığını yazar. Böyle takılan düzeltmeleri çözmenin yollarını uygulanmayan düzeltmeler yazımızda, kodla yapılması gereken işleri ise geliştirici görevleri yazımızda topladık.

Önemli bir ayrıntı: yardımcıların sitenizde bir kez kurulmuş olması gerekir. Bağlayıcı paketinin kılavuzu App Router için gereken parçaları tek tek sayar: generateMetadata içinde toMetadata(pageOverrides(...)) çağrısı, JSON-LD için jsonLdScripts, robots.txt ve site haritası için rota dosyaları, yönlendirmeler için de middleware. Eklemediğiniz parça sitede görünmez. Örneğin middleware kurmadıysanız yönlendirme kuralı dosyaya yazılır ama ziyaretçi eski adreste kalır.

Middleware konusunda sürüm farkı da var. Yardımcılar dosyayı Node.js dosya sistemiyle okur. Next.js 15.5 ve üstünde şablon middleware'i Node.js çalışma ortamına alır; Next.js 16'da dosyanın adı proxy olur. Daha eski sürümlerde yönlendirmeleri next.config içindeki redirects ayarına allRedirects ile vermeniz gerekir. Yardımcılar okudukları sonucu kısa süre bellekte tutar, yayından sonra değişikliğin görünmesi bir dakikayı bulabilir.

Kurulum: jeton, depo, taban dal ve kural dosyası

Kurulum SEO Onarım'ın Kanal & Kurulum ekranındaki GitHub kartından yapılır. Önce GitHub'da ince ayrıntılı erişim jetonu (fine-grained token) oluşturun:

1. GitHub'da Settings, Developer settings ve Fine-grained tokens yolunu izleyin.
2. Depo erişimini yalnızca bu siteye ait depoyla sınırlayın.
3. Contents ve Pull requests izinlerini okuma-yazma, Metadata iznini okuma olarak verin.

Ardından karttaki dört alanı doldurun. Depo alanına sahip ve depo adını sahip/ad biçiminde ya da deponun GitHub adresini yazın. Jeton alanına az önce oluşturduğunuz jetonu yapıştırın. Hedef dal, pull request'in açılacağı taban daldır; boş bırakırsanız main kullanılır. Kural dosyası yolu, düzeltmelerin yazılacağı JSON dosyasıdır; kart bu alanı bağlayıcı paketinin varsayılan okuduğu yolla doldurur, değiştirmeniz için bir neden yoksa olduğu gibi bırakın.

Depoyu bağla dediğinizde panel önce GitHub'a deponun ve hedef dalın var olup olmadığını sorar. Depo bulunamazsa, dal yoksa ya da jetonun yazma yetkisi yoksa bağlantı kurulmaz ve kart hangi sorunun çıktığını yazar. Jeton panelde şifreli saklanır, form kaydedildikten sonra ekrandan silinir.

Bağlantıdan sonra GitHub'ı etkin kanal yapın. Kanal etkin değilse eşitleme düzeltme göndermez ve kart bunu açıkça söyler. İlk pull request için PR'ı şimdi güncelle düğmesini kullanabilirsiniz.

Birkaç güvenlik notu:

• Jetonu tüm hesabınıza değil, yalnızca bu depoya yetkili oluşturun.
• Jetona bir bitiş tarihi verin ve süresi dolmadan yenileyin. Jeton geçersiz olursa kanal hata durumuna geçer ve bağlantı testi bunu gösterir.
• Taban dalınızda dal koruması ve zorunlu inceleme açıksa açık bırakın. Otopilot birleştirme yapmaz, yalnızca pull request açar.

Pull request birleştirilince, kapatılınca ya da güncellenince

Pull request açıldığında içine giren düzeltmeler panelde "çekildi" durumuna geçer. Bu, düzeltmenin yolda olduğu ama henüz sitede olmadığı anlamına gelir.

Eşitleme iki yoldan çalışır. Birincisi elle: kurulum kartındaki PR'ı şimdi güncelle düğmesi. İkincisi otomatik: bağlantı sağlığını kontrol eden saatlik tarama her GitHub bağlantısı için eşitlemeyi de çalıştırır. Her eşitlemede panel önce açık pull request'in durumuna bakar, sonra kural dosyasını yeni düzeltmelerle karşılaştırır.

Birleştirilmiş bir pull request görürse içindeki düzeltmeleri uygulandı sayar; ardından doğrulama sayfaları siteden kontrol eder. Birleştirilmeden kapatılmış bir pull request görürse içindeki düzeltmeleri yeniden hazır duruma döndürür. Yani kapatmak düzeltmeleri silmez; bir sonraki eşitlemede yeni bir pull request'e yeniden girerler. Bir düzeltmeyi gerçekten istemiyorsanız panelden geri alın.

Açık bir pull request varken yeni düzeltmeler hazırlanırsa yeni bir pull request açılmaz. Aynı daldaki kural dosyası güncellenir, açık pull request kendiliğinden yeni hali gösterir. Kural dosyası değişmemişse hiçbir şey yazılmaz ve kart "Değişiklik yok; PR güncel." der.

Bir örnek düşünelim. Next.js ile yapılmış bir kurumsal sitede Otopilot on iki sayfanın başlığını ve açıklamasını, eski bir hizmet sayfası için de bir yönlendirmeyi hazırlamış. Siz bunları onayladınız, eşitleme pull request'i açtı. Geliştiriciniz değişiklik listesine bakıp bir sayfanın başlığını beğenmedi. Bu durumda pull request'i kapatmak yerine o düzeltmeyi panelden geri almak daha temiz bir yoldur: bir sonraki eşitlemede kural dosyası o düzeltme olmadan güncellenir, kalan değişiklikler aynı pull request'te birleştirilmeyi bekler.

Yayın betikleri sekmesi ve sürümü geri almak

Pull request'lerin geçmişini GitHub'da da görebilirsiniz, ama hangi pull request'in hangi düzeltmeleri taşıdığını oradan takip etmek zordur. Bunun için Site kodu görevleri ekranına Yayın betikleri adında yeni bir sekme ekledik.

Bu sekme GitHub pull request ve Cloudflare Worker kanallarıyla yapılan her yayını bir sürüm olarak listeler. GitHub tarafında her pull request açılışı ve her güncellemesi yeni bir sürümdür. Her satırda sürüm numarası, tarih, düzeltme sayısı, etkilenen sayfalardan örnekler ve pull request bağlantısı bulunur. Durum etiketi dörtten biridir:

• Açık PR: pull request açık, birleştirilmeyi bekliyor.
• Birleştirildi: pull request birleştirildi, düzeltmeler uygulandı sayıldı.
• Kapatıldı: pull request birleştirilmeden kapatıldı.
• Yerini yenisi aldı: aynı pull request daha sonra farklı bir düzeltme kümesiyle güncellendi; geçerli sürüm listede bunun üstündedir.

Sekmenin üstünde bu kanallar üzerinden şu an sitede kaç düzeltme bulunduğu da yazar. Projede GitHub ya da Worker kanalı bağlı değilse sekme sizi önerilen kanal ekranına yönlendirir.

Bir sürümün yanındaki Bu sürümü geri al düğmesi, o sürümdeki geri alınabilir düzeltmelerin hepsini panelin mevcut geri alma akışıyla geri alır. Ayrı bir mekanizma yoktur; tek tek geri almakla aynı kayıtlar oluşur. Geri alma sonrası GitHub kanalı bir sonraki eşitlemede bu düzeltmeler olmadan yeni bir pull request hazırlar. Siz onu birleştirip siteyi yayınladığınızda eski değerler geri gelir. Sonuçta ekranda kaç düzeltmenin geri alındığı, varsa kaçının geri alınamadığı yazar. Toplu geri alma ve onay akışının ayrıntılarını toplu onay ve geri alma yazımızda bulabilirsiniz.

Acil bir durumda GitHub'ın kendi yolu da açıktır: birleştirilmiş commit'i geri alıp siteyi yayınlamak. Ama bu yol panelin kayıtlarını güncellemez. Panelde düzeltmeler hâlâ uygulanmış görünür ve bir sonraki eşitleme onları yeniden yazmaya çalışabilir. Bu yüzden geri almayı mümkünse Yayın betikleri sekmesinden yapın. Kanalların neleri kapsadığını site bağlayıcıları sayfasında özetledik.

Sık sorulan sorular

Otopilot pull request'i kendisi birleştirir mi?

Hayır. Otopilot yalnızca dal açar, kural dosyasını günceller ve pull request oluşturur. Birleştirme her zaman sizin ya da geliştiricinizin kararıdır.

Pull request'i kapatırsam düzeltmeler kaybolur mu?

Kaybolmaz. Birleştirilmeden kapatılan bir pull request'teki düzeltmeler yeniden hazır duruma döner ve bir sonraki eşitlemede yeni bir pull request'e girer. İstemediğiniz düzeltmeyi panelden geri alın.

WordPress sitemde GitHub kanalını kullanabilir miyim?

Önerilen kanal ekranı GitHub'ı WordPress sitelerinde önermez. Kanal Next.js bağlayıcı paketinin yardımcılarına dayanır; WordPress için eklenti kanalı daha uygun yoldur.

Birleştirdim ama sitede değişiklik göremiyorum. Neden?

En sık iki neden vardır. Site yeniden yayınlanmamıştır ya da ilgili yardımcı sitede kurulu değildir. Başlık ve açıklama için generateMetadata, yönlendirme için middleware, robots.txt için rota dosyası gerekir.

PR ne sıklıkla güncellenir?

Saatlik bağlantı taramasında otomatik olarak, ayrıca kurulum kartındaki düğmeyle istediğiniz an. Kural dosyası değişmemişse depoya hiçbir şey yazılmaz.

Kaynaklar

• Google: JavaScript SEO temelleri
• Google: Yönlendirmeler ve Google Arama
• Google: Başlık bağlantıları için öneriler
• Google: Yapısal veriye giriş
• IETF RFC 9309: Robots Exclusion Protocol