Teknik SEO Nedir? Teknik SEO Danışmanlığı Rehberi

Teknik SEO nedir ve teknik SEO danışmanlığı neyi kapsar?

Teknik SEO, bir web sitesinin arama sistemleri tarafından keşfedilme, taranma, oluşturulma ve dizine alınma koşullarını iyileştiren çalışmalardır. Kapsam; sunucu yanıtlarından URL üretimine, iç bağlantılardan mobil sunuma kadar uzanır. Amaç, arama motoruna özel bir site kurmak değil, kullanıcıya açık değerli sayfaların teknik engeller yüzünden görünmez kalmasını önlemektir.

Google, arama sürecini genel olarak tarama, dizine ekleme ve sonuç sunma aşamalarıyla açıklar. Bir URL'nin bulunması, mutlaka taranacağı; taranması da mutlaka dizine alınacağı anlamına gelmez. Bu ayrım önemlidir, çünkü “Google sayfayı görmüyor” şikâyeti bağlantı keşfinden içerik kalitesine kadar farklı nedenlere dayanabilir. Google Arama'nın çalışma açıklaması bu aşamaların çerçevesini verir.

Teknik çalışma, içerik stratejisinin yerine geçmez. Boş bir kategori sayfasının hızlı açılması onu yararlı yapmaz; güçlü bir rehberin yanlışlıkla noindex olması ise içeriğin değerlendirilmesini engelleyebilir. Bu nedenle teknik ekip, içerik ve ürün sahipleriyle aynı URL envanteri üzerinde çalışmalıdır. Sorun yalnız koda, başarı da yalnız kelime sıralamasına indirgenmemelidir.

Bir SEO danışmanlığı kapsamı; denetim, çözüm tasarımı, geliştirme görevleri, yayın öncesi kontrol ve yayın sonrası doğrulama içerebilir. Her işletmenin ihtiyacı aynı değildir. On sayfalık kurumsal sitede fasetli gezinme analizi gereksiz olabilir; geniş ürün kataloğunda ise parametre yönetimi ve şablon bazlı inceleme çalışmanın merkezine yerleşebilir.

Teknik SEO hizmeti satın alırken teslimin “kırık bağlantıları bulma” düzeyinde kalıp kalmadığını sorun. Tarayıcı aracı binlerce satır üretebilir, fakat hangi satırın gelir üreten sayfa grubunu etkilediğini kendi başına bilemez. Danışmanın görevi veriyi bağlama oturtmak, olası nedeni sınamak ve yazılım ekibinin uygulayabileceği kabul ölçütleri oluşturmaktır.

Başarı, bütün uyarıların sıfırlanması değildir. Bazı URL'lerin dizinde olmaması bilinçli bir ürün kararı olabilir; bazı yönlendirmeler kullanıcı yolculuğunun doğal parçasıdır. Sağlıklı hedef, istenen sayfaların tutarlı biçimde erişilebilir olması ve değişikliklerin yeni risk üretmeden yönetilmesidir.

Teknik SEO analizi hangi bilgilerle başlamalıdır?

Teknik SEO analizi, sitenin ticari sayfalarını ve yayın düzenini anlamakla başlamalıdır. Önce organik aramadan bulunması beklenen ürün, hizmet, kategori, lokasyon ve bilgi sayfalarını listeleyin. Denetçi bu hedefi bilmezse, test ortamını engelleyen kural ile canlı ürün grubunu kapatan kuralı aynı önemde raporlayabilir.

Alan adının bütün sürümlerini kaydedin: HTTP, HTTPS, www, www olmayan yapı, alt alan adları ve varsa ayrı mobil adresler. Bunların hangi nihai sürüme yönlendiğini gerçek isteklerle kontrol edin. Sadece tarayıcının adres çubuğuna bakmak yeterli değildir; yönlendirme zinciri, durum kodu ve canonical hedefi birlikte incelenmelidir.

Search Console mülkleri, analitik hesapları, içerik yönetim sistemi ve sunucu kayıtlarına erişim kapsamını belirleyin. Erişim verilmeyen alanı raporda açıkça işaretleyin. Log görülmeden bot davranışı, şablon kodu görülmeden oluşturma nedeni veya yayın geçmişi bilinmeden ani düşüş hakkında kesin konuşmak doğru olmaz.

Yakın dönemdeki alan adı taşıması, tasarım değişimi, kategori birleşimi, altyapı geçişi ve robots düzenlemelerini zaman çizelgesine ekleyin. Trafik grafiğindeki tarih ile sürüm kaydı arasındaki yakınlık tek başına neden kanıtı değildir; araştırılacak URL kümesini daraltır. Aynı tarihte sezon, stok veya talep değişmiş olabileceğini de not edin.

