E-Ticaret SEO Projesinde Developer Desteği Neden Gerekir?

E-ticaret SEO projesine başlanırken en sık gözden kaçan konulardan biri developer kapasitesidir.

Keyword research yapılabilir, kategori mimarisi yeniden tasarlanabilir, teknik audit tamamlanabilir ve onlarca doğru öneri çıkarılabilir. Fakat bu önerilerin önemli bölümü CMS üzerinden birkaç metin değiştirerek uygulanamıyorsa SEO ekibi bir noktadan sonra geliştirici desteğine ihtiyaç duyar.

Özellikle büyük kataloglarda mesele daha da belirgin hale gelir. Faceted navigation, pagination, ürün varyantları, canonical üretimi, structured data, ürün yaşam döngüsü, JavaScript rendering, sitemap kuralları ve internal linking sistemlerinin önemli bölümü doğrudan platform davranışına bağlıdır.

Bu yüzden e-ticaret SEO projesinde doğru soru:

“SEO ajansının developer’ı var mı?”

değil:

“SEO kararlarını kim teknik gereksinime çevirecek, kim uygulayacak ve canlıya çıktıktan sonra kim doğrulayacak?”

olmalıdır.

DigitalPlus’ın E-Ticaret SEO çalışmalarında kategori mimarisi, ürün sayfaları, filtre sistemleri, yapısal veri ve dönüşüm ölçümünü aynı operasyon içinde ele almamızın nedeni de budur. E-ticarette SEO, yalnız içerik optimizasyonu değil, platformun nasıl URL ve ürün verisi ürettiğine kadar uzanan bir sistem problemidir.

E-Ticaret SEO’da Hangi İşler Developer Gerektirir?

Her SEO task’i developer işi değildir.

Title, meta description, bazı kategori metinleri, ürün içerikleri veya belirli internal linkler kullanılan CMS’e göre SEO ya da content ekibi tarafından uygulanabilir.

Fakat problem sayfa içeriğinde değil sistem davranışındaysa geliştirici müdahalesi gerekir.

Örneğin kategori filtreleri her seçimde yeni indexlenebilir URL oluşturuyorsa bunu bir içerik editörü düzeltemez. Ürün varyantlarında canonical yanlış üretiliyorsa yüzlerce sayfaya manuel etiket girmek yerine product template veya routing mantığının değiştirilmesi gerekir.

Benzer biçimde “Daha Fazla Yükle” butonundan sonra gelen ürünler crawler tarafından ulaşılabilir bağlantılarla sunulmuyorsa sorun kategori metninde değildir. Listing component’in nasıl çalıştığıyla ilgilidir.

Google da e-ticaret sitelerinde kategori, alt kategori ve ürün sayfalarının crawl edilebilir bağlantılar üzerinden ulaşılabilir olmasını öneriyor. Bu yüzden frontend davranışının Search için önemli olduğu birçok durumda SEO gereksiniminin teknik implementasyona dönüşmesi kaçınılmazdır.

Pagination ve ürün keşfinin nasıl çalışması gerektiğini E-Ticarette Sayfalama, Load More ve Infinite Scroll rehberinde ayrıntılı olarak ele alıyoruz.

Faceted Navigation Developer Olmadan Neden Zor Yönetilir?

E-ticaret sitelerinde developer ihtiyacının en açık görüldüğü alanlardan biri faceted navigation’dır.

Kullanıcıların marka, renk, beden, fiyat veya teknik özelliklere göre ürünleri filtrelemesi UX açısından değerlidir. Ancak altyapı her kombinasyon için ayrı URL üretiyorsa Search tarafında kısa sürede çok büyük bir URL alanı oluşabilir.

SEO ekibi hangi filtrelerin gerçek organik talep taşıdığını belirleyebilir. Hangi kombinasyonların indexlenmesi, hangilerinin yalnız kullanıcı deneyimi için kalması gerektiğine dair politika oluşturabilir.

Fakat bu politikanın gerçek site davranışına dönüşmesi çoğu zaman development işidir.

