Google uzmanları konuya! Ne önerirsiniz? Ücretli destek vb.

13 yıllık internet haber sitem var.
4 kez yazılım değiştim. PHP-PHP-PHP-WP-PHP
PHP'de keşfet açıyordu. WP geçip sonra php geçtik 1 yıldır keşfet açmıyor
Yazılım değiştirmeyi düşünüyorum ama yoruldum. Bununda çözüm olup olmayacağını bilmiyorum.
Screaming frog ile dün siteyi taradım. Hataları şu şekilde analiz ve çözüm yöntemlerini iletti.
Bu konuda uzman öneri çözüm ve hizmet veren varsa lütfen dm ve konuya mesajla fikirlerini paylaşsın.
Lütfen yapay zeka ile ben bu işi çözerim diyenler yazmasın!
Benim aklıma çözemezsem son 1 yıl hariç tüm haberleri silmek geliyor! Uzmanlar ne der bilmiyorum.
O yüzden bu konuyu açtım.
Aşağıdaki bilgilere göre bu konuyu çözecek varsa lütfen yazsın. Veya önerilerde bulunacak arkadaşlar olursa değerli yorumlarını bekliyorum.


Sitenin altyapısı WordPress'ten özel PHP bir çözüme taşındığında, yeni sistemin arama motorlarıyla olan teknik iletişimi eksik yapılandırılmış. 1 yıldır Keşfet (Discover) trafiğinizin kesik olmasının temelinde bu altyapı geçişinde oluşan yapısal sorunlar yatıyor.
Google Keşfet, normal arama sonuçlarından (SERP) çok daha hassas ve katı teknik kurallara sahiptir. Özellikle görsel kalitesi ve anında indekslenme (tarama) konusunda sıfır toleransla çalışır. Tarama raporunuzdaki veriler, PHP altyapısının Keşfet'in ana gereksinimlerini karşılayamadığını net bir şekilde gösteriyor.
İşte Keşfet'ten düşmenizin ana nedenleri ve adım adım çözüm yolları:

1. Görsel Boyutlandırma ve Teknik Etiket Hataları (Ana Neden)

Google Keşfet'te yer almanın bir numaralı kuralı yüksek kaliteli ve geniş görseller kullanmaktır (en az 1200 piksel genişlik). Rapordaki 56.092 adet "Images: Missing Size Attributes" hatası ve /cropImages/ dizinindeki 404/410 hataları, yeni yazılımın görselleri işlerken (kırparken veya ekrana basarken) teknik standartları karşılayamadığını gösteriyor.

• Nasıl Çözülür?
  • Haber detay sayfalarının kaynak koduna (head tagleri arasına) mutlaka <meta name="robots" content="max-image-preview:large"> etiketini ekleyin. Bu, Keşfet için zorunludur.
  • Yazılımcınızla görüşüp, haber kapak görsellerinin HTML çıktısında width ve height (genişlik ve yükseklik) değerlerinin otomatik olarak basılmasını sağlayın.
  • Öne çıkan görsellerinizin (featured image) en az 1200 piksel genişliğinde olduğundan emin olun ve 404 hatası veren bozuk görsel linklerini temizleyin.

2. İndeksleme ve Hatalı Canonical Yapılandırması

Keşfet akışına girebilmek için haber yayınlandığı anda Google botlarının sayfayı sorunsuz tarayıp dizine eklemesi (index) gerekir. Rapordaki 1.225 adet "Non-Indexable Canonical" ve on binlerce "noindex" hatası, PHP sisteminin Google botlarının kafasını karıştırdığını kanıtlıyor. Bot, asıl haberi bulmakta zorlandığı için Keşfet havuzuna o içeriği hiç almıyor.

• Nasıl Çözülür?
  • Haber detay sayfalarınızın (makalelerin) canonical etiketlerinin tam olarak kendi URL'sini (self-referencing) işaret ettiğinden ve bu URL'lerin aktif (200 OK) olduğundan emin olun.
  • Haber detay sayfalarınızda yanlışlıkla <meta name="robots" content="noindex"> etiketi kalıp kalmadığını kontrol edin. Haber sayfaları kesinlikle index, follow olmalıdır.

3. Karma İçerik (Mixed Content) Sorunu

Rapordaki 351 adet "Security: Mixed Content" hatası Keşfet için kritik bir engeldir. Siteniz HTTPS sertifikasına sahip olsa bile, sayfanın içindeki bir resim HTTP (güvensiz) bağlantısıyla çağrılıyorsa, Google bu sayfayı "güvenli olmayan deneyim" sayarak Keşfet akışına dahil etmez.