Tarama aracı ayarlarını sitenin yapısına göre belirleyin. Yalnız HTML bağlantılarını izleyen bir tarama, JavaScript ile eklenen yolları kaçırabilir. Buna karşılık sınırsız parametre takibi, gerçek kullanıcının ulaşmadığı milyonlarca birleşim üretebilir. Kullanıcı aracısı, oluşturma modu, hız sınırı ve dahil edilen alt alan adları raporla birlikte saklanmalıdır.

Başlangıç kaydı oluştururken örnek URL değil, şablon ailesi düşünün. Bir ürün sayfasındaki hata on bin üründe ortaksa etkisi büyüktür; tek bir eski kampanya adresindeki benzer hata aynı önceliği taşımayabilir. URL sayısı, organik talep, dönüşüm rolü ve geliştirme bağımlılığı sonraki kararların ortak girdisi olur.

Tarama ile dizine ekleme arasındaki fark nasıl teşhis edilir?

Tarama, botun bir URL'ye istekte bulunup yanıtı almasıdır; dizine ekleme ise alınan içeriğin değerlendirilerek arama dizininde temsil edilmesidir. Bu nedenle sunucu logunda Googlebot isteği görmek, sayfanın arama sonuçlarına uygun bulunduğunu göstermez. Aynı şekilde dizinde görünen eski bir URL, yakın zamanda yeniden taranmış olmayabilir.

Teşhise URL'nin nasıl keşfedildiğini sorarak başlayın. Sayfa gezinme içinde bağlı mı, yalnız XML site haritasında mı, başka bir alan adından mı işaret ediliyor? Yetim sayfa olarak adlandırılan, geçerli iç bağlantısı bulunmayan adresler site haritasıyla keşfedilebilse de kullanıcı ve bot için bağlamsal yol sunmaz.

Ardından HTTP yanıtını ve alınan HTML'i kontrol edin. Başarılı görünen bir 200 yanıtı, aslında “ürün bulunamadı” metni taşıyan soft 404 olabilir. Kalıcı kaldırılmış içeriğin 200 döndürülmesi, tarayıcı aracının yalnız durum koduna bakan raporunu yanıltır. Yanıtın anlamı sayfadaki görünür durumla uyuşmalıdır.

Dizine alınmayan sayfada önce teknik engelleri arayın: noindex talimatı, erişim hatası, kimlik doğrulama, canonical seçimi veya içeriğin oluşturulamaması. Ardından sayfanın benzersiz ve yararlı bir amaç taşıyıp taşımadığını değerlendirin. Teknik erişim kusursuz olsa bile arama sistemi her taranan URL'yi dizine almak zorunda değildir.

Tek bir URL denetimi ile site genelindeki örüntüyü karıştırmayın. Search Console URL incelemesi belirli adres için yararlıdır; kategori ailesinin tamamını anlamak için dışa aktarımlar, site haritaları ve tarama verisi gerekir. Örneklem seçerken başarılı, başarısız ve sınırda görünen sayfalardan kayıt alın.

Sonuç cümlesi “indeks sorunu var” olmamalıdır. Daha kullanışlı ifade; etkilenen şablonu, gözlenen durumu, olası nedeni ve doğrulama yöntemini belirtir. Örneğin, filtre URL'lerinin navigasyondan sınırsız üretildiği ve ürün sayfalarına ayrılan tarama ilgisini dağıttığı hipotezi, log örneği ve bağlantı grafiğiyle sınanabilir.

Robots.txt, noindex ve XML site haritası birlikte nasıl kullanılmalıdır?

Robots.txt, belirli tarayıcılara hangi yolların taranmaması gerektiğini bildiren bir erişim kuralıdır; bir URL'yi dizinden kaldırma aracı değildir. Google, robots.txt ile engellenmiş adresin başka yerlerden gelen sinyaller nedeniyle URL olarak görünebileceğini açıklar. Dizinden çıkarma hedefi varsa botun noindex talimatını görebilmesi gerekir. Robots.txt belgesi bu sınırı açıklar.

Noindex, desteklenen meta robots etiketi veya HTTP başlığıyla sayfanın arama dizininde gösterilmemesi talebidir. URL aynı anda robots.txt ile engellenirse bot etiketi okuyamayabilir. Bu çelişki, “hem engelledik hem noindex verdik” yaklaşımının neden beklenen sonucu üretmediğini açıklar.

XML site haritası, dizine alınmasını istediğiniz tercih edilen URL'leri bildirmek için kullanılır; dizine ekleme garantisi vermez. Yönlendiren, hata döndüren, noindex taşıyan veya başka URL'yi canonical gösteren adresleri site haritasına koymak çelişkili sinyal üretir. Haritayı bütün keşfedilen URL'lerin dökümü değil, seçilmiş yayın envanteri olarak yönetin.

Google site haritalarını özellikle büyük, yeni, bağlantısı zayıf veya zengin medya içeren sitelerde yararlı bulur; küçük ve bağlantıları düzenli bir site haritasız da keşfedilebilir. Site haritası kılavuzu, dosyanın bir ipucu olduğunu vurgular. Bu nedenle teslim raporu yalnız “sitemap var” dememeli, içeriğinin diğer talimatlarla uyumunu göstermelidir.

