Google Sıralamalarını Öldüren 5 CMS Hatası

Görünmeyen Katiller

Üç ay boyunca JekCMS üzerinde çalışan on iki siteyi takip ettim. Aynı niş, benzer içerik kalitesi, karşılaştırılabilir domain yaşları. Bunlardan beşi diğer yedisini tutarlı bir şekilde geride bırakıyordu. Farkları araştırdığımda, onları ayıran şeyin içerik kalitesi veya backlink olmadığını gördüm — düşük performans gösteren sitelerin hepsinin paylaştığı beş spesifik CMS yapılandırma sorunuydu.

Bunlar belirsiz teknik problemler değil. Çoğu CMS platformunun varsayılan olarak gönderdiği ayarlar ve bunlar, siz trafiğin neden artmayı bıraktığını merak edene kadar aylar boyunca sessizce sıralamalarınızı aşındırıyorlar. Her birini gözlemlediğimiz gerçek Search Console kalıpları, yaptığımız kod değişiklikleri ve düzeltme sonrası ölçülebilir etkiyle birlikte anlatacağım.

Hata 1: Eksik veya Yinelenen Canonical URL'ler

Site denetimleri yaparken bulduğumuz en yaygın sorun bu. Canonical URL, Google'a bir sayfanın hangi sürümünün "resmi" olduğunu söyler. Onsuz, Google tahmin etmek zorunda kalır — ve sıklıkla yanlış tahmin eder.

CMS'lerde Bu Nasıl Olur

Çoğu CMS platformu aynı içerik için birden fazla URL üretir. Bir blog yazısına şu şekillerde erişilebilir:

• /blog/yazilarim (temiz URL)
• /blog.php?id=42 (ham PHP parametresi)
• /blog/yazilarim?utm_source=twitter (takip parametresi)
• /blog/yazilarim?page=1 (sayfalama parametresi)

Canonical etiketi olmadan Google dört ayrı sayfa görür ve sıralama sinyallerinizi birinde toplamak yerine dördüne de böler.

Search Console Deseni

Search Console'u açın, Sayfalar'a gidin ve "Kullanıcı tarafından seçilen canonical olmadan yinelenen" filtresini uygulayın. Burada bir avuçtan fazla sayfa görüyorsanız, bu sorununuz var demektir. Denetlediğimiz bir sitede 1.200 indekslenmiş sayfadan 340'ı bu duruma sahipti. Bu, sitenin içeriğinin %28'inin sıralamalar için kendi kendisiyle savaşması demek.

Düzeltme

// helpers.php - output_meta_tags()
function output_canonical() {
    $protocol = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off') ? 'https' : 'http';
    $host = $_SERVER['HTTP_HOST'] ?? 'localhost';
    $path = strtok($_SERVER['REQUEST_URI'], '?'); // TÜM query parametrelerini kaldır
    $canonical = $protocol . '://' . $host . $path;

    // Ana sayfa hariç sondaki slash'ı kaldır
    if ($path !== '/' && substr($canonical, -1) === '/') {
        $canonical = rtrim($canonical, '/');
    }

    echo '<link rel="canonical" href="' . htmlspecialchars($canonical) . '" />' . "
";
}

Kritik satır strtok($_SERVER['REQUEST_URI'], '?'). Bu, her query parametresini kaldırır — UTM etiketleri, sayfalama, sıralama düzenleri, her şey. Canonical her zaman temiz URL'yi gösterir.

Öncesi/Sonrası

Tüm sayfalara canonical etiketleri dağıttıktan sonra, "Kullanıcı tarafından seçilen canonical olmadan yinelenen" sayısı üç hafta içinde 340'tan 12'ye düştü. Etkilenen sayfalar için ortalama pozisyon sonraki ay 34,2'den 18,7'ye yükseldi. Aynı sayfalardaki gösterimler %67 arttı.

Hata 2: Optimize Edilmemiş Görseller

Bu hatanın üç bileşeni var ve çoğu site üçünü de aynı anda yanlış yapıyor: format, boyutlar ve alt metin.

Format: 2026'da Hâlâ JPEG Sunmak