Routing nasıl değişecek? Gereksiz URL’ler üretilecek mi? Filter state URL içinde nasıl tutulacak? Internal links hangi kombinasyonlara gidecek? Empty-result filtreler hangi HTTP davranışını gösterecek?

Bunların cevabı yalnız SEO dokümanında kalırsa hiçbir şey değişmez.

Google’ın faceted navigation rehberi de kontrolsüz filtre sistemlerinin çok büyük URL alanları ve gereksiz crawling oluşturabileceğini açıkça belirtiyor. Bu yüzden DigitalPlus’ın Faceted Navigation SEO yaklaşımında yalnız index/noindex kararı vermek yerine frontend davranışı, URL üretimi ve Search ownership’i birlikte ele alıyoruz.

Buradaki developer desteği “SEO ekibi teknik bilmiyor” anlamına gelmez. Aksine SEO gereksiniminin production sistemine uygulanabilmesi için doğru uzmanlıkların birlikte çalışması gerekir.

Ürün Varyantlarında SEO Kararı ile Teknik Uygulama Ayrılmalıdır

Ürün varyantlarında da benzer durum vardır.

SEO ekibi hangi ürün seçeneklerinin bağımsız arama talebi taşıdığını, hangi varyantların aynı product family içinde kalması gerektiğini ve canonical stratejisinin nasıl olması gerektiğini belirleyebilir.

Ancak sistem her renk veya beden seçildiğinde ne yapacak?

Yeni URL mi açacak? Query parameter mı kullanacak? Canonical hangi ürüne dönecek? Structured data aktif varyantın fiyat ve stok bilgisini mi gösterecek? Merchant feed hangi URL’yi gönderecek?

Bu sorular platform seviyesinde cevaplanır.

Özellikle büyük kataloglarda tek bir yanlış template davranışı binlerce ürün URL’sini etkileyebilir. Bu nedenle varyantları manuel sayfa optimizasyonu olarak değil, sistem tasarımı olarak ele almak gerekir.

DigitalPlus’ın Ürün Varyantları SEO rehberi URL, canonical, SKU, GTIN ve product data ilişkisini bu yüzden birlikte değerlendiriyor. Ürün sayfasının daha geniş SEO rolü için de E-Ticaret Ürün Sayfası SEO rehberi ayrı owner olarak kullanılabilir.

JavaScript Kullanan E-Ticaret Sitelerinde Developer Desteği Daha Kritik Hale Gelir

Modern e-ticaret sitelerinde önemli bileşenlerin JavaScript ile çalışması normaldir.

Filtreler, ürün kartları, fiyatlar, varyant seçimi, pagination veya related products tamamen frontend component’leri üzerinden üretilebilir.

JavaScript kullanmak kendi başına SEO problemi değildir.

Problem, önemli içerik veya bağlantıların crawler tarafından güvenilir biçimde alınamamasıdır.

Örneğin kullanıcı tarayıcıda 100 ürünü görüyor olabilir ama kaynak ve render edilmiş yapı incelendiğinde crawler yalnız ilk 20 ürüne erişebiliyor olabilir.

Ya da ürün structured data’sı JavaScript ile geç oluşturuluyor ve fiyat veya availability bilgisi sayfadaki gerçek durumla zaman zaman uyuşmuyor olabilir.

Google, e-ticaret navigasyonunda gerçek <a href> bağlantılarının kullanılmasını öneriyor. Product structured data tarafında da hızlı değişen fiyat ve stok bilgilerinin dinamik JavaScript ile üretilmesinin Shopping crawl’larını daha az güvenilir hale getirebileceğine dikkat çekiyor.

Bu tip sorunlar SEO ekibinin yalnız öneri hazırlayarak çözebileceği alanlar değildir.

Frontend veya backend ekibinin:

rendering, hydration, routing, component davranışı veya server-side output üzerinde değişiklik yapması gerekebilir.

Bu nedenle JavaScript ağırlıklı altyapılarda Teknik SEO ile development süreci birbirinden tamamen kopuk çalışmamalıdır.