Site haritasını içerik türüne veya yayın sorumlusuna göre bölmek hata takibini kolaylaştırabilir. Ürün ve blog adreslerini ayrı izlemek, düşüşün hangi grupta yoğunlaştığını gösterir. Bölme kararı yalnız dosya sınırına ulaşınca verilmez; operasyon ekibinin sorunu ayırabilmesi de değerli bir gerekçedir.

Yayın sürecine otomatik kontroller ekleyin. Yeni adres site haritasına giriyor mu, kaldırılan sayfa çıkıyor mu, yanlış ortam alan adı sızıyor mu? Dosyayı elle ayda bir düzenlemek, hızlı değişen katalogda kalıcı çözüm değildir. Kaynağın içerik yönetim sistemindeki yayın durumuyla bağlantılı olması hata olasılığını azaltır.

Canonical, yönlendirme ve durum kodu kararları nasıl ayrılır?

Canonical etiketi, benzer veya yinelenen URL'ler arasında arama sonuçlarında tercih ettiğiniz temsilciyi bildiren güçlü bir sinyaldir; zorunlu bir komut değildir. Google, yönlendirme ve site haritası gibi başka sinyalleri de değerlendirir. Bu yüzden canonical hedefi ile iç bağlantılar ve site haritası aynı tercihi desteklemelidir.

Bir adres kullanıcılar için artık kullanılmıyorsa ve eşdeğer yeni konum varsa kalıcı yönlendirme çoğu durumda daha açık çözümdür. Eski sayfanın kullanıcıya açık kalması gerekiyorsa canonical düşünülebilir. “Her kopyayı ana sayfaya yönlendirme” yaklaşımı, alakalı karşılık sunmadığı için hem kullanıcıyı hem hata teşhisini zorlaştırır.

Kendine referans veren canonical, sayfanın tercih edilen adresini açık hale getirir. Ancak şablon hatası bütün ürünlerin aynı kategoriye işaret etmesine yol açarsa değerli sayfalar yanlış kümede birleşebilir. Denetimde yalnız etiketin varlığına değil, hedefin 200 yanıtına, dizine uygunluğuna ve içerik eşdeğerliğine bakın.

Parametreler her zaman kopya değildir. Renk veya sıralama parametresi aynı ürün kümesini farklı biçimde sunabilir; konum parametresi ise ayrı hizmet ve içerik sağlıyorsa özgün amaç taşıyabilir. Canonical kararı URL biçimine bakılarak otomatik verilmemeli, sayfanın kullanıcıya sunduğu ana değer değerlendirilmelidir.

HTTP'den HTTPS'e, büyük harften küçük harfe veya sondaki eğik çizgi kuralına geçişte tek bir standart seçin. İç bağlantıları doğrudan nihai adrese verin. Her istek birkaç ara adım dolaşıyorsa kullanıcı gecikme yaşar, loglar karmaşıklaşır ve taşıma kontrollerinde gerçek hedefi izlemek zorlaşır.

Google'ın yinelenen URL birleştirme belgesi, yönlendirme ile rel=canonical sinyalini ve site haritasının daha zayıf desteğini açıklar. Uygulama sonrasında seçilen canonical raporlarını örnekleyin; Google'ın seçimi farklıysa içerik, bağlantı ve teknik sinyallerdeki çelişkiyi araştırın.

Site mimarisi ve iç bağlantılar taranabilirliği nasıl etkiler?

Site mimarisi, önemli sayfaların gezinme, kategori ve içerik ilişkileri içinde bulunabilir olmasını sağlar. Düz bir yapı uğruna her sayfayı ana menüye eklemek gerekmez. Ama kullanıcı belirli bir hizmete yalnız site içi arama kutusuyla ulaşabiliyorsa, botun izleyebileceği kalıcı bağlantı yolu eksik kalabilir.

Bağlantının gerçek bir HTML bağlantısı olması önemlidir. Tıklama olayıyla çalışan fakat href hedefi bulunmayan öğe, kullanıcı arayüzünde bağlantı gibi görünse de tarayıcı tarafından aynı şekilde keşfedilmeyebilir. Menü, sayfalama ve “daha fazla yükle” bileşenlerini JavaScript kapalı veya hatalı olduğunda da temel URL yollarını sunacak biçimde tasarlayın.

İç bağlantı metni, hedef sayfanın ne sunduğunu anlaşılır biçimde ifade etmelidir. Her yerde “buraya tıklayın” kullanmak hem erişilebilirliği hem bağlamı zayıflatır. Bununla birlikte tam eşleşen anahtar kelimeyi yapay biçimde yüzlerce şablon satırına yerleştirmek de iyi bir bilgi mimarisi değildir.