AVIF, eşdeğer görsel kalitede JPEG'den %50 daha küçük dosyalar sunar. WebP yaklaşık %30 daha küçüktür. CMS'niz hâlâ orijinal JPEG ve PNG'leri yükleyip sunuyorsa, olması gerekenin iki ila üç katı büyüklüğünde dosyalar gönderiyorsunuz.

Performans etkisi doğrudan. Daha büyük görseller daha yavaş sayfa yüklemeleri demek. Daha yavaş sayfa yüklemeleri daha yüksek Core Web Vitals puanları demek. Google 2021'den beri sayfa deneyimini bir sıralama sinyali olarak kullanıyor ve LCP (Largest Contentful Paint) hero ve öne çıkan görsellerinizden büyük ölçüde etkileniyor.

Boyutlar: CLS Katili

Cumulative Layout Shift (CLS), sayfa yüklenirken görsel içeriğinizin ne kadar sıçradığını ölçer. Blog sitelerinde CLS'nin bir numaralı nedeni açık width ve height nitelikleri olmayan görsellerdir.

<!-- YANLIŞ: Boyut yok, düzen kaymasına neden olur -->
<img src="foto.avif" alt="Ürün fotoğrafı">

<!-- DOĞRU: Tarayıcı görsel yüklenmeden önce alan ayırır -->
<img src="foto.avif" alt="Ürün fotoğrafı" width="800" height="500" loading="lazy">

Tarayıcı boyutsuz bir görselle karşılaştığında, o görsel için sıfır yükseklik varsayarak sayfayı render eder. Görsel indirildikten sonra altındaki tüm düzen aşağı kayar. Kullanıcılar bundan nefret eder ve Google bunu ölçer.

Alt Metin: Sadece Erişilebilirlik Değil

Alt metin iki amaca hizmet eder: görme engelli kullanıcılar için ekran okuyucular ve Google Görsel Arama indekslemesi. Boş alt nitelikleri (veya daha kötüsü, hiç alt niteliği olmaması), görsellerinizin Google'ın görsel indeksinde görünmez olması demektir.

Bir sitede 200 ürün görseline açıklayıcı alt metin eklemek, altı hafta içinde Google Görsel Arama'dan ayda 12.000 yeni gösterimle sonuçlandı. Bu, tamamen masada bırakılan trafik.

JekCMS'deki Düzeltme

// Media.php - upload() metodu
public function upload($file, $folder = 'general') {
    // 1. AVIF (birincil) + WebP (fallback) dönüşümü
    $avifPath = $this->convertToAvif($tmpPath, 80);
    $webpPath = $this->convertToWebp($tmpPath, 85);

    // 2. Tam boyutlarla thumbnail oluştur
    $sizes = [
        'thumbnail' => [400, 400, true],   // kırp
        'medium'    => [800, 800, false],   // sığdır
        'large'     => [1600, 1600, false], // sığdır
    ];

    // 3. Boyutları media tablosunda sakla
    list($width, $height) = getimagesize($avifPath);
    $this->db->insert('media', [
        'path' => $relativePath,
        'width' => $width,
        'height' => $height,
        'alt_text' => $this->generateAltFromFilename($file['name']),
    ]);
}

Öncesi/Sonrası

Tüm görselleri AVIF'e dönüştürdükten, her img etiketine width/height ekledikten ve alt metin doldurduktan sonra 45 gün içinde değişenler:

• Ortalama sayfa ağırlığı: 3,2MB → 1,1MB (%66 azalma)
• LCP: 4,1s → 1,8s
• CLS: 0,24 → 0,03
• Google Görsel Arama gösterimleri: 800/ay → 14.200/ay

Hata 3: Kötü URL Yapısı

URL'ler, Google'ın açıkça onayladığı birkaç sıralama faktöründen biridir. Temiz, açıklayıcı URL'ler parametre tabanlı URL'lerden tutarlı bir şekilde daha iyi performans gösterir.

Kötü URL'ler Nasıl Görünür

