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

Görünmeyen Katiller

JekCMS tabanlı sitelerde teknik SEO denetimleri hep aynı beş hatayı ortaya çıkarıyor. Düşük performans gösteren siteleri sağlıklı olanlardan ayıran şey nadiren içerik kalitesi veya backlink oluyor — 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. İndekslenmiş sayfalarınızın kayda değer bir bölümü bu kovadaysa, içeriğiniz sıralamalar için kendi kendisiyle savaşıyor demektir.

Düzeltme

// helpers.php - gercek fonksiyon output_canonical_tag()
function output_canonical_tag(?string $url = null): void {
    $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 = $url ?? ($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ğıtıldığında, "Kullanıcı tarafından seçilen canonical olmadan yinelenen" sayısı yeniden taramayla birlikte birkaç hafta içinde çöker. Sinyalleri canonical URL'lerde toplamak, etkilenen sayfaların ortalama pozisyonunu ölçülebilir biçimde iyileştirir.

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.

Açıklayıcı alt metin ikinci bir kapı açar: görsel ağırlıklı yazıların masada bıraktığı Google Görsel Arama gösterimleri.

JekCMS'deki Düzeltme

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

    // 2. Standart boyut varyantlarını oluştur
    $sizes = [
        'thumbnail' => [150, 150, true],    // kırp
        'small'     => [300, 200, true],    // kırp
        'medium'    => [600, 400, true],    // kırp
        'large'     => [1200, 800, false],  // sığdır
        'full'      => [1920, 1280, 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ürüp her img etiketine width/height ekledikten ve alt metinleri doldurduktan sonra üç şey beklersiniz: sayfa ağırlığı yarıya veya daha altına iner, CLS sıfıra yaklaşır ve görsel indeksi içeriğinizi nihayet gördüğü için Google Görsel Arama gösterimleri açılır.

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çildiğinde Google URL'leri SERP'lerde hızla yeniden tarayıp günceller — ve açıklayıcı URL'ler ham parametrelerden tutarlı biçimde daha çok tıklama alır.

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": "Yazar Adı"
  },
  "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ı

Article + FAQPage schema eklemek bir içerik sitesinin yapabileceği en yüksek kaldıraçlı değişikliklerden biridir: SSS zengin sonuçları SERP'te daha fazla alan kaplar ve bu sonuçlara sahip sayfalar olmayanlardan tutarlı biçimde daha çok tıklanır.

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ı devreye girince önbellekli sayfalarda TTFB onlarca milisaniyeye iner, toplam sayfa yükleme tipik olarak yarılanır, aynı trafikte sunucu CPU'su belirgin düşer ve site hızlandıkça Google'ın tarama temposu artar.

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

Beş sorunu bir içerik sitesinde birlikte düzelttiğinizde tipik sıralama şudur:

• 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

Bileşik etki sonraki haftalarda Search Console'da görünür: daha iyi ortalama pozisyon, ilk sayfada daha çok anahtar kelime ve yeniden büyümeye başlayan trafik. Bunu kendi verinizle ölçün.

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.