Breadcrumb, kullanıcının hiyerarşideki konumunu görmesine ve üst gruplara dönmesine yardım eder. Görünür breadcrumb ile yapılandırılmış verideki yol birbiriyle uyumlu olmalıdır. Bir ürün farklı kategorilerde bulunabiliyorsa işletmenin ana gezinme mantığını seçin; URL'yi her kullanıcı filtresine göre yeniden üretmeyin.

Sayfalama adresleri, listede aşağıda kalan ürün veya yazılara erişilebilir bağlantılar sağlamalıdır. Sonsuz kaydırma yalnız kullanıcı hareketine bağlıysa bot bütün öğeleri göremeyebilir. Her parça benzersiz, kalıcı bir URL ile açılabilmeli; sonraki bölüme standart bağlantı üzerinden geçilebilmelidir.

Yetim sayfaları yalnız tarama aracıyla bulamazsınız, çünkü araç başlangıç bağlantısından erişemediği URL'yi tanımaz. XML site haritası, analitik açılış sayfaları, Search Console ve sunucu loglarını tarama listesiyle karşılaştırın. Sonra her adres için bağlantı ekleme, birleştirme, yönlendirme veya kaldırma kararı verin.

JavaScript SEO denetiminde hangi farklar kontrol edilmelidir?

JavaScript SEO denetimi, sunucudan gelen ilk HTML ile betikler çalıştıktan sonra oluşan DOM arasındaki farkı inceler. Ana içerik, başlık, canonical veya iç bağlantılar yalnız istemci tarafında ekleniyorsa oluşturma hatası görünürlüğü etkileyebilir. Sorun “JavaScript kötüdür” değil, temel bilginin güvenilir biçimde sunulup sunulmadığıdır.

Google JavaScript'i işleyebilir, fakat tarama ve oluşturma kaynak ister; ayrıca engellenmiş dosya, çalışma zamanı hatası veya uyumsuz özellik sonucu değiştirebilir. JavaScript SEO temelleri, benzersiz başlık ve açıklama, HTTP durumları, bağlantılar ve oluşturulan içerik için uygulama önerileri sunar.

CSR, SSR ve statik üretim etiketlerini tek başına kalite göstergesi saymayın. Sunucu tarafında oluşturulan sayfa yanlış canonical verebilir; istemci tarafı uygulama doğru ön oluşturmayla erişilebilir içerik sunabilir. Mimari seçimi geliştirme ekibinin bakım kapasitesi, kişiselleştirme ihtiyacı ve yayın sıklığıyla birlikte değerlendirilmelidir.

Testte kaynak HTML'i, tarayıcı DOM'unu ve arama motoru inceleme çıktısını yan yana koyun. İçerik üçünde de var mı, bağlantı hedefleri aynı mı, başlık betik sonrasında değişiyor mu? Kişisel oturum, çerez veya konum nedeniyle oluşan farkları genel tarayıcı davranışı sanmamak için temiz oturum kullanın.

SPA rotalarında her görünümün paylaşılabilir ve doğrudan açılabilir URL'si olmalıdır. Sunucu bilinmeyen her yola 200 ve aynı uygulama kabuğunu döndürüyorsa gerçek olmayan adresler soft 404 üretebilir. Hata rotaları anlamlı durum kodu vermeli, içerik yüklenemezse sonsuz yükleniyor ekranında kalmamalıdır.

Dinamik oluşturma, kullanıcı ve bot için farklı çıktı yönetme maliyeti taşır ve kalıcı çözüm gibi ele alınmamalıdır. Asıl hedef, önemli içeriğin ve bağlantıların tutarlı sunulmasıdır. Teknik görev yazarken “SSR'ye geç” demek yerine hangi şablondaki hangi bilginin ilk yanıtta veya oluşturulmuş HTML'de bulunması gerektiğini belirtin.

Core Web Vitals değerleri teknik SEO kararına nasıl çevrilir?

Core Web Vitals, gerçek kullanıcı deneyiminin yükleme, etkileşim ve görsel kararlılık yönlerini LCP, INP ve CLS ile değerlendirir. Google'ın belgelediği iyi eşikler 75. yüzdelik dilimde LCP için 2,5 saniye veya daha az, INP için 200 milisaniye veya daha az, CLS için 0,1 veya daha azdır. Core Web Vitals belgesi güncel metrikleri açıklar.

Bu eşikleri laboratuvar puanıyla karıştırmayın. PageSpeed Insights içindeki alan verisi, uygun veri olduğunda gerçek Chrome kullanıcılarından gelir; laboratuvar testi ise belirli cihaz ve ağ varsayımıyla teşhis sağlar. İkisinin farklı çıkması hata değildir. Alan verisi sonucu, laboratuvar izi olası nedeni araştırmaya yardım eder.