SEO Ajansının Kendi Developer’ı Olması Şart mı?

Hayır.

Bir e-ticaret SEO ajansının bütün teknik uygulamaları kendi developer ekibiyle yapması zorunlu değildir.

Özellikle orta ve büyük şirketlerde zaten ürün, frontend, backend veya platform ekipleri bulunabilir. Bu durumda dışarıdaki SEO partnerinin şirketin mevcut geliştirme ekibinin yerine geçmeye çalışması gereksizdir.

Daha önemli olan SEO ekibinin teknik gereksinimi developer’ın uygulayabileceği kadar açık yazabilmesidir.

Örneğin:

“Facet’leri düzeltin.”

bir developer task’i değildir.

Buna karşılık iyi tanımlanmış bir task:

hangi URL pattern’lerinin etkileneceğini, hangi durumda kalıcı URL üretileceğini, canonical davranışını, empty-result durumunu, internal linking beklentisini ve test edilecek edge case’leri açıklar.

Bu durumda şirketin kendi developer’ı uygulamayı yapabilir.

DigitalPlus’ın SEO Audit yaklaşımında da bazı problemlerin CMS, bazılarının geliştirici, sunucu veya analitik ekip gerektirdiğini özellikle ayırıyoruz. Audit’in görevi yalnız problemi bulmak değil, hangi ekibin ne uygulayacağını da mümkün olduğunca net hale getirmektir.

Asıl Kritik Konu: SEO Task’i Developer Ticket’ına Dönüşebiliyor mu?

E-ticaret projelerinde strateji ile implementation arasındaki en büyük kayıp genellikle burada yaşanır.

SEO uzmanı problemi doğru teşhis eder.

Rapor hazırlanır.

Developer’a iletilir.

Sonra task:

“SEO ekibinin istediği canonical düzenlemesi”

gibi tek satırlık bir Jira kartına dönüşür.

Developer doğal olarak kendi anladığı şekilde uygular. SEO ekibi ise iki hafta sonra crawl yaptığında beklediğinden farklı bir davranışla karşılaşır.

Bu yüzden teknik SEO önerisinin uygulama task’ına dönüşürken en az üç şeyi netleştirmesi gerekir:

Mevcut davranış nedir?

Beklenen davranış nedir?

Doğru uygulandığını nasıl test edeceğiz?

Örneğin ürün varyantı task’ında yalnız “canonical ana ürüne gitmeli” yazmak yerine hangi variant URL’lerinin nasıl davranacağı, doğrudan açıldığında hangi ürün state’ini göstereceği ve structured data’nın hangi varyanta göre üretileceği açıklanmalıdır.

Bu ayrım büyük projelerde son derece önemlidir çünkü tek bir belirsiz requirement binlerce URL’de yanlış implementasyona dönüşebilir.

Acceptance Criteria Neden SEO Projesinin Parçası Olmalı?

Developer task’inin “completed” durumuna geçmesi SEO işinin gerçekten tamamlandığı anlamına gelmez.

SEO açısından tamamlanma kriteri canlı davranıştır.

Örneğin pagination problemi için developer yeni bağlantılar eklemiş olabilir.

Acceptance criteria şu kontrolleri içerebilir:

Sonraki pagination URL’si gerçek bir URL mi? Link <a href> olarak üretiliyor mu? URL doğrudan açılabiliyor mu? Canonical doğru mu? Ürün listesi beklendiği gibi geliyor mu? Internal links aynı URL formatını mı kullanıyor?

Böylece QA, “tasarım düzgün görünüyor” seviyesinden gerçek SEO doğrulamasına çıkar.

DigitalPlus’ın pagination ve infinite scroll rehberinde kullanıcı arayüzü ile crawler’ın ürünleri keşfetme yolunu ayrı değerlendirmemizin nedeni budur.

Staging QA Olmadan Teknik SEO Uygulaması Risklidir

Özellikle büyük e-ticaret sitelerinde teknik değişiklikleri doğrudan production’a çıkarmak gereksiz risk yaratır.