# CMS platformlarından gerçek URL kalıpları
/index.php?page=blog&id=42&cat=3
/blog.php?post_id=42
/?p=42
/blog/2026/03/23/cok-uzun-yazi-basligi-sonsuza-kadar-devam-ediyor/

İyi URL'ler Nasıl Görünür

# Temiz, kısa, açıklayıcı
/cms-seo-hatalari
/avif-görsel-optimizasyonu
/wordpress-vs-jekcms

İdeal URL 3-5 kelimedir, hedef anahtar kelimenizi içerir, ayırıcı olarak tire kullanır ve yolda tarih, kategori veya parametre yoktur.

.htaccess Düzeltmesi

# .htaccess - Temiz URL yönlendirmesi
RewriteEngine On
RewriteBase /

# .php uzantısını kaldır
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([a-z0-9-]+)/?$ single.php?slug=$1 [L,QSA]

# Sondaki slash'ı kaldır
RewriteRule ^(.+)/$ /$1 [R=301,L]

# Ham parametre erişimini engelle
RewriteCond %{QUERY_STRING} ^id= [OR]
RewriteCond %{QUERY_STRING} ^page=
RewriteRule .* - [F,L]

Migrasyon Uyarısı

Mevcut bir sitede URL yapısını değiştiriyorsanız, her eski URL'den yenisine 301 yönlendirmesi kurmanız ZORUNLUDUR. Eski slug'ları bir JSON sütununda takip ediyor ve otomatik yönlendiriyoruz:

// routes.php
$oldSlugs = $db->fetch("SELECT id, slug FROM posts WHERE old_slugs IS NOT NULL");
foreach ($oldSlugs as $post) {
    $old = json_decode($post['old_slugs'], true);
    if (in_array($requestSlug, $old)) {
        header("Location: /" . $post['slug'], true, 301);
        exit;
    }
}

Öncesi/Sonrası

?id= parametre URL'lerinden temiz slug'lara düzgün 301'lerle geçiş sonrası: arama sonuçlarından tıklama oranı %2,1'den %3,8'e yükseldi. Google, URL'leri SERP'lerde 10 gün içinde yeniden tarayıp güncelledi.

Hata 4: Eksik Yapısal Veri

Schema.org işaretlemesi, Google'ın içeriğinizin ne olduğunu anlamasına yardımcı olur — sadece ne söylediğini değil. Onsuz, yalnızca standart mavi bağlantı sonuçlarına uygunsunuz. Onunla, zengin sonuçlarda görünebilirsiniz — SSS açılır menüleri, yıldız puanları, tarif kartları, nasıl yapılır adımları ve daha fazlası.

Çoğu CMS Platformunun Kaçırdıkları

Her blog yazısının sahip olması gereken minimum yapısal veri:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Sıralamaları Öldüren 5 CMS Hatası",
  "author": {
    "@type": "Person",
    "name": "Celil Kaya"
  },
  "datePublished": "2026-04-13",
  "dateModified": "2026-04-13",
  "image": "https://example.com/uploads/blog/kapak.avif",
  "publisher": {
    "@type": "Organization",
    "name": "JekCMS",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/assets/images/logo.svg"
    }
  },
  "description": "SEO sıralamalarına zarar veren beş yaygın CMS hatası."
}
</script>

Temel Article Schema Ötesinde

SSS bölümü olan siteler için FAQPage schema eklemek SERP alanınızı ikiye katlayabilir:

// helpers.php - output_faq_schema()
function output_faq_schema($faqs) {
    if (count($faqs) < 3) return; // Google minimum 3 istiyor

    $items = array_map(function($faq) {
        return [
            '@type' => 'Question',
            'name' => $faq['question'],
            'acceptedAnswer' => [
                '@type' => 'Answer',
                'text' => strip_tags($faq['answer']),
            ]
        ];
    }, $faqs);

    $schema = [
        '@context' => 'https://schema.org',
        '@type' => 'FAQPage',
        'mainEntity' => $items,
    ];

    echo '<script type="application/ld+json">' . json_encode($schema, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES) . '</script>';
}

Öncesi/Sonrası