LCP sorununda önce gerçek LCP öğesini bulun. Büyük hero görseli, metin bloğu veya poster olabilir. Sunucu yanıtı, kaynak keşif gecikmesi, dosya boyutu ve oluşturmayı engelleyen stiller toplam süreye katkı verebilir. Bütün görselleri sıkıştırmak yararlı olsa da sorun yazı tipi veya geç başlayan API isteğiyse tek başına çözmez.

INP, sayfanın ömrü boyunca kullanıcı etkileşimlerine verdiği yanıtı temsil eder. Uzun ana iş parçacığı görevleri, ağır üçüncü taraf betikleri ve gereksiz yeniden oluşturma gecikmeye neden olabilir. Yalnız ilk açılışı ölçen bir rapor, menü veya filtre tıklamasındaki yavaşlığı yakalamaz. Gerçek etkileşim yolunu profil çıkararak inceleyin.

CLS sorunları çoğunlukla boyutu ayrılmamış medya, sonradan eklenen bileşen veya font değişiminden doğar. Görsele width ve height eklemek alan oranını korumaya yardım eder; ancak beklenmedik reklam veya bildirim için de yer ayrılmalıdır. Kaymanın hangi öğeden kaynaklandığını film şeridi ve performans kaydıyla doğrulayın.

Performansı tek seferlik proje yapmayın. Şablon bütçeleri, görsel işleme kuralları ve üçüncü taraf betik onayı yayın sürecine bağlanmazsa sonraki kampanya eski sorunu geri getirir. Ölçüm, sayfa türüne ve cihaz grubuna ayrılmalıdır; site ortalaması kritik ürün şablonundaki bozulmayı saklayabilir.

Hız iyileştirmesini sıralama garantisi olarak sunmak doğru değildir. Core Web Vitals arama sistemlerinin kullandığı sayfa deneyimi unsurları arasındadır; alakalı ve yararlı içerik gereksiniminin yerini almaz. Önceliği yalnız SEO puanına göre değil, kullanıcıların görevi tamamlamasını engelleyen gecikmeye göre de belirleyin.

Mobil içerik ve yapılandırılmış veri nasıl doğrulanmalıdır?

Google, dizine ekleme ve sıralama için sitenin mobil sürümündeki içeriği kullanır. Mobil görünümde ana metin, bağlantılar veya görsel alt metinleri kaldırılıyorsa masaüstündeki zengin sürüm bu eksikliği telafi etmeyebilir. Responsive tasarım yönetimi kolaylaştırır, fakat yanlış CSS veya koşullu yükleme yine içerik farkı yaratabilir.

Mobil test, ekranın daraltılmış görüntüsünden ibaret değildir. Googlebot Smartphone erişimi, kaynak dosyaları, açılır içerikler, dokunma hedefleri ve yükleme davranışı incelenmelidir. Kullanıcı etkileşimiyle açılan açıklamalar erişilebilir olabilir; içerik ancak yeni ağ isteği ve oturum koşuluyla geliyorsa risk farklıdır.

Yapılandırılmış veri, görünür içeriğin makine tarafından anlaşılabilen ifadesidir. Sayfada bulunmayan fiyatı, yorumu veya SSS'yi yalnız JSON-LD içinde eklemek uygun değildir. İşaretleme doğru olsa bile zengin sonuç gösterimi garanti edilmez. Google yapılandırılmış veri girişi uygunluk ve kalite ilkelerini açıklar.

Şema türünü sayfanın gerçek amacıyla eşleştirin. Blog yazısında Article, ürün ayrıntısında uygun Product özellikleri düşünülebilir; her sayfaya olabildiğince çok tür eklemek hedef değildir. Zorunlu ve önerilen özellikleri resmi özellik belgesinden izleyin, çünkü arama görünümü gereksinimleri zamanla değişebilir.

Yapılandırılmış veriyi şablondan üretirken kaynak alanları belgeleyin. Ürün stokta değilken şema “InStock” kalıyorsa teknik doğrulama testi kodu geçerli bulabilir ama bilgi yanlıştır. Görünür metin, veri katmanı ve JSON-LD aynı kaynaktan beslendiğinde bu tutarsızlık azalır.

Yayın öncesinde sözdizimini, yayın sonrasında canlı URL'yi test edin. Ardından Search Console geliştirme raporlarını izleyin. Uyarı ile hatayı ayırın; önerilen alanın eksikliği her zaman uygunluğu bozmaz. Görevi, kullanıcıya gerçekten sunulabilen veri ve hedeflenen arama görünümü üzerinden önceliklendirin.

Hreflang ve çok dilli URL yapısı hangi hataları önlemelidir?

Hreflang, aynı veya benzer içeriğin dil ve bölge alternatiflerini arama sistemine bildirir. Etiket sayfayı çevirmediği gibi sıralama garantisi de vermez. Her dil sürümünün kullanıcıya gerçekten o dilde içerik sunması, erişilebilir olması ve uygun canonical düzenine sahip bulunması gerekir.