Facet routing, canonical, structured data, pagination veya ürün template’i değişiyorsa staging ortamında örnek URL’lerle kontrol yapılması daha sağlıklıdır.

Burada SEO ekibi developer’ın kodunu incelemek zorunda değildir.

Ancak çıktıyı test edebilmelidir.

Örneğin yeni facet sistemi staging’de:

gereksiz URL üretmiyor mu, indexlenmesi gereken owner URL’leri koruyor mu, canonical beklendiği gibi mi, empty combinations doğru davranıyor mu?

Bu kontroller production öncesi yapılırsa hatanın binlerce URL’ye yayılması engellenebilir.

Büyük kataloglarda bu fark küçümsenmemelidir. Tek bir template veya routing değişikliği geniş bir URL grubunu aynı anda etkileyebilir.

Canlıya Çıktıktan Sonra Developer’ın İşi Bitiyor mu?

Geliştirme açısından task bitebilir.

SEO açısından genellikle bir doğrulama aşaması daha vardır.

Production sonrasında:

örnek URL’ler tekrar crawl edilmeli, kaynak veya render edilmiş HTML kontrol edilmeli, canonical ve structured data doğrulanmalı, gerekirse Search Console veya server log verileri takip edilmelidir.

Çünkü staging’de doğru çalışan davranış production ortamında CDN, cache, routing veya farklı veri nedeniyle aynı sonucu vermeyebilir.

DigitalPlus’ın Teknik SEO çalışmalarında implementation sonrası kontrolü ayrı bir aşama olarak ele almamızın nedeni budur. SEO task’i önerinin yazıldığı anda değil, canlı sistem beklenen davranışı ürettiğinde kapanmalıdır.

E-Ticaret SEO’da Developer Desteği Hangi Alanlarda En Sık Gerekir?

Her platform farklıdır fakat developer ihtiyacının sık ortaya çıktığı alanlar genellikle aynı sistemlerin çevresinde toplanır.

Facet ve parametre URL yönetimi, pagination, canonical üretimi, ürün varyantları, structured data, sitemap otomasyonu, site içi arama davranışı, ürün lifecycle kuralları, JavaScript rendering, breadcrumb ve template-level internal linking bunların başında gelir.

Bunların her biri ayrı bir uzun teknik rehber konusu olduğu için aynı detayları bu procurement içeriğinde yeniden anlatmak gereksiz olur.

Örneğin filtre sistemi için Faceted Navigation SEO, varyant yapısı için Ürün Varyantları SEO, pagination için Sayfalama, Load More ve Infinite Scroll, search result URL’leri için Site İçi Arama SEO owner olarak kullanılmalıdır.

Bu yazının amacı bu problemlerin nasıl çözüleceğini tekrar öğretmek değil, neden developer kapasitesinin e-ticaret SEO scope’unun bir parçası olduğunu açıklamaktır.

Site İçi Arama ve Kategori Fırsatlarında Developer Nerede Devreye Girer?

Site içi arama güzel bir örnektir çünkü burada SEO, UX ve development aynı sistemde kesişir.

Kullanıcıların aradığı sorgular yeni kategori fırsatları gösterebilir. SEO ekibi search loglarını inceleyip tekrarlanan ve ticari değeri olan sorguları çıkarabilir.

Fakat mevcut search URL’lerini olduğu gibi indexletmek doğru çözüm olmayabilir.

Yeni kalıcı kategori açılması, routing’e eklenmesi, navigasyona bağlanması veya ilgili ürünlerin bu owner’a atanması gerekebilir.

Google da ürünlerin yalnız search box üzerinden bulunmasına güvenilmemesini, indekslenmesi istenen ürünlerin crawlable navigasyon bağlantılarıyla ulaşılabilir olmasını öneriyor.

DigitalPlus’ın E-Ticaret Site İçi Arama SEO yaklaşımında bu nedenle search query’yi önce demand signal olarak kullanıyor, gerçek fırsat olduğunda kalıcı category/landing owner’a dönüştürüyoruz.