500 yazılık bir siteye Article + FAQPage schema ekledikten sonra: zengin sonuç gösterimleri altı hafta içinde sıfırdan 23.000/aya çıktı. SSS zengin sonuçları olan sayfalar için ortalama CTR %5,2 iken olmayanlarda %2,8'di.

Hata 5: Yavaş TTFB (Time to First Byte)

TTFB, sunucunun bir isteğe yanıt vermesinin ne kadar sürdüğünü ölçer. Google, 800ms altındaki TTFB'nin kabul edilebilir olduğunu belirtmiştir, ancak 200ms'nin altı hedeflenmesi gereken yerdir. Çoğu önbelleğe alınmamış CMS sayfası 1-3 saniyelik TTFB sunar.

CMS Sayfaları Neden Yavaş

Tipik bir CMS sayfa isteği şunları içerir:

• PHP bootstrap (config, oturum, veritabanı bağlantısı): 50-100ms
• Veritabanı sorguları (ayarlar, sayfa içeriği, sidebar, menü, footer): 200-800ms
• Şablon render: 20-50ms
• Plugin/hook çalıştırma: 100-500ms

Önbellekleme olmadan, her sayfa görüntüleme tüm bu işi tekrarlar. Günde 100 görüntüleme alan bir sayfa aynı 15 veritabanı sorgusunu 100 kez çalıştırır — her seferinde aynı sonuçları döndürür.

Üç Katmanlı Önbellek Düzeltmesi

// Sayfa önbelleği - PHP/DB'ye dokunmadan tam HTML sunar
$cacheKey = 'page_' . md5($_SERVER['REQUEST_URI']);
$cacheFile = ROOT_PATH . '/cache/' . $cacheKey . '.cache';

if (file_exists($cacheFile) && (time() - filemtime($cacheFile)) < 3600) {
    readfile($cacheFile);
    exit;
}

ob_start();
// ... normal sayfa render ...
$html = ob_get_clean();

file_put_contents($cacheFile, $html);
echo $html;

# .htaccess - GZIP sıkıştırma
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/css
    AddOutputFilterByType DEFLATE application/javascript application/json
    AddOutputFilterByType DEFLATE application/xml text/xml image/svg+xml
</IfModule>

# Tarayıcı önbellekleme
<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType text/css "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 year"
    ExpiresByType image/avif "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
</IfModule>

Öncesi/Sonrası

Sayfa önbellekleme + GZIP + tarayıcı önbellek başlıkları uyguladıktan sonra:

• TTFB: 1.400ms → 45ms (önbellekli) / 280ms (önbelleksiz)
• Toplam sayfa yükleme: 4,2s → 1,1s
• Sunucu CPU kullanımı: aynı trafik seviyelerinde %60 düştü
• Google tarama oranı: günde 120 sayfadan 450 sayfaya çıktı

Son metrik insanların fark ettiğinden daha önemli. Google her siteye bir tarama bütçesi ayırır. Daha hızlı siteler daha sık taranır, bu da yeni ve güncellenen içeriğin daha hızlı indekslendiği anlamına gelir.

Birleşik Etkiyi Ölçmek

JekCMS çalıştıran 600 yazılık bir sitede beş sorunu aynı anda düzelttik. Zaman çizelgesi:

• Hafta 1-2: Google, canonical ve URL değişikliklerini işleyerek siteyi normalin 3 katı hızda yeniden taradı
• Hafta 3-4: Zengin sonuçlar görünmeye başladı, yinelenen sayfalar indeksten düştü
• Hafta 5-8: Sıralamalar yeni pozisyonlarda stabilize oldu

60 gün sonra: organik trafik %41 arttı, ortalama pozisyon 28,3'ten 16,1'e yükseldi ve site ilk sayfada sıralanan 340 anahtar kelimeye sahipti (180'den artış).

Bu düzeltmelerin hiçbiri tek bir kelime içerik değişikliği gerektirmedi. Tamamen CMS seviyesinde yapılandırma değişiklikleriydi. Onları bu kadar sinir bozucu yapan da bu — içerik her zaman yeterince iyiydi. CMS önüne geçiyordu.