Alternatif ilişkiler karşılıklı kurulmalıdır. Türkçe sayfa Almanca eşini gösteriyor, Almanca sayfa Türkçeye dönmüyorsa küme eksik kalır. Her sayfa kendisini de alternatif listesinde belirtmeli; dil kodları desteklenen biçimde yazılmalıdır. Yerelleştirilmiş sürümler belgesi uygulama seçeneklerini açıklar.

Canonical ile hreflang farklı görevler yapar. Türkçe içeriğin canonical adresini Almanca sürüme vermek, dil alternatifini güçlendirmek yerine Türkçe URL'nin tercih edilmemesine yol açabilir. Genel yaklaşım, her dil sayfasının kendi dilindeki tercih edilen URL'yi canonical göstermesi ve eşdeğerleri hreflang ile bağlamasıdır.

x-default, belirli dil veya bölge eşleşmediğinde genel seçeneği gösterebilir. Otomatik IP yönlendirmeleri ise botların veya seyahat eden kullanıcının alternatif sürüme erişimini zorlaştırabilir. Kullanıcıya dil değiştirme bağlantısı sunun ve her sürümün doğrudan URL ile açılmasına izin verin.

Çok dilli projede teknik görev içerik operasyonundan ayrı yürütülemez. Çeviri yayından kaldırıldığında karşılıklı etiketler, site haritası ve yönlendirmeler güncellenmelidir. Yabancı pazara açılan işletmeler, teknik dil eşlemesini içerik ve pazar planıyla birlikte ele alan yabancı dil SEO yaklaşımını değerlendirebilir.

Tarama bütçesi ve log analizi ne zaman gerçekten gereklidir?

Tarama bütçesi, Googlebot'un siteyi taramak için ayırdığı kapasite ile tarama talebinin birleşimi olarak ele alınır. Her site için ilk sorun değildir. Google, özellikle çok büyük, hızla değişen veya dizine alınmayan URL oranı yüksek sitelerin ayrı yönetim rehberinden yararlanabileceğini belirtir. Tarama bütçesi belgesi kapsamı sınırlar.

Küçük bir kurumsal sitede yeni sayfa bulunmuyorsa önce iç bağlantı, site haritası, erişim ve içerik durumunu kontrol edin. “Tarama bütçesi bitti” açıklaması kanıtsız kalabilir. Buna karşılık milyonlarca filtre birleşimi üreten katalogda bot isteklerinin dağılımını görmek, sorunun ölçeğini anlamak için değerlidir.

Sunucu erişim logları; istenen URL, zaman, yanıt kodu, kullanıcı aracısı ve aktarım gibi kayıtlar sağlar. Log, sayfanın dizine alınma nedenini doğrudan söylemez. Ayrıca user-agent metni taklit edilebilir; güvenlik veya kesin bot doğrulaması gerektiğinde yalnız isim alanına güvenilmemelidir.

Analizde bot isteklerini URL şablonlarına ayırın. Önemli ürünler ne sıklıkla görülüyor, filtre adresleri toplam isteğin ne kadarını alıyor, 5xx veya uzun yönlendirme yolları hangi grupta yoğunlaşıyor? Ham satır sayısı yerine işlevsel gruplar, yazılım ekibine uygulanabilir sonuç üretir.

Tarama sıklığını yapay biçimde yükseltmek hedef olmamalıdır. Değişmeyen, düşük değerli adreslerin sık taranması başarı sayılmaz. Önemli güncellemelerin keşfedilmesi, sunucunun kararlı yanıt vermesi ve gereksiz URL alanının kontrol altında tutulması daha anlamlı kabul ölçütleridir.

Log saklama süresi ve kişisel veri yönetişimi işletmenin güvenlik politikasıyla uyumlu olmalıdır. Danışmana bütün üretim loglarını sınırsız vermek yerine gerekli alanları, dönemi ve erişim yöntemini belirleyin. Analiz bitince erişimin kaldırılması ve türetilen dosyaların nasıl saklanacağı sözleşmede açık olabilir.

Site taşıması ve HTTPS geçişi nasıl güvenli yürütülür?

Site taşıması, URL, alan adı, altyapı veya tasarım değişikliklerinin arama görünürlüğünü etkileyebildiği planlı bir süreçtir. En güvenli yaklaşım; mevcut URL envanterini çıkarmak, yeni karşılıkları belirlemek, yönlendirme haritasını test etmek ve değişimden sonra aynı kontrolleri tekrarlamaktır. Taşıma günü ilk kez eski adres aramak geç kalmış bir kontroldür.

Her eski URL'yi ana sayfaya göndermek yerine en yakın eşdeğer içeriğe yönlendirin. Karşılığı olmayan adres için dürüst bir kaldırma yanıtı daha anlamlı olabilir. Yönlendirme haritasında hedeflerin kendi içinde başka adrese gitmediğini ve döngü oluşmadığını otomatik testle doğrulayın.