Bu dönüşüm çoğu zaman yalnız SEO editörünün CMS içinde yapacağı değişiklik değildir. Kategori sistemi, routing veya product assignment altyapısı developer desteği gerektirebilir.

Product Structured Data’da Developer Desteği Neden Önemli?

Küçük sitelerde birkaç sayfanın JSON-LD’si manuel olarak düzenlenebilir.

Binlerce ürünlü e-ticaret sitesinde structured data template veya product data sistemi üzerinden otomatik üretilir.

Bu nedenle hata da otomatik ölçeklenir.

Product name, SKU, GTIN, price, currency, availability veya variant ilişkisi yanlış data mapping’den geliyorsa SEO uzmanının birkaç sayfada schema düzenlemesi sorunu çözmez.

Kaynak verinin ve template mantığının düzeltilmesi gerekir.

Google ürün structured data’sının ürün bilgilerini daha açık anlamaya yardımcı olabileceğini ve özellikle merchant sayfalarında fiyat, stok, shipping ve diğer ürün bilgilerinin kullanılabildiğini belirtiyor.

Burada SEO ekibinin görevi hangi verinin gerektiğini ve mevcut output’un doğru olup olmadığını kontrol etmek olabilir.

Developer’ın görevi ise bu veriyi binlerce ürün sayfasında güvenilir şekilde üreten sistemi kurmaktır.

Bu tam olarak strateji ile implementation’ın neden ayrı ama birbirine bağımlı olduğunu gösterir.

Developer Desteği Yoksa SEO Projesi Yapılamaz mı?

Yapılabilir.

Ancak yapılabilecek işlerin sınırı baştan bilinmelidir.

Örneğin şirketin geliştirme kapasitesi yoksa SEO ekibi kategori research, query ownership, içerik, metadata, internal linking ve mevcut CMS’in izin verdiği teknik ayarlar üzerinde ilerleyebilir.

Fakat audit sırasında kritik bir platform problemi ortaya çıkarsa bunun backlog’da bekleyeceği bilinmelidir.

Örneğin kategori ürünlerinin büyük bölümü crawler tarafından bulunamıyor ve çözüm frontend geliştirmesi gerektiriyorsa içerik üretimine devam etmek bu blocker’ı ortadan kaldırmaz.

Bu nedenle developer kapasitesi bulunmayan şirketlerde SEO kapsamı hazırlanırken teknik bağımlılıklar özellikle belirlenmelidir.

DigitalPlus’ın canlı Teknik SEO hizmetinde de geliştirici ekibi bulunmayan şirketler için teknik uygulamanın kullanılan altyapıya göre ayrıca kapsamlandırılabileceği belirtiliyor. Yani çözüm her zaman in-house developer değildir; fakat birinin implementation ownership’ini üstlenmesi gerekir.

Developer Desteği SEO Ajansının Fiyatını Neden Değiştirir?

Çünkü “teknik SEO dahil” cümlesi çok farklı hizmet kapsamları anlamına gelebilir.

Bir teklif yalnız problemi bulup recommendation dokümanı teslim edebilir.

Başka bir teklif technical specification hazırlayabilir, development ekibiyle toplantılara girebilir, ticket yazabilir, staging QA yapabilir ve production sonrası doğrulama gerçekleştirebilir.

Üçüncü sağlayıcı bütün bunlara ek olarak geliştirmeyi de kendi ekibiyle üstlenebilir.

Doğal olarak bu üç modelin maliyeti aynı olmaz.

Bu nedenle e-ticaret SEO teklifini değerlendirirken yalnız aylık ücret değil, uygulama ownership’i de karşılaştırılmalıdır.

DigitalPlus’ın Büyük E-Ticaret Sitelerinde SEO Bütçesi yaklaşımında developer kapasitesini bütçe belirleyen ana değişkenlerden biri olarak ayırmamızın nedeni budur.

Daha genel teklif değerlendirmesi için SEO Teklifinde Neler Olmalı? rehberindeki analiz, uygulama ve kapsam ayrımı da kullanılabilir.

Developer Saatini SEO Bütçesine Dahil Etmek Gerekir mi?