• Nasıl Çözülür?
  • Veritabanınızda yayınlanmış tüm haberleri taratarak [http://www.gazetekritik.com](http://...zetekritik.com) veya [http://i.haber3.com](http://i.haber3.com) şeklinde çağrılan tüm medya dosyalarını https:// protokolüyle güncelleyin.

4. Tarama Bütçesi İsrafı (0 Yanıt Kodları ve 410'lar)

Rapordaki bini aşkın "0 (Sıfır) Yanıt Kodu" ve dış bağlantılardaki 4XX hataları, Google botlarının sitenizi tararken sürekli çıkmaz sokaklara veya sunucu engellerine takıldığını gösteriyor. Google botları bir sitede çok fazla hatayla karşılaşırsa o siteye ayırdığı "Tarama Bütçesini" düşürür. Tarama sıklığı düşen bir haber sitesi, anlık güncellenen Keşfet akışında rekabet edemez.

• Nasıl Çözülür?
  • Sunucunuzun (Hosting/VDS) erişim loglarını inceleyin. Yazılım geçişinden sonra botların IP adreslerini engelleyen bir güvenlik duvarı (WAF/Cloudflare) kuralı kalmış olabilir.
  • Eski sistemden kalan ve artık 404/410 yanıtı veren ölü sayfaları ve dosyaları tespit edip, ana sayfanıza veya ilgili güncel kategorilere 301 yönlendirmesi ile bağlayın.

Özetle: Google Keşfet algoritması, altyapınızın kusursuz olmasını bekler. Yeni yazılımdaki canonical hatalarını düzeltip, sayfalarınıza max-image-preview:large etiketini ekledikten ve HTTPS hatalarını giderdikten sonra, Google Search Console üzerinden "URL Denetimi" yaparak sayfalarınızın yeniden temiz bir şekilde dizine eklenmesini tetikleyebilirsiniz. Altyapı Google'ın istediği standartlara oturduğunda Keşfet trafiğiniz kademeli olarak geri gelecektir.



İki rapor birlikte değerlendirildiğinde sitenin temel erişilebilirliği iyi; fakat indeksleme stratejisinde ciddi bir uyumsuzluk var. En önemli sonuç: 66.582 iç HTML URL’sinin yalnızca 20.524’ü indekslenebilir durumda.

Genel tablo

DurumURLOranİç HTML toplamı66.582%100İndekslenebilir HTML20.524%30,8İndekslenemeyen HTML46.058%69,2noindex bulunan HTML44.831%67,3200 yanıt veren HTML65.355%98,2İç 3xx yönlendirme152%0,2İç 4xx/4101.075%1,6Robots.txt engeli1.001%1,5Yanıt alınamayan iç URL142%0,2
Bu sonuç “sitenin çoğu bozuk” anlamına gelmiyor. İndeks dışı URL’lerin büyük bölümü etiket, arşiv ve finans sayfalarından oluşuyor. Ancak bazı önemli sayfaların da yanlışlıkla bu gruba girdiği görülüyor.

1. En kritik konu: 44.831 URL’de noindex

Dağılım şu şekilde:
URL grubuNoindex URL/haberleri/ etiket sayfaları24.123/arsiv-haberleri/ eski haberler18.074/arsiv?date= tarihli arşivler1.213/borsalar/628/kripto/301/altin/266/kose-yazilari/155Üye sayfaları40/doviz/25
Üye girişi, kayıt ve benzeri sayfaların noindex olması doğru. Fakat aşağıdaki yapılar yeniden değerlendirilmelidir.

Etiket sayfaları

24.123 etiket sayfasının tamamı indeks dışı. İnce ve otomatik oluşturulmuş etiketlerin noindex olması mantıklı; ancak Fenerbahçe, Galatasaray, Özgür Özel, altın fiyatları gibi güçlü konular için bu karar trafik kaybettirir.
Üstelik bazı noindex etiket sayfaları 40–66 bin arasında dahili bağlantı alıyor. Site, Google’a çok önemli olduğunu söylediği bu sayfaların aynı anda indekslenmemesini istiyor.
Çözüm:

• En değerli 50–200 konuyu belirleyin.
• Bu sayfalara özgün H1, title, açıklama ve editoryal giriş metni ekleyin.
• Güncel haber listesini gösterin.
• Bu seçilmiş sayfalardan noindex etiketini kaldırın.
• Diğer zayıf etiketler noindex kalabilir.
• Site genelindeki footer’dan link verilen etiket ya kaliteli ve indekslenebilir olmalı ya da footer bağlantısı kaldırılmalı.

Eski haberler

18.074 /arsiv-haberleri/ URL’si Google’a tamamen kapatılmış. Bunlar özgün, tam içerikli haberlerse uzun kuyruklu arama trafiği ve eski backlink değerleri kaybediliyor olabilir.
Toplu olarak 18 bin URL’yi açmayın. Şu şekilde ilerleyin:

1. Backlink, gösterim veya geçmiş trafik alan eski haberleri belirleyin.
2. Özgün ve güncelliğini koruyan 500 URL’lik pilot grup seçin.
3. Self-canonical kullanın ve noindex etiketini kaldırın.
4. Güncelliğini yitiren haberlerde gerekiyorsa “Bu haber … tarihinde yayımlandı” bildirimi gösterin.
5. Kopya, çok kısa veya hukuki açıdan sakıncalı içerikler noindex kalabilir.

Finans sayfaları

Toplam yaklaşık 1.220 borsa, kripto, altın ve döviz sayfası noindex. Özellikle:

• /kripto sayfası 132.113 dahili bağlantı alıyor.
• /borsalar yaklaşık 67 bin bağlantı alıyor.
• Dolar, euro ve altın sayfaları menülerden bağlantı alıyor.

Bunları indekslemek istiyorsanız her sayfaya yalnızca fiyat tablosu değil; veri kaynağı, güncelleme zamanı, hesaplama yöntemi, geçmiş grafik, açıklama ve SSS ekleyin. Sonrasında stratejik sayfalardan noindex kaldırılabilir.

2. Canonical hataları: 1.225 URL

Raporda hem “Canonicalised” hem de “Non-Indexable Canonical” sayısı 1.225. Yani canonical verilen URL’lerin tamamında hedef sayfa indekslenemiyor.
Dağılımın büyük bölümü:

• Yaklaşık 1.212 adet /arsiv?date=... sayfası
• 13 adet altın hesaplama sayfası

Tarihli arşiv sayfaları noindex ve canonical olarak yine noindex olan /arsiv sayfasını gösteriyor. Google’a gönderilen iki sinyal de kullanışsız hale geliyor.
İki geçerli seçenek var:
Arşiv sayfaları Google’da gösterilmeyecekse:

<meta name="robots" content="noindex,follow">



Canonical etiketini kaldırın. İndekslenmeyecek sayfayı başka bir indekslenemeyen sayfaya canonical vermeyin.
Arşiv sayfaları Google’da gösterilecekse:

• noindex kaldırılmalı.
• Her tarih URL’si self-canonical olmalı.
• Başlık “18 Ağustos 2026 Haber Arşivi” gibi tarih bazlı olmalı.
• Sayfalar robots.txt ile engellenmemeli.

Altın hesaplama URL’leri için indekslenebilir bir /altin/hesaplama merkezi oluşturup ince miktar kombinasyonlarını bu merkeze canonical verebilirsiniz. Hedef merkez mutlaka indekslenebilir olmalı.

3. Robots.txt, 1.001 pagination URL’sini engelliyor

Engellenen iç URL’lerin tamamı kategori pagination yapısına ait:

/magazin?page=2/ekonomi?page=93/dunya?page=10/kultur-sanat?page=5



Robots.txt içindeki şu satır kaldırılmalı:

Disallow: /*?page=



Ardından her pagination sayfası:

• 200 yanıt vermeli.
• Kendisini canonical göstermeli.
• Sonraki ve önceki sayfalara normal <a href> bağlantıları vermeli.

Örnek:

<!-- /ekonomi?page=2 sayfasında --><link rel="canonical"href="https://www.gazetekritik.com/ekonomi?page=2">



Bu değişiklik eski haberlerin dahili bağlantılar üzerinden keşfedilmesini kolaylaştırır.

4. 1.075 iç 4xx hatasının 1.072’si kayıp görsel

Yanıt kodları:

• 1.072 adet 410 Gone
• 3 adet 404 Not Found

410 URL’lerin neredeyse tamamı eski haberlerde kullanılan görseller:

/images/upload/.../images/haberici/.../haber-url/example1.jpg/haber-url/image_url



410 kodu, dosya gerçekten kalıcı olarak kaldırıldıysa teknik olarak doğru. Sorun, haberlerin hâlâ bu görsellere referans vermesi.
Çözüm sırası:

1. Değerli içeriklerin görsellerini yedekten geri yükleyin.
2. Eşdeğer ve kullanım hakkı bulunan yeni görsel varsa src adresini güncelleyin.
3. Görsel bulunamıyorsa bozuk <img> etiketini içerikten kaldırın.
4. Eksik görselleri ana sayfaya 301 yönlendirmeyin.
5. Yalnızca birebir eşdeğer yeni görsel varsa 301 kullanın.

404’lerden biri /cdn-cgi/l/email-protection ve 20 dahili bağlantı alıyor. Bu, Cloudflare e-posta gizleme özelliğinden kaynaklanıyor. İletişim/yazar e-postalarını düzgün mailto: bağlantısına çevirin veya Cloudflare Email Address Obfuscation ayarını ilgili şablonda devre dışı bırakın.

5. Yanıt alınamayan 142 iç URL

Dağılım:

• 137 connection refused
• 5 timeout

Aynı hosttaki diğer on binlerce URL düzgün çalıştığı için bunlar büyük olasılıkla yüksek tarama hızında sunucu/WAF tarafından bağlantının kesilmesinden kaynaklanıyor.
Doğrulama:

• Yalnızca bu 142 URL’yi yeniden tarayın.
• Screaming Frog hızını 1–2 URL/saniye ve 2–3 iş parçacığına düşürün.
• Timeout süresini 20–30 saniye yapın.
• Sorun ortadan kalkarsa URL hatası değil, kapasite/rate-limit sorunudur.
• Devam ederse LiteSpeed hata kayıtları, Cloudflare WAF ve bağlantı limitleri incelenmeli.

6. Sayfa yanıt süreleri

HTML sonuçları:

• Medyan: 0,455 saniye
• %95 dilim: 0,769 saniye
• 1 saniyeden yavaş: 1.650 URL
• 2 saniyeden yavaş: 354 URL
• 5 saniyeden yavaş: 41 URL
• Bazı URL’ler: 20–22 saniye

En yavaş sayfaların önemli bölümü /haberleri/ etiket sayfaları. Bu sayfalar hem noindex hem de veritabanı açısından pahalı.
Çözüm:

• Etiket haber listelerini tam sayfa önbelleğe alın.
• Tag–haber ilişki tablosunda tag_id, content_id, published_at indekslerini kontrol edin.
• Sayfa başına sonuç sayısını sınırlandırın.
• Güncel sayfa dışında eski sayfaları daha uzun süre cache’leyin.
• Yayın yapıldığında yalnızca ilgili kategori ve etiket cache’ini temizleyin.

Önceki kontrolde tespit edilen ?v=time() CSS/JS sürümleme hatası da düzeltilmeli. Rapordaki 13.362 farklı CSS URL’sinin temel nedeni bu. Her istekte değişen timestamp yerine sabit deploy sürümü veya dosya hash’i kullanılmalı.

7. Görsel performansı

Önemli sonuçlar:

• 56.092 görselde width/height yok.
• 11.051 görsel 100 KB’den büyük.
• 3.045 görselde alt niteliği hiç yok.
• 197 görselde alt boş.
• 3.523 alt metin 100 karakterden uzun.

Görsel URL’sinde ölçü zaten bulunuyor:

/cropImages/587x332/...



Bu ölçüler doğrudan HTML’ye yazılabilir:

<imgsrc="..."width="587"height="332"alt="Haberin kısa ve açıklayıcı başlığı"loading="lazy"decoding="async">



Ana haber görselinde loading="lazy" kullanmayın; bunun yerine fetchpriority="high" kullanılabilir. Diğer görsellerde WebP/AVIF, srcset ve uygun kalite seviyesi uygulanmalı.

“Bad Content Type” uyarısı neden 34.063?

34.063 uyarının tamamı .jpg uzantılı URL’lerin image/webp olarak sunulmasından kaynaklanıyor. Örnek dosyada gerçek içerik de WebP, HTTP Content-Type başlığı da image/webp.
Dolayısıyla bu 34.063 kayıt işlevsel MIME hatası değil, uzantı–format farklılığıdır. Eski görsel URL’lerini topluca değiştirmeyin. Yeni görsellerde .webp uzantısı kullanılması yeterli.

8. Başlık, açıklama ve H1 sorunları

• 18.057 başlık 60 karakterden uzun.
• 17.402 başlık 561 pikselden geniş.
• 18.570 meta açıklama 155 karakterden uzun.
• 21 sayfada title yok.
• 57 sayfada H1 yok.
• 35 sayfada canonical yok.
• 43 duplicate title var.
• 39 duplicate meta description var.

Çözüm:

• CMS’ye haber başlığından ayrı bir “SEO başlığı” alanı ekleyin.
• Editöre 45–65 karakterlik görsel sayaç gösterin.
• Meta açıklama için yaklaşık 120–155 karakter hedefleyin.
• Haber başlığı çok uzunsa - Gazete Kritik ekini title’dan kaldırın.
• Kategori, yazar ve finans şablonlarına otomatik H1, description ve self-canonical ekleyin.
• Eski uzun URL’leri sırf kısaltmak için değiştirmeyin; yeni haberlerde daha kısa slug kullanın.

9. Güvenlik başlıkları

Yaklaşık 124.783 kaynakta şu başlıklar eksik:

• HSTS
• Content-Security-Policy
• Referrer-Policy
• X-Frame-Options
• X-Content-Type-Options

Bunlar doğrudan SEO cezası değildir, ancak güvenlik açısından düzeltilmeli. Cloudflare veya sunucu seviyesinde uygulanabilir:

Strict-Transport-Security: max-age=31536000X-Content-Type-Options: nosniffReferrer-Policy: strict-origin-when-cross-originX-Frame-Options: SAMEORIGIN



Tüm alt alan adlarının HTTPS olduğundan emin olmadan HSTS’ye includeSubDomains veya preload eklemeyin. Reklam ve analiz servisleri nedeniyle CSP’yi önce Content-Security-Policy-Report-Only olarak test edin.

Uygulama önceliği

1. Pagination robots.txt ve canonical düzenlemesi.
2. noindex sayfaların stratejik sınıflandırılması.
3. 1.225 non-indexable canonical hatasının çözülmesi.
4. 1.072 bozuk görsel referansının temizlenmesi.
5. CSS/JS timestamp cache hatasının giderilmesi.
6. 351 mixed-content kaydının HTTPS’ye çevrilmesi.
7. Title, H1, meta description ve canonical şablonları.
8. Görsel boyut, sıkıştırma ve alt metin düzenlemeleri.
9. Güvenlik başlıkları.

issues_overview_report.csv yalnızca sorun adetlerini içerdiği için missing title, H1, canonical ve mixed-content hatalarının URL listesi bu iki dosyada bulunmuyor. Bunların kesin URL bazlı çözümü için Screaming Frog’dan Issues → Export, Canonicals → Non-Indexable Canonicals ve Bulk Export → Security → Mixed Content çıktıları gerekir.

Pek kimsenin ilgisini mi çekmedi yoksa çözümsüz bir konu mu?

Konu çözümsüz değil de analiz ve sorunlar elinizde zaten. Konu Google Uzman konusu değil. Koder bulmanız lazım.

önereceğiniz forumdan biri var mı? Hatalar hepsi search console üzerinde olduğu için ve news ile alakalı olduğu için buradan açtım.

En son herhalde habersofttaydı senin site. Ama ondan öncede de sıkıntı vardı. Basın İlan şartları yoksa hepsini sil. Baktığımda AI ile çok kalitesiz içerikler giriliyordu. Bu en büyük keşfeti kapatmanın yolu. Teknik sorunlar tabii ki etken ama haber tarafında ilk bakılan taraf içerik. İçerik kaldır, haberciliğe uygun içerik ile tekrar dene. Biraz otorite, sosyal medya hiti ile tekrar dene.

aynen habersoft kullanıyorum şuan
Gazisoftta 23 milyon aylık hit vardı.
Peki son 1 yıl hariç diğer haberleri silersek ne gibi olumsuzluklar olur? Ne gibi düzelmeler bekleyebiliriz? Bu konuda bilginiz varsa sevinirim

3-4 projede aynısını yaptık. Search COnsole ve Analytics tarafında son 3 ayda hiç hit almayan bütün konuları kaldırdık. Onların yerine Evergreen içerikler girerek sitenin yazı otoritesini arttırdık. Haber tarafında da dümdüz rewrite yerine alakalı haberleri geçmişinde geçiren farklı bir sisteme geçtik hitler şu an düzenli olarak artıyor.

O toplara hiç girme. 404 alırsın işin içinden çıkamazsın.

Yukarıda arkadaşın belirttiği gibi sorunların tamamı zaten elinin altında. Yapmanız gereken sağlam bir coder bulmak. Ya da yeni bir yazılımla yola devam etmek.

Bir PM atıyorum inceleyin.

Şunu anlayamadım. Hit almayan haberleri silersek iyileşir mi kötüleşir mi? Sizin dediğinize göre olumlu ama bazı arkadaşlar dm'den hiç o işe girme yazmış.
Siz ne önerirsiniz? Benim duruma biraz aşinasınız