HTTPS geçişinde iç bağlantılar, canonical, hreflang, site haritası ve medya adresleri güvenli sürüme çevrilmelidir. Karma içerik kullanıcı tarayıcısında güvenlik sorunları doğurabilir. Sertifikanın kapsadığı alan adları, yenileme süreci ve HTTP'den tek adımda yönlendirme ayrıca kontrol edilir.

Test ortamının arama motorlarına kapatılması gerekir, fakat canlıya çıkarken engelin taşınmaması da aynı derecede önemlidir. Yayın kontrol listesinde robots, noindex, canonical alan adı ve kimlik doğrulama bulunmalıdır. Otomatik kabul testi, insanın yoğun yayın anında gözden kaçırdığı çevre ayarlarını yakalayabilir.

Değişim sonrasında yalnız toplam organik trafiğe bakmayın. Eski ve yeni URL durumları, dizin kapsamı, önemli sorgu grupları, dönüşüm yolları ve sunucu hataları izlenmelidir. Sezon etkisini not edin. Dalgalanma ihtimali vardır, fakat “taşımada düşüş normaldir” diyerek hatalı yönlendirmeyi beklemeye bırakmayın.

Teknik SEO çalışmasının etkisi hangi ölçülerle izlenmelidir?

Teknik SEO çalışması, tek bir “site sağlık puanı” ile yönetilmemelidir. Araç puanı kendi kural setindeki uyarıları özetler; işletmenin önemli sayfalarını veya organik talebini doğrudan ölçmez. Takip sistemi kapsama, erişim, deneyim ve iş sonucunu ayrı katmanlarda göstermelidir.

Kapsama ölçüsü, hedeflenen URL grubunda dizine uygun ve tercih edilen sayfaların durumunu izler. Payda her zaman tanımlı olmalıdır. Bütün taranan URL'leri kullanmak, parametre çöplüğünün raporu yönetmesine neden olabilir. Onaylı ürün ve kategori envanteri daha anlamlı bir başlangıç kümesidir.

Erişim ölçüsü, önemli şablonlarda başarılı yanıt, istenmeyen yönlendirme ve sunucu hatası dağılımını gösterir. Ortalama yanıt süresi tek başına uç hataları saklayabilir. Zaman serisini sürüm tarihleriyle birleştirin ve bot ile kullanıcı isteklerini bağlama göre ayırın.

İş sonucu katmanında teknik değişimle ilgili açılış sayfalarının organik ziyaret, nitelikli başvuru veya gelir eğilimi incelenebilir. Ancak aynı dönemde içerik, fiyat ve talep değişebileceği için nedensellik dikkatle yorumlanmalıdır. Teknik düzeltmenin doğrudan belirli bir gelir artışı sağlayacağını peşinen vaat etmeyin.

Ölçüm notunda veri kaynağı, tarih aralığı, filtreler ve bilinen kırılmalar yazmalıdır. Search Console verisi ile analitik oturumu aynı tanıma sahip değildir. İki panelde sayıların farklı olması, otomatik olarak kurulum hatası anlamına gelmez; önce kapsam ve işleme farkını açıklayın.

Teknik SEO görevleri hangi sırayla önceliklendirilmelidir?

Öncelik, hata adedinden değil etkilenen değerli URL'lerden başlamalıdır. Ana hizmet sayfalarını noindex yapan şablon hatası az satırda görünse bile kritiktir. Binlerce eski etiket sayfasındaki önemsiz başlık uyarısı ise büyük hacimli görünmesine rağmen daha düşük iş etkisi taşıyabilir.

Her bulgu için etki, kanıt güveni, uygulama çabası ve bağımlılıkları kaydedin. Etki “yüksek” yazmakla açıklanmış olmaz; hangi sayfa grubunun hangi arama veya kullanıcı yolunda engellendiğini belirtin. Kanıt zayıfsa önce küçük test veya ek veri görevi açın.

Bağımlılık sırası bazen görünür etkiden önce gelir. URL standardı kararlaştırılmadan canonical etiketini topluca değiştirmek yeni çelişki üretir. Tasarım sistemi görsel boyutlarını yönetmiyorsa tek tek dosya sıkıştırmak geçici rahatlama sağlar. Kök nedeni ve tekrar riskini görevde belirtin.

Geri döndürülebilir küçük değişiklikleri ayrı yayınlamak, sonucu okumayı kolaylaştırır. Çok sayıda robots, canonical ve yönlendirme değişimini tek pakette yapmak sorun çıktığında nedeni ayırmayı zorlaştırır. Büyük geçişte prova ortamı, örnek URL seti ve geri alma koşulu önceden hazırlanmalıdır.