Toplam yatırım hesabında evet.

SEO ajansı geliştiriciyi ayrıca faturalandırmasa bile şirketin kendi development ekibinin ayırdığı kapasite gerçek bir proje maliyetidir.

Bu yüzden büyük e-ticaret SEO bütçesi yalnız agency retainer değildir.

Daha doğru toplam maliyet:

SEO Strategy + Developer Capacity + Content + Analytics + Tools + QA

üzerinden değerlendirilmelidir.

Özellikle enterprise yapılarda developer saatleri başka ürün projeleriyle rekabet eder. SEO requirement’ın backlog’a girmesi bile yeterli değildir; business impact açık değilse aylarca bekleyebilir.

Bu yüzden SEO ekibinin teknik task’i yalnız doğru yazması değil, neden öncelikli olduğunu da anlatabilmesi gerekir.

SEO ve Developer Ekipleri Önceliği Nasıl Belirlemeli?

Her teknik SEO task’i P0 değildir.

Bir crawler’da görünen warning ile para kazandıran kategori grubunun indexation’ını bozan template problemi aynı öncelikte tutulmamalıdır.

Developer backlog’una giren SEO task’leri en azından etki, kapsam, kanıt, ticari değer ve uygulama riskine göre sıralanabilir.

Örneğin binlerce önemsiz URL’deki küçük markup uyarısı yerine ana ticari kategorilerin canonical davranışını bozan problem önce çözülmelidir.

DigitalPlus’ın SEO Audit çalışmalarında bulguları P0-P3 gibi seviyelerle önceliklendirebilmemizin nedeni bu. Amaç developer ekibine mümkün olduğunca fazla SEO işi göndermek değil, gerçekten etkili işleri doğru sırada göndermektir.

SEO ve Developer Sprintleri Birbirine Nasıl Bağlanmalı?

Büyük e-ticaret sitelerinde SEO’nun ayrı bir doküman evreninde yaşaması sağlıklı değildir.

SEO task’leri mümkün olduğunca şirketin gerçek development sürecine girmelidir.

Örneğin:

SEO ekibi problemi doğrular, requirement ve acceptance criteria’yı hazırlar.

Product veya engineering ekip task’i sprint’e alır.

Developer implementation yapar.

SEO staging QA gerçekleştirir.

Production sonrası gerçek URL’lerde yeniden doğrulama yapılır.

Bu çalışma:

Diagnosis → Requirement → Development → QA → Release → Validation

şeklinde ilerler.

Belirli ve kapanabilir technical SEO problemlerinde bu model SEO Sprintleri gibi proje bazlı çalışma biçimine de oldukça uygundur.

Ancak e-ticaret sitesi sürekli geliştiriliyorsa ve her sprint yeni SEO dependency’leri çıkarıyorsa ongoing SEO Danışmanlığı daha doğal çalışma biçimi haline gelebilir.

Developer Ekibi SEO Bilmeli mi?

Temel prensipleri bilmesi faydalıdır, fakat developer’ın SEO uzmanı olması gerekmez.

Developer’ın görevi search intent araştırması yapmak veya hangi kategori query’sinin ticari değer taşıdığını belirlemek değildir.

SEO ekibinin de her framework’ün kaynak kodunu geliştirebilmesi gerekmez.

Önemli olan iki tarafın ortak bir requirement dili kurmasıdır.

SEO:

“Google bunu sevmez.”

demek yerine beklenen teknik davranışı açıklamalıdır.

Developer da:

“Framework böyle çalışıyor.”

deyip konuyu kapatmak yerine requirement’ın uygulanabileceği teknik seçenekleri değerlendirmelidir.

İyi e-ticaret SEO operasyonu bu iki uzmanlığın kesişiminde kurulur.

SEO Ajansı ile Developer Arasındaki Sorumluluk Nasıl Bölünmeli?

Aşama	SEO / Ajans	Developer / Teknik Ekip
Teşhis	Search problemini ve etkilenen URL grubunu doğrular	Teknik kaynağı anlamaya destek olur
Gereksinim	Beklenen SEO davranışını tanımlar	Uygulama yöntemini tasarlar
Implementation	Gerekirse danışmanlık verir	Kod veya altyapı değişikliğini uygular
Staging QA	SEO acceptance criteria’yı kontrol eder	Bulunan teknik hataları düzeltir
Production	Canlı davranışı yeniden doğrular	Release ve teknik stabiliteyi yönetir
Measurement	Crawl, indexation ve organik etkiyi izler	Gerekirse yeni teknik iterasyon yapar

Bu tablo her şirkette birebir aynı olmak zorunda değildir.

Bazı ajanslar development’ı da üstlenebilir. Bazı şirketlerde product manager teknik koordinasyonu yönetebilir. Küçük mağazalarda WordPress veya Shopify değişikliklerinin önemli bölümü SEO ekibi tarafından yapılabilir.

Ama kim yaparsa yapsın üç rol sahipsiz kalmamalıdır:

Requirement → Implementation → QA

SEO Teklifinde Developer Desteği Nasıl Yazılmalı?

Teklifte yalnız “teknik SEO dahildir” yazması yeterli değildir.

Özellikle büyük e-ticaret projelerinde şu ayrım açık olmalıdır:

Audit kim tarafından yapılacak? Developer task’lerini kim hazırlayacak? Development dahil mi? Dahil değilse şirketin kendi ekibiyle kaç toplantı veya sprint desteği verilecek? Staging QA yapılacak mı? Canlı sonrası doğrulama kapsamda mı?

Aksi halde iki taraf da farklı şey satın aldığını düşünebilir.

Müşteri “teknik SEO aldım, sorunlar düzeltilecek” diye düşünürken ajans “biz yalnız öneri teslim ediyoruz” diyebilir.

Bu tür scope belirsizlikleri daha proje başlamadan çözülmelidir.

Teklif kapsamının nasıl okunması gerektiğini SEO Teklifinde Neler Olmalı? içeriğinde daha geniş olarak ele alıyoruz.

E-Ticaret SEO Ajansı Seçerken Developer Tarafında Ne Sormalısınız?

Satış görüşmesinde “developer’ınız var mı?” tek başına fazla yüzeysel kalır.

Bunun yerine ajansın gerçek çalışma modelini anlamaya çalışın.

Örneğin büyük kataloglarda technical recommendation’ları nasıl ticket’a dönüştürdüğünü, staging QA yapıp yapmadığını, JavaScript ve rendering problemlerini nasıl doğruladığını ve şirket içi engineering ekibiyle nasıl çalıştığını sorun.

Faceted navigation veya ürün varyantı gibi bir problem örneği verip:

“Burada sizin ekip ne yapar, bizim developer ne yapar?”

diye sorun.

Cevap size scope’un oldukça büyük bölümünü anlatır.

Büyük katalog için ajans seçim kriterlerini daha geniş kapsamda Büyük E-Ticaret Siteleri İçin SEO Ajansı Seçerken Nelere Dikkat Edilmeli? rehberinde ele alıyoruz.

Developer Desteği Olmadan Önce Hangi SEO İşleri Yapılabilir?

Development kapasitesi henüz hazır değilse SEO projesini tamamen durdurmak zorunda değilsiniz.

Query research, kategori ownership, mevcut sayfaların performance analizi, içerik briefleri, site içi arama verisi, commercial priority ve teknik backlog hazırlanabilir.

Böylece developer kapasitesi açıldığında ne yapılacağı bellidir.

Fakat kritik teknik blocker doğrulanmışsa bunu backlog’un altına gömüp aylarca yalnız içerik üretmek mantıklı değildir.

Örneğin ana ürün grubunuzun önemli bölümü crawlable navigation içinde bulunamıyorsa daha fazla blog yazmak ürün discovery problemini çözmez.

Bütçe ve kaynak sınırlı olduğunda bu tür önceliklendirme için SEO Bütçesi Düşükse Neye Öncelik Verilmeli? yaklaşımı kullanılabilir.