Görev tamamlandı işareti geliştiricinin kodu birleştirmesiyle verilmemelidir. Canlı ortamda beklenen durum kodu, HTML etiketi, bağlantı veya performans izi kontrol edilmelidir. Ardından arama sisteminin yeniden işleme süresi ayrı izlenir; teknik kabul ile organik sonuç aynı gün gerçekleşmek zorunda değildir.

Teknik SEO danışmanlığı seçerken hangi teslimler istenmelidir?

Teknik SEO danışmanlığı seçerken önce sorununuzu ve uygulama kapasitenizi paylaşın. Yazılım ekibi olmayan işletmeye yalnız geliştirici diliyle yüzlerce görev vermek uygulanabilir değildir. Kurumsal SEO danışmanlığı ise farklı ekiplerin sahipliğini, sürüm takvimini ve erişim politikasını hesaba katmalıdır.

Teklifte taranacak alan adları, ortamlar, URL sınırları ve kullanılacak veri kaynakları açık olmalıdır. “Tam teknik analiz” ifadesi tek başına kapsam değildir. Log analizi, JavaScript oluşturma testi, uluslararası etiketler veya taşıma desteği gerekiyorsa bunların dahil olup olmadığını sorun.

Örnek teslimde her bulgunun kanıtı, etkilenen şablonu, önerilen çözümü ve kabul ölçütü bulunmalıdır. Ekran görüntüsü yararlı olabilir; tekrar üretme adımı daha değerlidir. Yazılım ekibi sorunu kendi ortamında görebilmeli ve düzeltmenin geçtiğini aynı yöntemle sınayabilmelidir.

Teknik ve site içi SEO danışmanlığı birlikte yürütüldüğünde, altyapı görevi ticari sayfa planından kopmaz. Örneğin yeni kategori açma kararı URL üretimi, gezinme, metin ihtiyacı ve ölçümle birlikte ele alınabilir. Yalnız teknik uyarıları kapatmak, yanlış sayfa modelini daha düzenli hale getirebilir.

SEO danışmanlığı fiyatları; sitenin büyüklüğü kadar karmaşıklık, veri erişimi, toplantı ritmi ve uygulama desteğine göre değişebilir. Sayfa sayısını tek fiyat ölçüsü sanmayın. Az sayfalı JavaScript uygulaması derin oluşturma testi isterken, geniş fakat düzenli statik site daha standart örneklemle incelenebilir.

Garanti edilen sıralama veya kesin trafik artışı talep etmeyin. Danışman, yapacağı işi, teslim tarihini ve doğrulama yöntemini taahhüt edebilir; arama sisteminin nihai sıralamasını kontrol edemez. Sağlıklı sözleşme, belirsizliği gizlemek yerine bağımlılıkları ve müşteri tarafındaki sorumlulukları belirtir.

Rapor sonrası desteği netleştirin. Geliştiricinin sorularını kim yanıtlayacak, görev metni güncellenecek mi, canlı yayın yeniden test edilecek mi? Tek seferlik PDF ile uygulama danışmanlığı farklı hizmetlerdir. İhtiyacınıza uygun SEO danışmanlığı kapsamını değerlendirirken bu ayrımı teklif üzerinde görünür kılın.

Teknik SEO denetimi uygulamaya nasıl dönüştürülür?

Denetim, hedef sayfa envanterinden canlı doğrulamaya uzanan tekrar edilebilir bir iş akışına dönüştürülmelidir. Araç çıktısını teslim edip beklemek, sorumluluk ve kabul koşulunu belirsiz bırakır. Her aşamada hangi kanıtın üretileceği ve sonraki adıma kimin geçeceği yazılmalıdır.

1. Kapsamı tanımlayın

   Organik görünürlük hedefi olan şablonları, son değişiklikleri, veri erişimlerini ve teknik sınırları kaydedin.

2. Hipotezi doğrulayın

   Tarama, HTML, DOM, Search Console ve log gibi kaynaklardan gerekenleri birleştirerek belirtinin nedenini sınayın.

3. Görevi yayınlayın

   Etkilenen örnekleri, çözüm sınırını, sorumluyu, riskleri ve test edilebilir kabul ölçütünü aynı kayda ekleyin.

4. Canlıda yeniden test edin

   Düzeltmeyi kullanıcı ve bot görünümünde kontrol edin; arama etkisini ayrı zaman serisinde takip edin.

İlk turda bütün siteyi değiştirmek yerine temsilci bir şablonda çözümü deneyin. Sonuç beklendiği gibiyse kapsamı genişletin. Bu yaklaşım özellikle canonical, yönlendirme ve JavaScript bileşenlerinde toplu hatanın etkisini sınırlar.

Son rapor, kapanan ve açık kalan işleri ayırmalıdır. Uygulanmayan önerinin gerekçesi, bağımlılığı ve yeniden değerlendirme tarihi görünür olsun. Böylece sonraki denetim aynı bulguyu yeniymiş gibi sunmaz; ekip kararın hangi koşullarda alındığını anlayabilir.