Developer Desteği E-Ticaret SEO Projesinde Sürekli mi Gerekir?

Her hafta developer gerekmeyebilir.

İhtiyaç projenin aşamasına göre değişir.

İlk teknik borç temizliği sırasında development yoğunluğu yüksek olabilir. Category ve content growth döneminde developer ihtiyacı azalabilir. Daha sonra redesign, migration veya yeni filtre sistemi geldiğinde tekrar artabilir.

Bu yüzden developer desteğini sabit saat paketinden çok dependency olarak düşünmek daha faydalıdır.

SEO roadmap’te developer gerektiren task’ler ayrı işaretlenebilir ve engineering sprintleriyle koordine edilebilir.

Belirli technical backlog kapatılacaksa SEO Sprinti yeterli olabilir. Platform düzenli geliştiriliyor ve SEO her release’ten etkileniyorsa daha sürekli çalışma gerekir.

E-Ticaret SEO’da Developer Desteği Olmadan Hangi Riskler Oluşur?

En büyük risk teknik problemlerin bilinmesine rağmen kapanmamasıdır.

Audit yapılır, doğru bulgular çıkarılır, rapor hazırlanır ve altı ay sonra aynı problemler hâlâ canlıdadır.

Bu durumda işletme aslında SEO bilgisinden değil implementation kapasitesinden yoksundur.

İkinci risk geçici workaround’ların kalıcı mimariye dönüşmesidir. SEO ekibi developer erişimi olmadığı için sürekli manuel redirect, plugin veya CMS hack’leriyle problemi çevrelemeye çalışabilir.

Üçüncü risk ise yeni geliştirmelerin eski SEO problemlerini tekrar üretmesidir.

SEO ve engineering birbirinden kopuksa yeni component, filtre veya ürün yapısı production’a çıktıktan sonra sorun fark edilir.

Bu yüzden developer desteğinin değeri yalnız mevcut hataları düzeltmek değildir. Yeni teknik borcun oluşmasını engelleyen süreç de en az eski hataları kapatmak kadar önemlidir.

Sonuç: E-Ticaret SEO Projesinde Developer Desteği Neden Gerekir?

E-ticaret SEO projesinde developer desteği, SEO ajansının teknik görünmek için yanında bulundurduğu ek servis değildir.

Kategori ve ürün mimarisi büyüdükçe SEO kararlarının önemli bölümü platform davranışına dönüşür.

Facet URL’lerinin nasıl üretildiği, ürün varyantlarının nasıl modellenip canonical edildiği, pagination’ın ürünleri nasıl açtığı, structured data’nın hangi kaynaktan beslendiği veya JavaScript component’lerinin crawler’a ne sunduğu doğrudan development alanına girer.

Bu yüzden sağlıklı operasyon:

SEO Diagnosis → Technical Requirement → Developer Implementation → Staging QA → Production Validation → Measurement

şeklinde çalışmalıdır.

SEO ajansının bütün kodu kendisinin yazması şart değildir.

Fakat SEO gereksinimini uygulanabilir task’e çevirebilmesi, development ekibiyle aynı problemi konuşabilmesi ve canlıya alınan değişikliği doğrulayabilmesi gerekir.

Developer ekibinin de SEO stratejisini üretmesi gerekmez. Uygulanacak davranış ve acceptance criteria net olduğunda kendi uzmanlığıyla doğru teknik çözümü geliştirebilir.

Bu nedenle e-ticaret SEO teklifi alırken yalnız içerik, audit ve raporlama kapsamına bakmayın. Implementation ownership’in kimde olduğunu mutlaka netleştirin.

Kategori, ürün, faceted navigation, ürün verisi ve teknik uygulamayı tek SEO sistemi içinde yönetmeniz gerekiyorsa E-Ticaret SEO commercial owner’dır. Önce mevcut teknik problemlerin ve bağımlılıkların teşhis edilmesi gerekiyorsa SEO Audit, doğrulanmış teknik problemlerin uygulanması gerekiyorsa Teknik SEO üzerinden ilerlemek daha doğru olabilir.