E-Tablo Formülleriyle Satır Bağımsız Toplu Meta Veri Düzenleme

Yüzlerce veya binlerce sayfanın meta title, meta description, H1 ve diğer SEO alanlarını tek tek düzenlemek hem zaman kaybettirir hem de hata riskini büyütür. E-Tablo Formülleriyle Satır Bağımsız Toplu Meta Veri Düzenleme yaklaşımı, her URL için kendi kaynak verisini kullanan ve diğer satırlardan bağımsız çalışan formüllerle bu işi kontrollü biçimde ölçeklendirmeyi sağlar. Buradaki amaç her sayfaya aynı metni yapıştırmak değil, ürün adı, kategori, lokasyon, anahtar kelime ve marka gibi alanları satır seviyesinde birleştirerek özgün ve denetlenebilir çıktılar üretmektir. Bu rehberde Excel formülleriyle toplu meta title ve description düzenleme nasıl yapılır, Google Sheets ile SEO meta verileri toplu nasıl oluşturulur ve binlerce URL için QA, override, import, rollback ve versioning yapısı nasıl kurulmalıdır sorularını uygulama odaklı ele alacağız. Sonuçta elinizde yalnızca birkaç formül değil, ekip içinde kullanılabilecek ve daha sonra Apps Script, Python veya CMS API süreçlerine taşınabilecek sürdürülebilir bir metadata çalışma modeli olacak.

E-Tablo ile Toplu Meta Veri Düzenleme Nedir?

E-tablo ile toplu meta veri düzenleme, çok sayıda URL'nin SEO alanlarını satır bazlı kaynak verilerden formüllerle üretme, kontrol etme ve yayına hazırlama yöntemidir. Bu yapı özellikle ürün kataloğu, kategori sayfaları, lokasyon sayfaları ve programmatic SEO projelerinde ciddi zaman kazandırır. Her satır ayrı kayıt olarak tutulduğu için meta title veya description ilgili URL'nin kendi ürün adı, kategori veya lokasyon bilgisinden oluşturulabilir. Formül çıktısı doğrudan yayınlanmak zorunda değildir; QA, manuel override ve approval katmanlarından geçirilebilir. Böylece e-tablo basit veri giriş ekranı olmaktan çıkar ve kontrollü SEO üretim hattına dönüşür.

Bulk Metadata Editing Ne Anlama Gelir?

Bulk metadata editing, çok sayıda sayfanın meta alanlarını tek bir ortak çalışma seti üzerinden düzenlemek anlamına gelir. Burada temel avantaj aynı işlemi yüzlerce kez elle tekrarlamak yerine kuralları bir kez tanımlamaktır. Örneğin ürün adı, kategori ve marka alanlarından otomatik title üretilebilir. Her satır kendi değerlerini kullandığı için aynı formül binlerce satırda farklı çıktı oluşturabilir. Kaliteli bir bulk düzenleme süreci mutlaka QA, duplicate kontrolü ve backup mekanizmasıyla desteklenmelidir.

Tek Tek Sayfa Düzenlemekten Farkı

Tek tek düzenleme küçük sitelerde yönetilebilir olabilir ancak URL sayısı büyüdükçe operasyon maliyeti hızla artar. E-tablo yaklaşımında değişiklik mantığı formüle taşındığı için aynı kural bütün uygun satırlara uygulanır. Marka adı veya separator değiştiğinde yüzlerce kaydı yeniden yazmak yerine config veya formül güncellenebilir. Bununla birlikte yüksek değerli landing page'ler tamamen otomasyona bırakılmamalıdır. En sağlıklı model, düşük riskli sayfalarda otomasyon ve önemli sayfalarda insan kontrolünü birlikte kullanır.

Hangi SEO Alanları Toplu Düzenlenebilir?

E-tablo yalnızca meta title ve meta description üretmek için kullanılmaz. H1, slug, canonical, robots, Open Graph alanları, image alt text ve structured data alanları da satır bazlı kurallarla hazırlanabilir. Her alan için aynı otomasyon seviyesi uygun değildir. Canonical ve robots gibi teknik alanlarda deterministic formüller daha güvenilirken description gibi içerik alanlarında insan veya AI desteği gerekebilir. Bu nedenle her sütun için source, generated, override ve final ayrımının yapılması güçlü bir mimari sağlar.

Meta Title

Meta title formülle üretmeye en uygun SEO alanlarından biridir. Ürün, kategori, lokasyon ve marka gibi yapısal değerler kolayca birleştirilebilir. Karakter uzunluğu LEN ile kontrol edilebilir. Duplicate title COUNTIF veya normalize edilmiş helper sütunlarıyla bulunabilir. Yüksek trafik alan sayfalarda generated title doğrudan yayınlanmadan önce manuel review uygulanması faydalıdır.

Meta Description

Meta description daha doğal metin gerektirdiği için title'a göre biraz daha fazla kontrol ister. Ürün avantajı, kategori, lokasyon ve CTA alanları TEXTJOIN veya koşullu IF mantığıyla birleştirilebilir. Boş kaynaklar sessizce atlanarak anlamsız ayraç ve eksik cümle sorunları azaltılabilir. Description uzunluğu formülle izlenebilir ancak yalnızca karakter sayısına bakmak yeterli değildir. Okunabilirlik ve arama niyetiyle uyum da insan kontrolünün parçası olmalıdır.

H1

H1 sayfanın ana başlığını temsil ettiği için ürün veya hizmet adıyla güçlü biçimde ilişkilidir. Yapısal kataloglarda H1 formülle hazırlanabilir. Bununla birlikte title ve H1'in tamamen aynı olması zorunlu değildir. Marka veya lokasyon bilgisi yalnızca gerektiğinde eklenebilir. E-tabloda H1 için ayrı generated ve final alan tutulması daha güvenli çalışma sağlar.

URL Slug

URL slug kaynak verinin normalize edilmiş biçiminden üretilebilir. Küçük harf dönüşümü, boşlukların tireye çevrilmesi ve özel karakter temizliği formül veya script ile yapılabilir. Mevcut URL'leri topluca değiştirmek yönlendirme ve indeksleme riski taşıdığı için dikkat gerektirir. Yeni sayfalarda otomasyon daha güvenlidir. Eski URL'lerde slug değişikliği yapılacaksa redirect planı ayrı hazırlanmalıdır.

Canonical

Canonical değerleri URL veya unique ID üzerinden deterministic biçimde üretilebilir. Canonical formülü sayfa tipine göre değişebilir. Filtreli veya varyant sayfalarda canonical rule daha dikkatli tanımlanmalıdır. E-tablo teknik SEO QA için güçlü kontrol noktası sunar. Final import öncesinde canonical'ın doğru domain ve path kullandığı sample crawl ile doğrulanmalıdır.

Robots

Robots alanları index, noindex, follow veya nofollow gibi kontrollü değerler içerir. Sayfa tipi veya durum alanına göre IF veya IFS ile üretilebilir. Yanlış robots değeri organik görünürlüğü ciddi biçimde etkileyebileceği için bu alan yüksek riskli kabul edilmelidir. Formül sonucu QA sütunuyla kontrol edilmelidir. Yayın öncesinde özellikle noindex değerleri ayrı filtrelenerek incelenmelidir.

Open Graph

Open Graph title ve description alanları metadata modelinden türetilebilir. Sosyal paylaşım dili arama sonuçlarından farklı olabileceği için ayrı şablon kullanmak daha iyi sonuç verebilir. OG image URL'si de ürün veya kategori ID'sinden oluşturulabilir. Kaynak veri eksikse fallback image uygulanabilir. Final export sırasında yalnızca yayınlanacak alanlar ayrı tabloda tutulmalıdır.

Image Alt Text

Image alt text ürün, kategori veya görsel bağlamından üretilebilir. Aynı ürünün birden fazla görseli varsa tamamen aynı alt text'i tekrarlamak yerine görsel rolü eklenebilir. Formüller yapısal kataloglarda iyi başlangıç sağlar. Ancak görselin gerçekten ne gösterdiği source veride yoksa uydurma içerik üretilmemelidir. Özellikle AI kullanılıyorsa yalnızca mevcut kaynak alanlardan üretim kuralı uygulanmalıdır.

Structured Data Alanları

Structured data için gerekli name, description, SKU veya availability gibi alanlar e-tabloda hazırlanabilir. JSON-LD'nin tamamını formülle üretmek mümkün olsa da büyük yapılar hata ayıklamayı zorlaştırabilir. Daha güvenli yaklaşım source alanları tabloda hazırlayıp template'i script veya CMS katmanında oluşturmaktır. JSON-LD ve yapılandırılmış veri manipülasyonu üzerine ek bir içerik için https://www.diyarbakiryazilim.com.tr/posts/blog-ve-kurumsal-iceriklerde-json-ld-schema-manipulasyonu adresi incelenebilir. Structured data her durumda test aracı ve crawl ile doğrulanmalıdır.

Satır Bağımsız Formül Nedir?

Satır bağımsız formül, her kaydın yalnızca kendi satırındaki kaynak değerleri kullanarak çıktı üretmesini sağlayan formül yaklaşımıdır. Başka satırın sıra numarasına, geçici hücre konumuna veya manuel kopyalama düzenine bağlı değildir. Filtreleme, sıralama veya yeni satır ekleme gibi işlemlerde formül mantığı korunur. E-tabloda her satır için dinamik meta title description formülü oluşturma hedefleniyorsa row-level logic temel tasarım prensibi olmalıdır. Bu yapı hem QA hem de daha sonra script'e geçiş açısından sistemi çok daha güvenilir hale getirir.

Her Satırın Kendi Kaynak Verisini Kullanması

Her satır kendi ürün adı, kategori, lokasyon veya keyword değerini kullanmalıdır. Böylece formül başka bir kaydın verisine yanlışlıkla bağlanmaz. Excel Table structured reference veya Google Sheets MAP gibi yapılar bu mantığı destekler. Formül bağımlılıkları açık olduğunda debug işlemi kolaylaşır. Özellikle binlerce satırda tek bir yanlış referansın yayılması böylece önlenir.

Bir Satırdaki Hatanın Diğer Satırları Etkilememesi

Kaynak verisi eksik olan tek satır bütün sütun çıktısını bozmamalıdır. IFERROR veya explicit boşluk kontrolleri kullanılabilir. Eksik keyword varsa fallback olarak product name seçilebilir. Bu durum QA status sütununda ayrıca işaretlenmelidir. Böylece sorunlu satır izole edilir ve diğer kayıtların üretimi devam eder.

Satır Sıralaması Değiştiğinde Formülün Korunması

SEO ekipleri veriyi sık sık trafik, kategori veya durum sütununa göre sıralar. Formül sabit satır numaralarına dayanıyorsa sıralama sonrası yanlış kayıt eşleşmeleri oluşabilir. Structured references veya aynı satırın hücre referansları bu riski azaltır. Unique ID her kaydın kimliğini korur. Final import URL sırasına değil ID veya güvenilir key alanına bağlanmalıdır.

Filtreleme Sonrası Veri Tutarlılığı

Filtre yalnızca görünümü değiştirmeli, formül ilişkilerini değiştirmemelidir. Görünen satırları kopyalarken hidden records yanlışlıkla export edilebilir. Export-ready tab kullanmak bu riski azaltır. Approval filtresiyle yalnızca onaylanmış kayıtlar ayrı alana taşınabilir. Filter state hiçbir zaman kayıt kimliğinin yerine kullanılmamalıdır.

Row-Level Logic Kavramı

Row-level logic her kaydı küçük bağımsız işlem birimi olarak düşünür. Bir satır source, generated, override, final ve QA alanlarını kendi içinde taşır. Bu yaklaşım script, database veya API sistemlerine geçişi kolaylaştırır. Aynı satır daha sonra JSON record olarak da temsil edilebilir. Spreadsheet böylece geçici dosya değil, açık veri modeline sahip çalışma ortamına dönüşür.

Satır Bağımsız Metadata Modelinin Avantajları

Satır bağımsız metadata modeli ölçek büyüdükçe sağladığı avantajı daha net gösterir. Bir URL'deki eksik veri diğer URL'nin çıktısını bozmaz. QA ve manual override kayıt seviyesinde yönetilir. Formula version değiştiğinde hangi kayıtların yeniden üretileceği seçilebilir. E-Tablo Formülleriyle Satır Bağımsız Toplu Meta Veri Düzenleme yaklaşımının asıl gücü, toplu işlem yaparken her URL'nin bağımsızlığını koruyabilmesidir.

Ölçeklenebilirlik

Aynı formül yüzlerce veya binlerce satıra uygulanabilir. Yeni ürün eklendiğinde kurallar baştan yazılmaz. Excel calculated column veya Google Sheets array yaklaşımı otomatik genişleme sağlar. Büyük veri setlerinde performans için range sınırları kullanılmalıdır. Belirli ölçekten sonra Apps Script veya Python'a geçiş planlanabilir.

Tutarlılık

Marka yazımı, separator ve CTA gibi kurallar tek merkezden yönetilebilir. İnsanların farklı biçimde title yazması nedeniyle oluşan stil farkları azalır. QA kuralları bütün satırlara aynı şekilde uygulanır. Tutarlılık özgünlüğün karşıtı değildir. Sayfa tipine göre farklı template kullanılarak hem standardizasyon hem çeşitlilik korunabilir.

Tekrar Kullanılabilirlik

İyi tasarlanmış formül birden fazla katalog veya site projesinde yeniden kullanılabilir. Config tab marka ve limitleri ayırırsa formül kodu değiştirilmeden uyarlanabilir. Named Functions veya LAMBDA reusable logic oluşturur. Test dataset'i yeni projelerde hızlı doğrulama sağlar. Bu yaklaşım ekip içinde küçük bir formula library oluşturmayı mümkün kılar.

QA Kolaylığı

Her satırın QA status ve score alanı bulunduğunda filtreleme kolaylaşır. Missing keyword, duplicate title veya length issue ayrı kodlarla işaretlenebilir. Conditional formatting yalnızca görsel destek sağlar. Asıl source of truth QA status değeridir. Bu yapı onaylanmayan satırların export edilmesini de engelleyebilir.

Manuel Override

Generated output her zaman final olmak zorunda değildir. Önemli sayfalarda uzman elle daha iyi title yazabilir. Override ayrı sütunda tutulduğu için formula güncellense bile insan düzenlemesi kaybolmaz. Final sütunu override doluysa onu, değilse generated değeri seçer. Bu küçük mimari kararı büyük kataloglarda çok değerli hale gelir.

Rollback

Original metadata ayrı tutulduğunda toplu değişiklik geri alınabilir. Her batch'e kimlik ve tarih eklenebilir. Hatalı import yalnızca ilgili batch üzerinden geri çevrilebilir. Önceki values export dosyasında saklanmalıdır. Rollback planı olmayan bulk SEO güncellemesi gereksiz operasyon riski taşır.

Otomasyona Hazırlık

Structured kolonlar daha sonra script ve API entegrasyonuna doğrudan temel sağlar. ID, source, generated ve final alanları açık olduğunda Python veya Apps Script aynı veri modelini okuyabilir. Spreadsheet'ten otomasyona geçerken sistem yeniden tasarlanmak zorunda kalmaz. Audit log ve sync status eklenerek production süreci kurulabilir. Böylece e-tablo başlangıç aracı olarak kalırken mimari büyümeye hazır olur.

Spreadsheet Metadata Mimarisinin Temel Katmanları

Sağlam spreadsheet mimarisi source veriyi doğrudan formül çıktısıyla karıştırmaz. Kaynak, normalizasyon, generated output, QA, override, final output, approval ve export alanları ayrı katmanlar olarak düşünülmelidir. Bu ayrım veri kaybını ve yanlış import riskini ciddi biçimde azaltır. Her katman belirli sorumluluğa sahip olduğunda ekip içinde rol yönetimi kolaylaşır. Büyük metadata projelerinde bu düzen formüllerden daha önemli hale gelebilir.

Kaynak Veri Sütunları

Source columns CMS veya katalogdan gelen gerçek veriyi taşır. URL, product name, category ve brand buna örnektir. Bu sütunlar mümkün olduğunca değiştirilmemelidir. Gerekiyorsa protected range uygulanabilir. Normalizasyon source üzerine değil ayrı helper alanlarda yapılmalıdır.

Normalizasyon Sütunları

Normalizasyon sütunları TRIM, CLEAN, SUBSTITUTE veya REGEX ile temizlenmiş değerleri tutar. Kaynak veriye zarar vermeden standart representation oluşturur. Duplicate ve formula generation bu alanlardan beslenebilir. Debug sırasında raw ve normalized değer karşılaştırılır. Gereksiz helper kolonlar büyük tabloda saklanmamalıdır.

Formül Çıktıları

Generated title ve description formül katmanında tutulur. Kullanıcı bu alanları doğrudan elle düzenlememelidir. Formula change bütün generated outputs'u güncelleyebilir. Bu nedenle final değer ayrı sütunda olmalıdır. Generated output formula QA'nın test ettiği temel draft'tır.

QA Sütunları

QA kolonları length, duplicate, missing source ve keyword presence gibi kuralları kontrol eder. Tek overall status yanında ayrı issue sütunları bulunabilir. Bu yaklaşım sorunun nedenini hızlı gösterir. QA formülleri mümkün olduğunca deterministic olmalıdır. Manual review ihtiyacı ayrı status ile işaretlenebilir.

Manuel Override Sütunları

Override alanları insanın generated çıktıyı bilinçli olarak değiştirdiği yerdir. Yalnızca yetkili ekip üyeleri edit edebilir. Boş override generated değerin kullanılacağını gösterir. Override reason eklemek audit için faydalıdır. Formula güncellemesi bu alanı değiştirmemelidir.

Final Output

Final output CMS'e gitmesi planlanan gerçek değerdir. Formül basit biçimde override varsa onu, yoksa generated değeri seçebilir. Approval başarısızsa export tab'a hiç taşınmayabilir. Final sütunu manuel giriş alanı olmamalıdır. Böylece kaynağın nereden geldiği her zaman bilinir.

Approval Durumu

Approval status yayın kararını temsil eder. Not Started, Review Required veya Approved gibi durumlar kullanılabilir. Yüksek değerli sayfalarda iki aşamalı approval düşünülebilir. Approved olmayan kayıtlar import dosyasına girmemelidir. Status değişiklikleri tarih ve kullanıcıyla audit edilebilir.

Export/Sync Alanları

Export tab yalnızca CMS'in ihtiyaç duyduğu kolonları içermelidir. Formula code yerine calculated values taşınmalıdır. Sync status ve batch ID yayın sürecini izlemeyi sağlar. API entegrasyonunda response code veya updated_at bilgisi eklenebilir. Export katmanı çalışma tabından bilinçli biçimde ayrılmalıdır.

Önerilen E-Tablo Kolon Yapısı

Kolon yapısı projenin veri sözleşmesi gibi çalışır. Her alanın amacı açık olursa formüller ve import süreçleri daha kolay yönetilir. Unique ID ve URL temel kimlik bilgilerini taşırken keyword, brand ve category üretim girdilerini oluşturur. Existing, generated ve final değerlerin ayrılması değişiklik kontrolü sağlar. QA ve approval sütunları yayına gidecek kayıtları güvenilir biçimde filtreler.

Unique ID

Unique ID kayıt için kalıcı kimliktir. URL değişse bile aynı kaydı temsil etmeye devam eder. CMS product ID veya internal page ID kullanılabilir. Duplicate ID quality gate'i kritik seviyede olmalıdır. Import ve rollback bu alan üzerinden daha güvenli çalışır.

URL

URL sayfanın mevcut adresini temsil eder. SEO analizi ve crawl eşleştirmesinde önemlidir. URL değişebilir olduğu için primary identity olarak tek başına kullanılmamalıdır. Normalize edilmiş URL helper sütunu duplicate kontrolüne yardımcı olabilir. Domain veya protocol farkları bilinçli biçimde yönetilmelidir.

Sayfa Tipi

Page type title ve description template seçiminde temel girdidir. Product, category, service, location veya blog gibi değerler kullanılabilir. Allowed values validation ile sınırlanabilir. Page type boşsa output üretmek yerine review status verilebilir. Böylece yanlış template uygulanması engellenir.

Ana Keyword

Primary keyword metadata üretiminde en değerli SEO girdilerinden biridir. Her sayfa için gerçekten ilgili olmalıdır. Keyword boşsa fallback kullanılabilir. Exact inclusion her durumda zorunlu tutulmamalıdır. Keyword stuffing kaliteyi düşürebileceği için QA yalnızca varlık kontrolüyle sınırlanmamalıdır.

İkincil Keyword

Secondary keyword title veya description'a yalnızca doğal uyum sağladığında eklenmelidir. Her satırda kullanmak gereksiz uzunluk yaratabilir. Description formülünde conditional field olarak değerlendirilebilir. Primary boşsa secondary fallback olabilir. Bu davranış config üzerinden yönetilebilir.

Ürün/Hizmet Adı

Product veya service name çoğu template'in temel içerik parçasıdır. Source katalogdan gelmelidir. Çok uzun isimler title limitini aşabilir. Short name helper sütunu gerekebilir. Kısaltma otomatik yapılacaksa anlam kaybı olmamasına dikkat edilmelidir.

Marka

Brand tutarlı biçimde yazılmalıdır. Config tab içinde merkezi brand value tutulabilir. Bazı sayfalarda source brand farklı olabilir. Missing brand title üretimini tamamen engellemek zorunda değildir. Template'e göre koşullu ekleme yapılabilir.

Kategori

Category ürünün bağlamını güçlendirir. Title'da her zaman gerekli olmayabilir ancak description veya H1 için faydalıdır. Category hierarchy varsa parent ve leaf category ayrı tutulabilir. Programmatic SEO template'i yalnızca ilgili seviyeyi kullanmalıdır. Category normalization duplicate sorunlarını azaltır.

Lokasyon

Location service ve local landing page'lerde önemli source alanıdır. Şehir ve ilçe ayrı sütunlarda tutulabilir. Location boşsa lokasyon şablonu uygulanmamalıdır. Yazım standardizasyonu duplicate kontrolünü etkiler. Türkçe karakterler korunmalı ve slug üretimi ayrı yapılmalıdır.

Existing Meta Title

Existing title backup ve diff için tutulmalıdır. Yeni draft doğrudan bu sütunun üzerine yazılmamalıdır. Organik performansı yüksek sayfalarda eski title önemli referanstır. Update sonrası yeniden export ile expected value karşılaştırılır. Rollback gerektiğinde bu alan kullanılabilir.

Generated Meta Title

Generated title formül tarafından oluşturulan draft'tır. Manual edit yapılmamalıdır. Formula version değiştiğinde otomatik yeniden hesaplanabilir. QA bu değer üzerinde çalışır. Final title ancak override ve approval kurallarından sonra belirlenmelidir.

Final Meta Title

Final title CMS'e gönderilecek değeri temsil eder. Override varsa manual value, yoksa generated value seçilebilir. Approval false ise export tab'a alınmaz. Final value üzerinde yeniden length ve duplicate QA çalıştırmak faydalıdır. Çünkü override generated kalite kurallarını bozabilir.

Existing Meta Description

Mevcut description değişiklik öncesi referans olarak saklanır. Empty değerler de ayrıca anlamlıdır. New draft ile karşılaştırma yapılır. High-performing sayfalarda otomatik overwrite engellenebilir. Rollback ve audit için korunmalıdır.

Generated Meta Description

Generated description formül veya AI draft'ını taşır. Kaynağı ayrıca belirtmek faydalıdır. Formula-generated ve AI-generated çıktılar farklı QA gerektirebilir. Character length ve duplicate kontrolü uygulanır. Human review özellikle yüksek değerli sayfalarda devam eder.

Final Meta Description

Final description yayına gidecek değerdir. Override önceliği açık olmalıdır. Boş final description istemeden CMS'e gönderilmemelidir. Approval filter ile export edilir. Import sonrası actual value ile karşılaştırılır.

QA Status

QA status satırın teknik kalite durumunu özetler. OK, Missing, Duplicate veya Review Required gibi değerler kullanılabilir. Birden fazla issue varsa priority sistemi uygulanabilir. Filter ve dashboard bu alanı kullanır. Status renk formatından bağımsız olmalıdır.

Approval Status

Approval status insan kararını temsil eder. QA OK olmak otomatik olarak Approved anlamına gelmeyebilir. Yüksek öncelikli sayfalarda owner onayı gerekebilir. Approved kayıtların timestamp'i tutulabilir. Export yalnızca izin verilen durumları almalıdır.

Unique ID Neden URL’den Ayrı Tutulmalıdır?

URL kullanıcı ve arama motoru açısından önemli olsa da veri sisteminde kalıcı kimlik olmak için her zaman uygun değildir. Slug değişebilir, kategori yapısı değişebilir veya yönlendirme nedeniyle URL güncellenebilir. Kalıcı ID bu değişikliklerden bağımsız olarak kaydı takip eder. Import, rollback ve version karşılaştırmaları daha güvenli hale gelir. Büyük kataloglarda ID kullanmamak duplicate ve yanlış update riskini ciddi biçimde artırır.

URL Değişebilir

SEO veya içerik değişikliği nedeniyle URL güncellenebilir. Eğer metadata dosyası yalnızca eski URL'yi key olarak kullanıyorsa eşleşme kaybolabilir. Unique ID aynı kaydı takip etmeye devam eder. Eski ve yeni URL ayrıca history alanında tutulabilir. Redirect kontrolü URL değişim sürecinin ayrı parçasıdır.

Ürün Handle Değişebilir

E-ticaret sistemlerinde handle ürün adına bağlı olarak güncellenebilir. Kategori veya marka değişikliği de handle değişimine yol açabilir. Internal product ID ise genellikle sabit kalır. Metadata import bu ID üzerinden yapılırsa daha güvenilir olur. Handle yalnızca görünür path bilgisi olarak kullanılabilir.

Kalıcı Kayıt Kimliği

Persistent ID her kaydın yaşam döngüsü boyunca aynı kalmalıdır. Formula output, approval ve publish history bu ID ile ilişkilendirilebilir. Database veya CMS ID kullanmak çoğu zaman uygundur. ID yoksa deterministic key oluşturulabilir. Ancak generated key'in değişmeyecek alanlardan türetilmesi gerekir.

Import Sonrası Doğru Kaydı Bulma

Import sonrasında yeniden export yapıldığında ID üzerinden join kurulabilir. URL sırası farklı olsa bile expected ve actual değerler doğru eşleşir. Missing update kolay tespit edilir. Duplicate ID kritik hata olarak işaretlenir. Verification süreci böylece daha otomatik hale gelir.

Duplicate Güncellemesini Önleme

Aynı URL dosyada yanlışlıkla iki kez bulunabilir. Unique ID count kontrolü bunu yakalar. CMS aynı kayda iki farklı metadata değeri almamalıdır. Batch import öncesi duplicate key gate kullanılmalıdır. Bu basit kontrol yanlış overwrite riskini azaltır.

Formül Sütunu ile Final Sütunu Neden Ayrılmalı?

Generated output ve final output aynı hücrede tutulduğunda manuel düzenleme ile otomasyon birbirine karışır. Formül değiştirildiğinde elle yapılan değer kaybolabilir. Ayrı final sütunu ise source of truth kararını açık hale getirir. Human override değerli sayfalarda korunurken long-tail kayıtlar generated output kullanabilir. Bu yapı ekip içinde güvenli hibrit model sağlar.

Generated Output

Generated output sistemin önerisidir. Formula veya AI tarafından üretilebilir. İnsan bunu değiştirirse sistem davranışı izlenemez hale gelir. Bu yüzden generated kolon protected tutulmalıdır. Formula version metadata'sı da aynı satırda saklanabilir.

Human Override

Override kullanıcının generated değerin yerine bilinçli olarak seçtiği metindir. Bu alanın boş olması generated output'u kabul ettiği anlamına gelebilir. Override reason eklemek sonradan analiz için faydalıdır. Yüksek override oranı formülün yeterince iyi olmadığını gösterebilir. Dashboard bu metric'i izleyebilir.

Final Output

Final output basit seçim mantığıyla generated veya override değerini alır. CMS'e yalnızca final alan gönderilir. QA tekrar final output üzerinde çalışmalıdır. Çünkü insan override değeri uzun veya duplicate olabilir. Final value immutable olmak zorunda değildir ancak değişiklik history'si tutulabilir.

Formula Değiştiğinde Manuel Editi Korumak

Formula revision generated value'yu değiştirir. Override ayrı sütundaysa insan düzenlemesi aynı kalır. Bu durum özellikle aylardır optimize edilmiş landing page'lerde kritiktir. Yeni formül yalnızca override olmayan satırlarda etkili olabilir. Formula migration raporu hangi kayıtların değişeceğini önceden gösterebilir.

Formula vs Human Karar Önceliği

Öncelik kuralı açık ve tek olmalıdır. Genellikle override doluysa insan, boşsa formula tercih edilir. Bazı sayfa tiplerinde tamamen human-only policy uygulanabilir. Priority flag bunu yönetebilir. Final formül farklı istisnaları tek noktada kontrol eder.

Manuel Override Modeli Nasıl Kurulur?

Manuel override modeli otomasyon ile uzman kontrolünü birlikte kullanmanın en pratik yollarından biridir. Generated sütun formülü korur, override sütun insan düzenlemesini saklar ve final sütun karar mantığını uygular. Böylece SEO uzmanı sadece gerekli satırlara müdahale eder. Formül geri kalan binlerce satırı otomatik yönetir. Override rate zaman içinde ölçülerek şablonun kalitesi de analiz edilebilir.

Generated Meta

Generated meta otomatik draft'tır. Source alanlardan deterministic biçimde oluşabilir. İnsan bu hücreye yazmamalıdır. Protected column kullanmak faydalıdır. Formula version ile birlikte izlenebilir.

Override Meta

Override meta yalnızca manual edit gerektiğinde doldurulur. Boşluk gerçekten boş kabul edilmelidir. Yanlışlıkla tek space girilmesi final mantığını bozabilir. TRIM kullanılarak boşluk kontrolü yapılabilir. Editor ve edit date audit alanları eklenebilir.

Final Meta

Final meta override ve generated arasındaki seçimdir. Basit IF formülü kullanılabilir. Final hücre manual edit edilmemelidir. Export tab bu değeri alır. QA final değer üzerinde son kez çalışır.

Override Boşsa Formül Çıktısını Kullan

Bu en yaygın default davranıştır. Override gerçekten empty veya TRIM sonrası boşsa generated value seçilir. Generated da boşsa QA Missing olarak işaretler. Fallback logic final içinde saklanmamalı, generated katmanda çözülmelidir. Böylece final seçim mantığı sade kalır.

Override Doluysa İnsan Çıktısını Koru

İnsan düzenlemesi formül değişikliğinden etkilenmemelidir. Override dolu olduğunda final doğrudan bu değeri kullanır. Formula update impact raporunda bu satırlar "protected" görülebilir. Yine de duplicate ve length QA devam etmelidir. İnsan edit'i kalite kontrolünden muaf değildir.

Google Sheets’te Satır Bazlı Formül Yaklaşımları

Google Sheets satır bazlı metadata üretimi için birkaç farklı formül yaklaşımı sunar. Klasik hücre formülü kolay öğrenilir, ARRAYFORMULA bütün sütunu tek formülle doldurur, MAP ve BYROW ise daha açık row-level logic sağlar. Named Functions tekrar kullanılan mantığı ekip içinde sadeleştirir. Seçim veri hacmi ve formül karmaşıklığına göre yapılmalıdır. Tek bir yaklaşımı her problemde kullanmak yerine formül okunabilirliği ve bakım kolaylığı önceliklendirilmelidir.

Klasik Hücre Formülü

Klasik formül her satır hücresine ayrı yazılır veya fill down ile kopyalanır. Öğrenmesi kolaydır. Satır bazında debug yapmak rahattır. Ancak yeni satır eklendiğinde formula kopyalanmayabilir. Büyük tablolarda version consistency problemi oluşabilir.

Fill Down

Fill down ilk satırdaki formülü aşağı doğru çoğaltır. Küçük ve orta tabloda pratiktir. Formül yanlışlıkla bazı satırlarda değişebilir. Yeni kayıtlar için tekrar uygulanması gerekir. Formula integrity QA yapılabilir.

ARRAYFORMULA

ARRAYFORMULA tek hücreden bütün range için çıktı üretir. Basit string birleştirme ve IF yapılarında çok kullanışlıdır. Yeni satırlar otomatik kapsanabilir. Karmaşık row-level branching okunabilirliği zorlaştırabilir. Generated column içinde manuel edit yapılamaz.

MAP + LAMBDA

MAP bir veya birden fazla input dizisinin her elemanını bağımsız LAMBDA ile işler. Satır bağımsız metadata için güçlü ve okunabilir yaklaşım sunar. Birden fazla source column aynı row index üzerinden kullanılabilir. Empty row handling açık biçimde yazılabilir. Karmaşık formüllerde ARRAYFORMULA'ya göre daha rahat kontrol sağlar.

BYROW + LAMBDA

BYROW bir satırdaki birden fazla hücreyi birlikte değerlendirir. QA score veya kompleks validation için uygundur. Tek satırı array olarak LAMBDA'ya verir. Column selection CHOOSECOLS gibi fonksiyonlarla yapılabilir. Metadata üretiminde source fields çok olduğunda faydalı olabilir.

Named Functions

Named Functions uzun formülü tekrar yazmadan anlamlı isimle kullanmayı sağlar. Örneğin META_TITLE_PRODUCT gibi function tanımlanabilir. Ekip üyeleri karmaşık iç mantığı görmeden fonksiyonu kullanabilir. Version ve documentation yönetimi önemlidir. Test cases fonksiyon güncellemesinden sonra tekrar çalıştırılmalıdır.

Hangi Yaklaşım Ne Zaman Kullanılmalı?

Küçük tabloda klasik formül yeterlidir. Basit sütun üretiminde ARRAYFORMULA güçlüdür. Birden fazla source field ve koşul olduğunda MAP + LAMBDA daha okunabilir olabilir. Satırın tamamını kontrol eden QA işlemlerinde BYROW uygundur. Çok tekrar eden logic Named Function'a taşınabilir.

ARRAYFORMULA ile Toplu Metadata

ARRAYFORMULA özellikle basit metadata şablonlarını tek bir formülle bütün sütuna yaymak için güçlü yöntemdir. Yeni satır eklendiğinde formül aralığı uygun tanımlandıysa sonuç otomatik oluşur. Boş satırları IF kontrolüyle atlamak gereksiz çıktı üretimini önler. Çok karmaşık koşullarda okunabilirlik hızla düşebilir. Bu nedenle array formülü küçük helper kolonlarla desteklemek çoğu zaman daha sağlıklıdır.

Tek Formül ile Tüm Sütunu Doldurmak

Generated title sütununun ilk hücresine tek ARRAYFORMULA yazılabilir. Alt hücreler sistem tarafından doldurulur. Kullanıcı bu hücrelere manuel değer girmemelidir. Header row dikkatle hariç tutulmalıdır. Formül range sınırı performans için optimize edilebilir.

Boş Satırları Atlamak

Source ID veya URL boşsa output da boş kalmalıdır. Bu kontrol gereksiz title üretimini engeller. IF(LEN(ID)=0,"",...) mantığı kullanılabilir. Tek space veya görünmeyen karakter varsa TRIM yardımcı olur. Missing required source ayrıca QA status ile işaretlenebilir.

IF ile Birleştirmek

IF sayfa tipine veya source varlığına göre farklı metin parçaları ekler. Brand boşsa separator ile birlikte brand bölümü atlanabilir. Nested IF çok büyürse IFS veya helper column daha okunabilir olur. Formula complexity bakım maliyetidir. Her condition test dataset'inde denenmelidir.

ARRAYFORMULA’nın Avantajları

Tek source formula version consistency sağlar. Fill-down unutma problemi azalır. Yeni satır otomatik işlenebilir. Formula protected tutulabilir. Simple metadata catalog için hızlı ve yeterli çözümdür.

Karmaşık Row Logic’te Sınırlamaları

Çok sayıda farklı column condition tek array formülünü okunmaz hale getirebilir. Debug sırasında hangi satırda hangi branch çalıştı anlamak zorlaşır. MAP veya helper columns daha temiz yapı sunabilir. Çok ağır regex ve full-column ranges performansı etkileyebilir. Formula seçiminde sadece kısa yazmak değil bakım kolaylığı önemlidir.

MAP + LAMBDA ile Satır Bağımsız Metadata

MAP + LAMBDA, Google Sheets içinde gerçekten satır seviyesinde düşünmek isteyen ekipler için güçlü seçenektir. Birden fazla source sütunu paralel olarak alır ve her kayıt için bağımsız hesaplama yapar. Boş kayıt ve fallback logic formül içinde açık biçimde tanımlanabilir. Reusable logic için Named Functions ile birlikte kullanılabilir. Karmaşık katalog şablonlarında okunabilirliği artırması büyük avantajdır.

Bir veya Birden Fazla Kaynak Sütunu Kullanmak

MAP keyword, product, category ve brand dizilerini aynı anda alabilir. LAMBDA her iteration'da o satırın değerlerini kullanır. Böylece satır numarasına manuel referans gerekmez. Source range uzunlukları uyumlu olmalıdır. Required field kontrolleri function başında yapılabilir.

Her Kaydı Ayrı Hesaplamak

MAP her satırı küçük function invocation gibi işler. Bir satırdaki empty value diğer kaydı etkilemez. Hata durumunda IFERROR row-level fallback sağlayabilir. Bu yapı debugging açısından avantajlıdır. Output array tek sütuna yayılır.

Boş Kayıt Yönetimi

ID veya page type boşsa function boş output döndürebilir. Eksik brand yalnızca brand parçasını atlayabilir. Eksik keyword fallback hierarchy üzerinden çözülebilir. Missing source QA ayrı sütunda hesaplanmalıdır. Production metadata sessizce yanlış üretilmemelidir.

Reusable Logic

LAMBDA logic named function içine taşınabilir. Aynı title rule farklı sheet'lerde kullanılabilir. Function parameters source columns olur. Config değerleri named range üzerinden alınabilir. Değişiklik sonrası regression dataset ile kontrol yapılmalıdır.

ARRAYFORMULA’ya Göre Avantajları

MAP karmaşık row logic'i daha doğal ifade eder. Birden fazla input column kullanımı açıktır. Nested array behavior azalır. LAMBDA variable isimleri readability sağlar. Ancak çok büyük sheet'lerde hesaplama maliyeti yine izlenmelidir.

BYROW + LAMBDA Ne Zaman Kullanılmalı?

BYROW bir satır içindeki birden fazla alanın birlikte değerlendirilmesi gereken durumlarda öne çıkar. Metadata generation kadar QA ve scoring işlemlerinde de kullanışlıdır. Satır array olarak function'a verilir ve belirli kolondaki değerler seçilebilir. Özellikle row-level completeness veya quality score hesaplarında sade yapı sunar. Çok geniş tabloda kolon indekslerinin değişmesini önlemek için Named Range veya sabit schema kullanmak gerekir.

Bir Satırdaki Birden Fazla Alanı Birlikte İşlemek

Title, description, keyword ve page type aynı row function içinde değerlendirilebilir. CHOOSECOLS ile gerekli değerler alınabilir. Row array'in column order'ı schema değiştiğinde etkilenebilir. Bu nedenle index mapping document edilmelidir. Çok karmaşık mantık named function'a taşınabilir.

Satır Bazlı Kalite Kontrolü

Bir satırdaki final title boşsa Missing status üretilebilir. Keyword varlığı ve length aynı function içinde kontrol edilebilir. Duplicate gibi site-wide kontroller ayrı sütunda kalmalıdır. Row-level QA ile global QA ayrımı önemlidir. Son overall status bu sinyalleri birleştirebilir.

Row-Level Score Hesabı

Her kalite kuralı belirli puan verebilir. Title dolu, keyword mevcut ve length uygun olduğunda score artar. Duplicate penalty ayrıca eklenebilir. Score tek başına approval yerine geçmemelidir. İnsan review threshold üzerinden yönlendirilebilir.

Kompleks Validation

Page type'a göre farklı required fields kontrol edilebilir. Product page için product name zorunlu, location page için lokasyon zorunlu olabilir. BYROW bu conditional schema'yı tek satırda değerlendirebilir. Error message tek status yerine detaylı issue listesi döndürebilir. Validation logic config tab üzerinden yönetilirse formül daha sade kalır.

Excel’de Satır Bağımsız Metadata Düzenleme

Excel Table yapısı satır bağımsız metadata düzenleme için güçlü bir model sunar. Structured references sayesinde formüller A2 veya B2 gibi kırılgan hücre adresleri yerine kolon isimleriyle yazılabilir. Yeni kayıt eklenince calculated column formülü otomatik uygulanır. Bu yapı büyük kataloglarda formül tutarlılığını artırır. Excel formülleriyle toplu meta title ve description düzenleme nasıl yapılır sorusunun en güvenilir cevaplarından biri, veriyi normal range yerine Table formatında yönetmektir.

Excel Table

Excel Table dataset'i structured object haline getirir. Header isimleri formüllerde kullanılabilir. Filter ve new row behavior daha güvenilirdir. Calculated columns otomatik genişler. Import-ready data için ayrı table oluşturulabilir.

Calculated Columns

Bir column içine formula yazıldığında Excel aynı formülü bütün tablo satırlarına uygulayabilir. Yeni row da otomatik formül alır. Manuel değişiklik calculated column consistency'yi bozabilir. Generated fields protected tutulmalıdır. Override fields ayrı normal column olarak kullanılmalıdır.

Structured References

Structured reference kolon adlarını formülde kullanır. Bu yaklaşım okunabilirliği artırır. Column insert durumunda hücre adreslerine göre daha dayanıklıdır. Örneğin current row Brand alanı doğrudan isimle referans edilebilir. Schema isimleri standart tutulmalıdır.

Current Row Referansı

Current row notation her formülün aynı satırdaki değeri kullanmasını sağlar. Bu gerçek row-level logic oluşturur. Sort sonrası association korunur. Formula debugging kolaylaşır. Unique ID yine kayıt seviyesinde güvence sağlar.

Yeni Satır Eklenince Formülün Otomatik Uygulanması

Excel Table yeni kayıt eklendiğinde calculated formula'yı kopyalar. Fill down unutma problemi azalır. Source import sonrası yeni rows hızlı işlenir. Formula version bütün kolon için tutarlı kalır. Büyük catalog management açısından ciddi operasyon avantajıdır.

Google Sheets ve Excel Yaklaşımlarının Karşılaştırılması

Google Sheets ve Excel aynı metadata problemini farklı araçlarla çözebilir. Sheets işbirliği ve web tabanlı otomasyon avantajına sahipken Excel Table ve structured references güçlü row-level formül modeli sunar. Çok büyük veri setlerinde iki platformun da sınırları vardır. API ve script entegrasyonu seçimde önemli olabilir. Ekip mevcut çalışma alışkanlıklarını ve veri hacmini birlikte değerlendirmelidir.

ARRAYFORMULA

Google Sheets'e özgü güçlü array yaklaşımıdır. Basit column generation için uygundur. Tek formula source consistency sağlar. Manual edit generated column'da yapılamaz. Karmaşık logic MAP ile daha okunabilir olabilir.

MAP / BYROW

Modern Sheets fonksiyonları row-level functional logic sunar. Birden fazla input column rahat kullanılır. Validation ve metadata generation için uygundur. Eski sheet alışkanlıklarına göre öğrenme eğrisi olabilir. Reusable logic LAMBDA ve Named Functions ile güçlenir.

Excel Structured References

Excel Table içinde column names üzerinden çalışır. Row relation güvenilir biçimde korunur. Calculated column otomatik genişler. Büyük kurumsal dosyalarda oldukça pratiktir. Power Query veya VBA süreçleriyle de birleştirilebilir.

İşbirliği

Google Sheets real-time collaboration açısından güçlüdür. Excel web sürümü de ortak çalışmayı destekler. Approval ve protected ranges her iki platformda farklı şekilde yapılandırılabilir. Büyük ekipte edit permission önemli konudur. Workflow status bağımsız veri alanı olarak tutulmalıdır.

Büyük Veri Setleri

On binlerce satır ve ağır formüller iki platformda da yavaşlayabilir. Full-column regex ve volatile formulas kaçınılmalıdır. Helper table ve batch processing performansı artırır. Çok büyük veri setinde Python veya SQL daha doğru olabilir. Spreadsheet sonsuz ölçekli veri motoru değildir.

API ve Script Entegrasyonu

Google Sheets Apps Script ve Sheets API ile kolay entegre olur. Excel Office Scripts ve diğer entegrasyon seçeneklerine sahiptir. CMS API sync ihtiyacı script kullanımını değerli hale getirir. Rate limit ve error handling formülden farklı mühendislik gerektirir. Audit log ihtiyacı arttığında script katmanı daha önemlidir.

Meta Title Formülü Nasıl Tasarlanır?

Meta title formülü birleştirilecek alanların sırasını ve fallback mantığını açıkça tanımlamalıdır. Ana keyword veya ürün adı başlangıçta yer alabilir, kategori ve marka gerektiğinde eklenebilir. Separator koşullu alanlarla birlikte yönetilmelidir. Character length QA ayrıca çalışmalıdır. Title formülü çok fazla parçayı zorla birleştirmek yerine sayfa tipine göre sade template kullanmalıdır.

Ana Keyword

Primary keyword title için güçlü başlangıç kaynağıdır. Her sayfada bulunmayabilir. Boşsa product name veya category fallback olabilir. Keyword'in doğal olmayan tekrarından kaçınılmalıdır. QA keyword presence sadece ilgili sayfa tiplerinde uygulanmalıdır.

Ürün/Hizmet Adı

Product veya service name kullanıcı açısından en açıklayıcı öğelerden biridir. Title'ın başında yer alabilir. Çok uzun isimler kısaltma ihtiyacı doğurabilir. Otomatik truncation kelimeyi ortadan kesmemelidir. Short name source alanı daha güvenli olabilir.

Kategori

Category kullanıcıya ürün bağlamı sağlar. Her title'a eklenmesi gerekmez. Product name zaten category bilgisini içeriyorsa duplicate ifade oluşabilir. Conditional formula bunu kontrol edebilir. Category template sayfa tipine göre farklı davranmalıdır.

Lokasyon

Location local search intent bulunan service page'lerde değerlidir. Şehir ve ilçe birlikte kullanılacaksa length kontrol edilmelidir. Location boşsa ayraç da atlanmalıdır. Generic product page'e gereksiz lokasyon eklenmemelidir. Page type bu kararı yönlendirmelidir.

Marka

Brand title sonunda separator ile kullanılabilir. Marka zaten product name içinde geçiyorsa tekrar edilmemesi düşünülebilir. Site-wide standard config üzerinden yönetilebilir. Rebrand durumunda tek config değeri güncellenebilir. Brand requirement high-value pages için manuel kontrol edilebilir.

Separator

Separator pipe, tire veya başka kısa ayırıcı olabilir. Aynı site içinde tutarlı kullanmak okunabilirlik sağlar. Empty field olduğunda separator yalnız kalmamalıdır. TEXTJOIN boş değerleri atlamak için yararlıdır. Config tab separator değişimini merkezi hale getirir.

Karakter Kontrolü

LEN formülü title karakter sayısını verir. Minimum ve maksimum threshold QA için kullanılabilir. Search result görünümü yalnızca karakter sayısına bağlı değildir. Pixel width ve query context sonucu etkileyebilir. Bu nedenle length check warning sistemi olarak görülmelidir.

Örnek Meta Title Şablon Mantıkları

Sayfa tipine göre farklı title template kullanmak benzersizlik ve relevancy açısından daha sağlıklıdır. Product, service, category ve blog sayfalarının arama niyetleri aynı değildir. Programmatic SEO sayfalarında keyword ve lokasyon kombinasyonu güçlü olabilir. Template'ler config tab içinde saklanabilir. QA ve A/B benzeri SEO performans izlemesiyle zaman içinde güncellenebilir.

Ürün Sayfası

Ürün title'ında product name en güçlü öğedir. Category ve marka ihtiyaç halinde eklenebilir. Varyant bilgisi kullanıcı aramasında anlamlıysa source olarak kullanılabilir. SKU gibi kullanıcıya fayda sağlamayan değerler çoğu title'da gereksizdir. Duplicate product names için category veya distinguishing attribute yardımcı olur.

Ürün + Kategori + Marka

Bu template büyük kataloglarda iyi başlangıçtır. Ürün adını ilk sırada tutar. Category bağlam ve brand güven sinyali ekler. Empty category durumunda separator atlanmalıdır. Length limit aşılıyorsa category veya brand öncelik sırasıyla düşürülebilir.

Hizmet Sayfası

Hizmet sayfasında service name ve location çoğu local intent için değerlidir. Marka son bölümde kullanılabilir. Şehir ve ilçe aynı anda gereksiz uzunluk yaratabilir. Hedef query yapısına göre location granularity seçilmelidir. High-value service pages manual override için güçlü adaydır.

Hizmet + Lokasyon + Marka

Bu yapı local service sayfalarında açıklayıcı title üretir. Location yoksa sadece service ve brand kullanılabilir. Aynı service farklı lokasyonlarda unique olur. Spam benzeri tekrar eden şehir listelerinden kaçınılmalıdır. Programmatic page kalitesi yalnız title template'e bağlı değildir.

Kategori Sayfası

Kategori sayfası birden fazla ürünü veya hizmeti toplar. Title kategori adını merkeze almalıdır. Değer önerisi search intent'e göre eklenebilir. Marka sonunda yer alabilir. Çok generic category names secondary keyword ile zenginleştirilebilir.

Kategori + Değer Önerisi + Marka

Değer önerisi kısa ve doğrulanabilir olmalıdır. Kaynakta olmayan "en ucuz" veya "en iyi" gibi ifadeler otomatik eklenmemelidir. Category ve brand deterministic source'dan gelir. Value proposition config veya approved copy alanında tutulabilir. Böylece formula yanlış iddia üretmez.

Blog

Blog title'ları katalog sayfalarına göre daha editorial olabilir. Ana konu ve search intent birlikte kullanılabilir. Marka her blog title'ında zorunlu değildir. Headline CTR ve content quality ile birlikte düşünülmelidir. Blog sayfaları tam otomasyon yerine yarı otomatik modele daha uygundur.

Konu + Arama Niyeti + Marka

Konu primary source olarak kullanılır. Intent "rehber", "nasıl yapılır" veya "karşılaştırma" gibi approved format olabilir. Brand yalnızca gerekiyorsa eklenir. Formula title üretse bile editorial review faydalıdır. Duplicate blog title ayrı QA ile kontrol edilmelidir.

Programmatic SEO

Programmatic SEO çok sayıda structured landing page üretir. Metadata template'i sayfa kalitesi problemini tek başına çözmez. Keyword, location ve property combination doğal olmalıdır. Thin content riski ayrıca yönetilmelidir. Formula QA binlerce URL'nin tutarlılığını korumada güçlü araçtır.

Keyword + Lokasyon + Nitelik

Bu template long-tail local query'ler için kullanılabilir. Nitelik source veride doğrulanabilir olmalıdır. Aynı combination duplicate çıkarsa unique differentiator gerekebilir. Location normalization önemlidir. Character limit nedeniyle field priority açık tanımlanmalıdır.

Meta Description Formülü Nasıl Tasarlanır?

Meta description formülü title'a göre daha doğal cümle yapısı gerektirir. Ana konu, farklılaştırıcı özellik, fayda, marka ve CTA gerektiğinde birleştirilebilir. Her alan zorunlu tutulmamalıdır. Boş değerler sessizce atlanmalı ve cümle bozulmamalıdır. Google Sheets ile SEO meta verileri toplu nasıl oluşturulur sorusunda description üretimi için TEXTJOIN ve koşullu alan mantığı oldukça kullanışlıdır.

Ana Konu

Description kullanıcıya sayfanın ne hakkında olduğunu hızlıca anlatmalıdır. Product veya service name başlangıç kaynağı olabilir. Ana keyword doğal biçimde yer alabilir. Keyword stuffing yapılmamalıdır. Description sayfa içeriğiyle gerçek uyum göstermelidir.

Farklılaştırıcı Özellik

Farklılaştırıcı özellik source veride bulunmalıdır. Stok durumu, kategori niteliği veya hizmet avantajı kullanılabilir. Uydurma claim oluşturulmamalıdır. Empty value varsa formül bu bölümü atlamalıdır. Approved attribute listesi config tab içinde tutulabilir.

Kullanıcı Faydası

Benefit copy kullanıcıya sayfanın neden değerli olduğunu anlatır. Her ürün için generic aynı faydayı kullanmak duplicate yaratabilir. Category-level value proposition reusable olabilir. High-value page'lerde human-written benefit daha iyi olabilir. AI kullanılacaksa source constraint uygulanmalıdır.

Marka

Brand description içinde zorunlu değildir. Site amacı ve search snippet stratejisine göre eklenebilir. Marka adı title'da zaten bulunuyorsa description alanı başka bilgiyi öne çıkarabilir. Config üzerinden conditional yapılabilir. Rebrand durumunda merkezi güncelleme avantaj sağlar.

CTA

CTA "inceleyin", "detayları keşfedin" gibi kısa ve dürüst ifade olabilir. Her description'a aynı CTA eklemek template duplicate oranını artırabilir. Sayfa tipine göre farklı CTA setleri kullanılabilir. Kullanıcıdan yapılamayacak bir aksiyon istememelidir. CTA final cümlenin doğallığını bozmamalıdır.

Karakter Uzunluğu

Description length LEN ile takip edilir. Çok kısa açıklama yetersiz bilgi verebilir. Çok uzun metin search result'ta kesilebilir. Ancak tek kalite metriği karakter sayısı değildir. QA status yalnız review ihtiyacını işaretlemelidir.

Meta Description’da Koşullu Alan Kullanımı

Koşullu alanlar description formülünü daha dayanıklı hale getirir. Brand, price veya location yalnızca gerçekten mevcutsa eklenir. Empty values nedeniyle yarım cümle veya iki separator oluşması engellenir. TEXTJOIN özellikle boş değerleri otomatik atlamak için yararlıdır. Source quality zayıfsa output üretmek yerine QA warning daha doğru olabilir.

Marka Varsa Ekle

IF(LEN(brand)>0,...) mantığı kullanılabilir. Marka yoksa cümle doğal biçimde devam etmelidir. Separator veya preposition brand ile birlikte condition içine alınmalıdır. Böylece dangling punctuation oluşmaz. Config-level brand daha güvenilir source olabilir.

Fiyat Varsa Ekle

Price metadata içine yalnızca güncel ve güvenilir source varsa eklenmelidir. Sık değişen fiyatlar stale description riski taşır. Currency formatting doğru yapılmalıdır. Kampanya fiyatı expiration yönetimi gerektirir. Genel durumda fiyatı description'a koymamak daha güvenli olabilir.

Lokasyon Varsa Ekle

Local service description'da location güçlü bağlam sağlar. Location missing olduğunda sentence structure bozulmamalıdır. Şehir ve ilçe önceliği tanımlanabilir. Location normalize edilmiş source'dan gelmelidir. Aynı description'ın şehir dışında tamamen duplicate olması önlenebilir.

Avantaj Varsa Ekle

Benefit field yalnızca doğrulanmış veri taşımalıdır. Empty ise formula default marketing claim uydurmamalıdır. Category-level benefit safe fallback olabilir. Human-approved copy listesi kullanılabilir. QA source missing status üretebilir.

Boş Alanları Sessizce Atla

TEXTJOIN ignore_empty seçeneği bu iş için kullanışlıdır. Ancak sentence grammar her combination için test edilmelidir. Bir alanın yokluğu iki farklı cümleyi birleştirebilir. Sample dataset tüm boşluk kombinasyonlarını içermelidir. Regression test yeni formula version'ını korur.

Boş Alanlar Formülü Nasıl Bozar?

Metadata formüllerindeki hataların önemli kısmı empty source values nedeniyle ortaya çıkar. Marka veya kategori eksikken separator kalabilir, iki boşluk oluşabilir veya tamamen anlamsız title çıkabilir. Bu nedenle source completeness ve fallback mantığı formülün ayrılmaz parçasıdır. Required ve optional fields birbirinden ayrılmalıdır. Missing critical source varsa output yerine review status üretmek daha güvenlidir.

Eksik Marka

Brand optional ise title onsuz çalışabilmelidir. Separator brand condition içinde tutulmalıdır. Brand required sayfa tipinde QA failure üretilebilir. Default brand config'ten gelebilir. Yanlış marka uydurulmamalıdır.

Eksik Kategori

Product title category olmadan da anlamlı olabilir. Ancak programmatic category template için category required olabilir. Page type'a göre requirement değişmelidir. Fallback olarak parent category kullanılabilir. Missing source status görünür olmalıdır.

Eksik Keyword

Primary keyword boşsa secondary keyword kullanılabilir. O da boşsa product name veya page title fallback olabilir. Her sayfada keyword source zorunlu değildir. Safe hierarchy config'te document edilmelidir. QA missing keyword ile missing output'u ayırmalıdır.

Fazladan Ayraç

String concatenation boş field durumunda "| |" benzeri çıktı üretebilir. TEXTJOIN veya conditional separator bu sorunu çözer. Regex cleanup son savunma olarak kullanılabilir. Ancak yanlış formülü regex ile gizlemek iyi tasarım değildir. İlk üretim mantığı doğru kurulmalıdır.

Çift Boşluk

Boş parçaların birleştirilmesi iki veya daha fazla space oluşturabilir. TRIM çoğu normal space'i temizler. Non-breaking space için CLEAN veya SUBSTITUTE gerekebilir. Final normalization helper column kullanılabilir. QA normalized output üzerinde çalışmalıdır.

Fallback Kuralları

Fallback hierarchy açık sıralı olmalıdır. Primary keyword, secondary keyword, product name, category ve page title gibi kaynaklar kullanılabilir. Safe default yalnızca gerçekten genel kullanıma uygunsa eklenmelidir. Fallback usage rate dashboard'da izlenebilir. Yüksek oran source data kalitesi sorununu gösterebilir.

Metadata Fallback Hiyerarşisi

Fallback hiyerarşisi kaynak alan eksik olduğunda metadata üretiminin nasıl devam edeceğini belirler. Bu mantık formül içine dağınık şekilde gömülmemeli, mümkünse helper column veya Named Function içinde merkezi tutulmalıdır. Öncelik SEO ve kullanıcı anlamına göre verilmelidir. Her fallback kabul edilebilir değildir. Safe default en son seçenek olmalı ve yüksek kullanım oranı kalite problemi olarak görülmelidir.

Primary Keyword

En yüksek öncelikli search target olabilir. Doğal biçimde kullanılmalıdır. Boş veya geçersizse sonraki kaynağa geçilir. Keyword source versionlanabilir. Keyword stuffing kontrolü ayrıca gerekir.

Secondary Keyword

Primary olmadığında geçici fallback sağlayabilir. Secondary aynı search intent'i temsil etmelidir. İlgisiz keyword kullanılmamalıdır. Birden fazla secondary varsa priority açık olmalıdır. Formula ilk geçerli değeri seçebilir.

Product Name

Product name çoğu ürün sayfasında güvenilir fallback'tir. Gerçek source verisidir. Çok uzun isimler title için optimize edilebilir. Normalization markayı yanlışlıkla silmemelidir. Duplicate product names category ile ayrıştırılabilir.

Category

Category ürün adı yoksa sınırlı fallback sağlar. Tek başına product page için çok generic olabilir. Category page'de ana source zaten category'dir. Page type-aware logic gereklidir. Parent category veya breadcrumb data ek bağlam sağlayabilir.

Page Title

Existing H1 veya CMS page title son fallback olabilir. Kalitesi garanti değildir. Import öncesi normalized ve empty check yapılmalıdır. Existing title tamamen metadata'ya kopyalanırsa duplicate riski oluşabilir. QA bu durumu işaretleyebilir.

Safe Default

Safe default marka veya site genel tanımı gibi zararsız kısa metin olabilir. Ancak binlerce sayfada aynı default duplicate yaratabilir. Bu nedenle output üretmemek bazı durumlarda daha doğru olabilir. Default kullanımı manual review status ile işaretlenmelidir. Safe sözcüğü kalite garantisi anlamına gelmez.

IF ve IFS ile Sayfa Tipine Göre Metadata

Farklı sayfa tiplerine tek metadata şablonu uygulamak kaliteyi düşürür. IF veya IFS page type alanına göre template seçebilir. Product, category, service, location, blog ve brand sayfaları farklı source priority kullanabilir. Formula büyüdükçe config mapping veya lookup tablosu daha okunabilir hale gelir. Page type taxonomy stable tutulmalıdır.

Product

Product template product name'i temel alır. Category ve brand optional eklenebilir. Varyant bilgisi gerekiyorsa ayrı source olmalıdır. Missing product name critical QA failure olabilir. Description product benefit ve category context kullanabilir.

Category

Category template kategori adını merkeze alır. Brand veya value proposition eklenebilir. Product-specific field kullanılmamalıdır. Duplicate category names hierarchy ile ayrıştırılabilir. Description category assortment veya benefit bilgisinden üretilebilir.

Service

Service template hizmet adı ve gerekiyorsa lokasyon içerir. Trust veya benefit source alanı description için kullanılabilir. Hizmet adı missing ise output üretmemek daha güvenlidir. Local intent ile generic service ayrımı önemlidir. Page type alt kategorisi kullanılabilir.

Location

Location page keyword ve city combination kullanabilir. Şehir tek başına title üretmek için yeterli değildir. Service veya category context gerekir. Duplicate city pages quality açısından ayrıca değerlendirilmelidir. Formula only metadata thin page sorununu çözmez.

Blog

Blog title content headline veya topic source'dan gelebilir. Formula daha hafif kullanılmalıdır. Editorial pages manual override oranı yüksek olabilir. Description summary source'dan üretilebilir. Keyword zorunlu olmamalıdır.

Brand

Brand landing page brand name ve category context kullanabilir. Aynı marka farklı category'de varsa combination gerekli olabilir. Site brand ile product brand karıştırılmamalıdır. Template source schema bunu ayırmalıdır. Duplicate check normalized values üzerinde yapılmalıdır.

Farklı Şablonların Tek Formülde Yönetilmesi

IFS küçük sayıdaki page type için yeterlidir. Çok sayıda template olduğunda lookup table daha sürdürülebilir olabilir. Config tab page type, template code ve limits saklayabilir. Formula Named Function üzerinden template seçebilir. Böylece yeni sayfa tipi eklemek bütün formülü yeniden yazmayı gerektirmez.

REGEX ile Metadata Temizliği

REGEX formülleri metadata temizliğinde güçlüdür ancak üretim hatalarını gizleyen genel bir bant olarak kullanılmamalıdır. Gereksiz karakter, eski marka ifadesi veya URL'den kategori çıkarma gibi kontrollü dönüşümlerde değerlidir. Regex pattern test dataset üzerinde denenmelidir. Türkçe karakter ve Unicode davranışı göz önüne alınmalıdır. Çok ağır regex büyük tabloda performans maliyeti oluşturabilir.

Gereksiz Karakterleri Silme

Kaynak veride yıldız, özel sembol veya kontrol karakteri bulunabilir. REGEXREPLACE belirli pattern'leri kaldırabilir. Her punctuation silinmemelidir. Ürün kodlarında sembol anlamlı olabilir. Field-specific temizleme kuralı daha güvenlidir.

Çift Boşlukları Temizleme

Regex birden fazla whitespace'i tek space'e çevirebilir. TRIM ile birlikte kullanılabilir. Non-breaking space ayrıca kontrol edilmelidir. Final output normalize helper column'dan geçebilir. Original source korunmalıdır.

Eski Marka İfadelerini Değiştirme

Rebrand durumunda eski ifade yeni değerle değiştirilebilir. Pattern tam eşleşme veya boundary kullanmalıdır. Ürün isminde tesadüfi aynı kelime varsa yanlış replacement olabilir. Config-driven mapping daha güvenlidir. Değişen satırlar diff column ile review edilmelidir.

Tarih/Yıl Temizliği

Eski title içinde geçmiş yıl bulunuyorsa regex ile kaldırılabilir. Ancak ürün model yılı gerçekten önemli olabilir. Generic numeric pattern risklidir. Page type ve source field context kullanılmalıdır. Current year otomatik eklemek her SEO sayfası için gerekli değildir.

Separator Standardizasyonu

Farklı pipe ve tire kullanımları normalize edilebilir. Double separator temizlenebilir. Separator config'ten üretiliyorsa cleanup ihtiyacı azalır. Regex last-stage QA helper olarak kullanılabilir. Readability korunmalıdır.

URL’den Kategori Çıkarma

URL path belirli yapıdaysa regex segment çıkarabilir. Source category yoksa geçici enrichment sağlar. URL yapısı değişirse logic kırılabilir. Bu nedenle gerçek category field varsa onu tercih etmek daha güvenlidir. Regex extraction QA ile karşılaştırılmalıdır.

TRIM, CLEAN ve SUBSTITUTE Kullanımı

Basit metin normalizasyonunda TRIM, CLEAN ve SUBSTITUTE çoğu sorunu REGEX'ten daha okunabilir biçimde çözer. Imported CSV veya kopyalanan veriler görünmeyen karakterler taşıyabilir. Normalization layer bu problemleri source'a dokunmadan temizler. Formül üretimi normalized alanlardan beslenebilir. Import öncesi final values üzerinde son kez normalizasyon yapmak faydalıdır.

Fazla Boşluk

TRIM başlangıç ve sondaki boşlukları kaldırır. Birden fazla normal space'i de azaltabilir. Empty check daha güvenilir hale gelir. Override sütununda sadece space bulunan hücre gerçek override kabul edilmez. Normalization standard her text field'a uygulanabilir.

Görünmeyen Karakter

CLEAN bazı kontrol karakterlerini kaldırır. Web export'larında non-breaking space ayrıca görülebilir. SUBSTITUTE özel karakteri normal space ile değiştirebilir. Duplicate check öncesi bu temizlik önemlidir. Aksi halde görsel olarak aynı title teknik olarak farklı görünebilir.

Eski Metin Kalıpları

SUBSTITUTE belirli eski phrase'i yeni phrase ile değiştirmek için uygundur. Rebrand veya format update işlemlerinde kullanılabilir. Case sensitivity davranışı bilinmelidir. Çok genel replacement yanlış değişiklik yapabilir. Diff QA mutlaka uygulanmalıdır.

Import Öncesi Normalizasyon

Final output export tab'a alınmadan önce temizlenmelidir. Fazla space, line break ve control character kaldırılabilir. Formula output values'e çevrilmelidir. UTF-8 export kontrol edilmelidir. Small batch test gerçek CMS davranışını doğrular.

Türkçe Karakterlerde Normalizasyon

Türkçe metinlerde büyük-küçük harf dönüşümü bazı dillerden farklı davranabilir. İ, I, ı ve i karakterleri duplicate veya slug işlemlerinde özel dikkat gerektirir. Metadata görünür alanlarında Türkçe karakterleri korumak genellikle doğru yaklaşımdır. Normalize helper yalnızca karşılaştırma ve technical matching amacıyla ayrı tutulabilir. Display text'i ASCII'ye dönüştürmek gereksiz kalite kaybı yaratabilir.

İ / I

Türkçe büyük İ ile Latin I farklı karakterlerdir. LOWER ve UPPER davranışı locale ayarından etkilenebilir. Duplicate normalization için explicit mapping gerekebilir. Görünür title orijinal doğru yazımı korumalıdır. Comparison key ayrı helper column olabilir.

ı / i

Dotless ı ve dotted i özellikle case-insensitive matching'de sorun yaratabilir. Search veya COUNTIF davranışı test edilmelidir. Normalized key için deliberate mapping yapılabilir. Display metadata değiştirilmemelidir. Locale-aware fonksiyon kullanımı önemlidir.

Ş / ş

Ş karakteri slug generation sırasında s'ye dönüştürülebilir. Metadata title içinde korunmalıdır. Duplicate key üretirken same-case normalization yeterli olabilir. Encoding UTF-8 olarak tutulmalıdır. CSV import sonrası bozuk karakter kontrolü yapılmalıdır.

Ç / ç

Ç visible metadata içinde doğal biçimde korunur. URL slug ayrı normalization kuralı kullanabilir. Encoding problemi import sırasında "?" gibi bozulma yaratabilir. Sample verification Türkçe karakterli kayıtları içermelidir. Regression dataset'te özel karakter case'leri bulunmalıdır.

Büyük/Küçük Harf Dönüşümleri

Title Case Türkçe için otomatik uygulandığında yanlış sonuç üretebilir. Her kelimeyi büyütmek marka ve ürün isimlerini bozabilir. Source capitalization korunabilir. Normalize duplicate key lower-case olabilir. Display ve comparison representation ayrımı kritik noktadır.

Duplicate Kontrolüne Etkisi

Görsel olarak aynı title farklı Unicode veya case representation taşıyabilir. Normalized key bu varyasyonları tek değer altında toplar. Trim ve whitespace normalization da eklenmelidir. Duplicate status final display'e değil normalized helper'a dayanabilir. Near-duplicate ayrıca farklı yöntem gerektirir.

Metadata Uzunluğu Nasıl Kontrol Edilir?

Metadata uzunluğu basit QA sinyallerinden biridir. LEN karakter sayısını verir ve threshold üzerinden status üretilebilir. Ancak arama sonucu gösterimi piksel genişliği, sorgu ve arama motoru davranışına göre değişebilir. Bu nedenle karakter sınırı kesin SEO kuralı gibi ele alınmamalıdır. En sağlıklı kullanım, aşırı kısa veya uzun değerleri review kuyruğuna yönlendirmektir.

LEN

LEN hücredeki karakter sayısını hesaplar. Title ve description için ayrı helper column oluşturulabilir. Override sonrası final value üzerinde tekrar hesaplanmalıdır. Empty cell sıfır döner. Dashboard length issue count bu alanlardan beslenebilir.

Minimum Uzunluk

Minimum threshold çok kısa ve yetersiz metadata'yı bulmak için kullanılabilir. Tek bir evrensel sayı yoktur. Page type'a göre threshold değişebilir. Product name kısa olabilir ama yeterli olabilir. Warning insan review için sinyal olmalıdır.

Maksimum Uzunluk

Maximum threshold aşırı uzun title'ları işaretler. Otomatik hard truncation her zaman doğru değildir. Kelimeyi ortadan kesmek kaliteyi düşürür. Field priority ile düşük öncelikli parçalar çıkarılabilir. Still-too-long durumunda review gerekir.

Warning Sütunu

Length warning formula output'u değiştirmeden sorunu bildirir. Bu separation QA tasarımını sadeleştirir. Kısa, normal ve uzun gibi status values kullanılabilir. Filter ile sadece sorunlu rows incelenir. Conditional formatting bu status'a bağlanabilir.

Conditional Formatting

Length issue renklerle görünür yapılabilir. Renk source of truth değildir. Status value her zaman hücrede bulunmalıdır. Export renk bilgisini taşımaz. Accessibility için yalnız renk kullanmamak daha doğrudur.

Karakter Sayısının Tek Başına Kalite Ölçütü Olmaması

İdeal uzunlukta ama alakasız title kötü metadata'dır. Keyword stuffing de length sınırı içinde kalabilir. Duplicate ve source relevance ayrıca kontrol edilmelidir. İnsan review yüksek değerli sayfalarda devam etmelidir. QA score birden fazla sinyali birleştirmelidir.

Meta Title Uzunluk Kontrol Sütunu

Title length status'ını ayrı sütunda tutmak toplu QA'yı kolaylaştırır. Boş, kısa, normal, uzun ve review required gibi sınıflar kullanılabilir. Threshold sayfa tipine göre config'ten gelebilir. Final title değiştiğinde status otomatik güncellenir. Export yalnızca kabul edilen veya onaylanmış statüleri alabilir.

Boş

Final title tamamen empty ise critical issue olarak görülmelidir. Generated ve override kaynakları kontrol edilir. Required source missing olabilir. Export engellenmelidir. Safe fallback yalnızca policy varsa kullanılmalıdır.

Kısa

Kısa title her zaman yanlış değildir. Ancak yeterli context sağlamıyor olabilir. Page type ve product name length dikkate alınmalıdır. QA warning uygulanabilir. High-value page human review'a yönlendirilir.

Normal

Length threshold içinde kalan title Normal olarak işaretlenebilir. Bu status kalite garantisi değildir. Duplicate ve keyword check yine yapılır. Approval ayrı süreçtir. Dashboard pass rate bu kategoriyi kullanabilir.

Uzun

Uzun title review gerektirebilir. Formula priority logic düşük değerli parçaları çıkarabilir. Hard truncate son seçenek olmalıdır. Marka veya category çıkarılması mümkün olabilir. Final karar page context'e göre verilir.

Review Required

Length yanında özel condition'lar review tetikleyebilir. Çok uzun product name veya fallback use buna örnektir. Status issue reason ile birlikte tutulmalıdır. Reviewer override column'a yeni title yazabilir. Final QA yeniden çalışır.

Duplicate Meta Title Nasıl Bulunur?

Duplicate title büyük kataloglarda önemli QA problemlerinden biridir. COUNTIF exact duplicate'ı hızlı bulabilir ancak normalization olmadan bazı varyasyonlar kaçabilir. Case, whitespace ve punctuation normalize edilmelidir. Near-duplicate için token veya similarity tabanlı yöntemler gerekebilir. Duplicate status URL veya page type bağlamıyla birlikte değerlendirilmelidir.

COUNTIF

COUNTIF aynı title'ın kaç kez geçtiğini gösterir. Count birden büyükse duplicate flag üretilebilir. Blank values hariç tutulmalıdır. Final title üzerinde çalışmalıdır. Large range performansı izlenmelidir.

COUNTIFS

COUNTIFS ek koşullarla duplicate kontrolü sağlar. Örneğin aynı title ve aynı language kombinasyonu incelenebilir. Category-level duplicate ayrıca filtrelenebilir. Complex conditions helper columns ile sadeleştirilebilir. Global duplicate yine ayrı kontrol edilmelidir.

Normalize Edilmiş Title

Lowercase, TRIM ve whitespace cleanup uygulanmış helper key oluşturulabilir. Punctuation standardization eklenebilir. Display title değiştirilmez. COUNTIF normalized key üzerinde çalışır. Böylece görsel olarak aynı title varyasyonları yakalanır.

Case-Insensitive Duplicate

Birçok spreadsheet comparison zaten case-insensitive davranabilir. Yine de locale ve Turkish character test edilmelidir. Explicit lowercase key daha kontrollü sonuç sağlar. İ/I dönüşümü ayrıca düşünülmelidir. QA sample gerçek Türkçe title'lar içermelidir.

Exact Duplicate

Exact duplicate final normalized değerlerin tamamen aynı olmasıdır. Birden fazla URL aynı title'ı kullanır. Bu her zaman kritik olmayabilir ancak çoğu programmatic sayfada review gerektirir. Page canonicalization context önemlidir. Intent overlap ayrıca incelenebilir.

Near-Duplicate

Near-duplicate title'lar küçük kelime farkıyla aynı yapıyı taşıyabilir. Basit COUNTIF bunu bulamaz. Token overlap, regex template extraction veya script-based similarity kullanılabilir. Binlerce URL için Python daha uygun olabilir. Near-duplicate sampling manual review ile doğrulanmalıdır.

Duplicate Meta Description Nasıl Bulunur?

Description duplicate kontrolü title'a benzer ancak template kullanımı nedeniyle daha sık tekrar oluşabilir. Tam eşleşme yanında aynı template'in sadece ürün adı değiştirilmiş varyasyonları da değerlendirilmelidir. Category bazlı veya site-wide duplicate oranları dashboard'da izlenebilir. Bazı kataloglarda belirli tekrar seviyesi kaçınılmaz olabilir. Öncelik arama niyeti ve sayfa farklılığını gerçekten yansıtmayan açıklamalara verilmelidir.

Tam Eşleşme

Normalized final description COUNTIF ile kontrol edilebilir. Blank values hariç tutulmalıdır. Exact duplicate hızlı QA sinyalidir. Same canonical group içinde duplicate farklı yorumlanabilir. Review severity page type'a göre değişebilir.

Template Duplicate

Template description ürün adı dışında tamamen aynı olabilir. Regex ile variable parçalar çıkarılıp kalan template karşılaştırılabilir. High template repetition content kalitesini düşürebilir. Özellikle category ve service pages daha özgün metin isteyebilir. Human veya AI-assisted refinement seçilebilir.

Category Bazlı Duplicate

Aynı category içindeki descriptions ayrı analiz edilebilir. Product catalog'da benzer attribute setleri tekrar yaratabilir. Unique distinguishing fields eklenebilir. Eksik source data duplicate oranını artırabilir. Source enrichment formula değişikliğinden daha iyi çözüm olabilir.

Site-Wide Duplicate

Global duplicate count bütün siteyi kapsar. Farklı page type'ların aynı description'ı kullanması sorun gösterebilir. Dashboard top duplicate texts listesini gösterebilir. High-value pages priority alır. Batch update küçük segmentlerden başlayabilir.

Manuel Review

Her duplicate otomatik yeniden yazılmamalıdır. Benzer ürünlerin tamamen farklı description zorlaması gereksiz olabilir. Reviewer business context'i değerlendirir. Automated flag yalnız aday üretir. Final karar performance ve page purpose'a dayanmalıdır.

Metadata Kalite Skoru Nasıl Oluşturulur?

Quality score birden fazla QA sinyalini tek sayıda özetleyebilir. Alanın dolu olması, length, keyword, duplicate ve brand standardı farklı puanlar taşıyabilir. CTA yalnız description gibi belirli field'larda kontrol edilmelidir. Score approval'ın yerine geçmemelidir. En iyi kullanım, hangi satırların önce review edilmesi gerektiğini belirlemektir.

Alan Dolu mu?

Required field completeness temel puandır. Final title boşsa yüksek severity uygulanır. Description policy'ye göre optional olabilir. Page type required fields config'ten gelir. Missing source ile missing final ayrı metric olmalıdır.

Uzunluk Uygun mu?

Length threshold pass belirli puan verebilir. Borderline values warning olabilir. Hard fail yalnız aşırı değerlerde kullanılabilir. Config page type'a göre değişebilir. Search snippet length'in kesin olmadığını unutmamak gerekir.

Ana Keyword Var mı?

Keyword presence yalnız keyword stratejisi olan sayfalarda ölçülmelidir. Exact phrase zorunluluğu doğal dili bozabilir. Partial veya normalized match kullanılabilir. Keyword source empty ise penalty farklı olmalıdır. Human override keyword'süz ama daha iyi olabilir.

Duplicate mi?

Exact duplicate yüksek penalty alabilir. Near duplicate lower severity olabilir. Same canonical group istisna olabilir. Count ve group size eklenebilir. Duplicate fix batch önceliği business value ile belirlenir.

Marka Standardına Uygun mu?

Brand yanlış yazımı regex veya exact list ile kontrol edilebilir. Marka gerekli olmayan page type'ta bu rule çalışmamalıdır. Rebrand sırasında eski ifade ayrı issue'dur. Source config merkezi olmalıdır. Score yalnız syntax değil policy'yi yansıtır.

CTA Var mı?

Description CTA bazı template'lerde beklenebilir. Her sayfada zorunlu olmak zorunda değildir. Generic CTA spam hissi yaratabilir. Approved CTA listesi kullanılabilir. Rule page type veya content type'a göre uygulanmalıdır.

Toplam QA Score

Toplam score weighted rule sonuçlarını birleştirir. Kritik issue varsa score yüksek olsa bile approval engellenebilir. Score yanında issue listesi her zaman görünür olmalıdır. Threshold historical review ile kalibre edilebilir. Dashboard score distribution trendini izleyebilir.

Örnek Metadata QA Durumları

QA status ekip içi ortak dil oluşturur. OK, Missing, Too Short, Too Long, Duplicate, Missing Keyword, Missing Source Data ve Manual Review gibi değerler yeterli başlangıç setidir. Tek satır birden fazla issue taşıyabilir. Overall status priority rule üzerinden seçilebilir. Detay issue listesi ayrı kolonlarda korunmalıdır.

OK

Temel otomatik kontrolleri geçen kaydı ifade eder. Approved anlamına gelmez. Human-only page policy varsa review devam eder. Final output export için teknik olarak hazır olabilir. Dashboard pass rate bu status'u kullanabilir.

Missing

Final output boş olduğunda kullanılır. Generated ve override source kontrol edilir. Import engellenmelidir. Required source eksik olabilir. Manual fix veya data enrichment gerekir.

Too Short

Value minimum threshold'un altındadır. Otomatik expansion dikkatle uygulanmalıdır. Ek source field mevcutsa template zenginleştirilebilir. Yoksa manual review gerekebilir. Short status tek başına kötü SEO sonucu anlamına gelmez.

Too Long

Value maximum threshold'u aşar. Low-priority field çıkarılabilir. Automatic truncation kelime bütünlüğünü korumalıdır. High-value page review edilir. Length issue release blocker policy'ye bağlıdır.

Duplicate

Normalized value birden fazla URL'de görülür. Group size tutulabilir. Page type ve canonical ilişkisi kontrol edilir. Programmatic pages unique field ekleyebilir. Human review high-value group'lara öncelik verir.

Missing Keyword

Target keyword final metadata içinde bulunmuyor olabilir. Bu durum her zaman hata değildir. Exact match zorunluluğu policy'ye bağlıdır. Search intent doğal olarak karşılanıyorsa manual approval verilebilir. Rule esnek olmalıdır.

Missing Source Data

Formula output üretmek için gereken kaynak eksiktir. Bu status Generated Missing'den ayrılmalıdır. Source data owner problemi çözmelidir. Fallback kullanılmışsa ayrıca flag tutulabilir. Yüksek oran catalog data quality sorununa işaret eder.

Manual Review

Otomatik kurallar net karar veremediğinde kullanılır. High traffic veya high revenue page'ler doğrudan bu kategoriye alınabilir. Reviewer override alanını kullanır. Review reason kaydedilmelidir. Approval sonrası status değişebilir.

Conditional Formatting ile SEO QA

Conditional formatting QA tablosunu hızlı taramayı kolaylaştırır. Renkler kritik hata, review ve approved durumlarını görsel olarak ayırabilir. Ancak renklerin kendisi veri değildir. Export ve dashboard gerçek status değerlerine dayanmalıdır. Renk şeması erişilebilir ve ekip genelinde tutarlı olmalıdır.

Kırmızı: Kritik Hata

Missing final value, duplicate ID veya invalid robots gibi kritik sorunlar kırmızı gösterilebilir. Bu satırlar export edilmemelidir. Critical status ayrı formula alanından gelmelidir. Reviewer rengin nedenini issue column'da görmelidir. Renk yalnız dikkat çekmek için kullanılır.

Uyarı: İnceleme Gerekli

Too long veya fallback used gibi durumlar uyarı seviyesinde gösterilebilir. Bu kayıtlar policy'ye göre yayınlanabilir veya review bekleyebilir. Sarı tonları kullanılabilir. Severity açık biçimde belgelenmelidir. Her uyarı aynı öneme sahip değildir.

Onaylı: Yayına Hazır

Approved ve QA OK satırlar yeşil gösterilebilir. Yine de export yalnız status değerini filtrelemelidir. Color-based filtering operasyon için tek başına güvenilir değildir. Publish sonrası Verified durumu farklı renkle gösterilebilir. Böylece workflow aşamaları görünür olur.

Durum Renklerinin Formülden Ayrı Tutulması

Formula değer üretir, formatting görselleştirir. Bu ayrım automation için önemlidir. Script status'u okuyabilir ancak hücre rengini okumak gereksiz complexity yaratır. Versioning yalnız data values üzerine kurulmalıdır. Dashboard da aynı canonical status alanını kullanmalıdır.

Existing Metadata Nasıl Korunmalıdır?

Toplu metadata projesine başlamadan önce mevcut değerlerin eksiksiz export'u alınmalıdır. Existing title ve description ayrı sütunlarda değiştirilmeden tutulmalıdır. Yeni draft ve final değerler başka alanlarda üretilmelidir. Diff column hangi sayfalarda gerçekten değişiklik olduğunu gösterir. Bu yaklaşım hem performans analizi hem rollback açısından vazgeçilmezdir.

Önce Export

CMS'ten mevcut metadata ve ID export edilmelidir. Export tarihi kaydedilmelidir. URL yanında stable ID bulunmalıdır. Encoding kontrol edilmelidir. Bu dosya immutable backup olarak saklanabilir.

Existing Title

Mevcut title source reference'tır. Formula bunun üzerine yazmamalıdır. Performance data ile birlikte high-value page flag üretilebilir. New generated title diff edilir. Rollback gerektiğinde existing value kullanılır.

Existing Description

Existing description da aynı şekilde korunur. Empty ve non-empty durumlar ayrı analiz edilebilir. Formula yeni draft oluşturur. Eğer existing daha iyi görünüyorsa override olarak korunabilir. Bulk automation existing quality'yi otomatik kötüleştirmemelidir.

New Draft

New draft generated metadata'dır. Existing değerle yan yana tutulur. Diff ve QA bu alanı değerlendirir. Human reviewer değişikliğin gerçekten gerekli olup olmadığına karar verebilir. Generated olmak publish zorunluluğu anlamına gelmez.

Diff

Diff basit eşitlik kontrolü veya daha ayrıntılı text comparison olabilir. No Change kayıtları import dışı bırakılabilir. Değişiklik tipi brand, keyword veya complete rewrite olarak sınıflandırılabilir. Büyük batch'te change count önemlidir. Unexpected massive diff formula regression gösterebilir.

Final Decision

Final decision existing, generated veya manual override arasından seçim olabilir. Bazı high-value pages existing olarak korunabilir. Decision reason alanı audit sağlar. Approved final output export edilir. Publish sonrası actual value yeniden kontrol edilir.

Before/After Karşılaştırma Sütunu

Before/after görünümü SEO uzmanının toplu değişiklikleri hızlı review etmesini sağlar. Eski ve yeni değer yan yana tutulur. Değişiklik olup olmadığı ve tipinin ne olduğu ayrı sütunlarda gösterilebilir. Review status batch ilerlemesini takip eder. Bu yapı yanlış formül değişikliğini publish öncesinde fark etmeyi kolaylaştırır.

Eski Değer

Existing metadata immutable source'tan gelir. Kullanıcı burada edit yapmamalıdır. Export tarihi bilinmelidir. Null değer açık biçimde gösterilebilir. Rollback referansı olarak korunur.

Yeni Değer

Final veya generated draft comparison için kullanılır. Hangisinin gösterildiği açık olmalıdır. Override varsa final tercih edilir. QA status aynı view'da bulunabilir. Reviewer context kaybetmez.

Değişiklik Var mı?

Exact comparison TRUE/FALSE üretebilir. Normalized comparison whitespace-only changes'i ignore edebilir. No-change rows import dışı bırakılabilir. Bu işlem batch boyutunu azaltır. Real change count dashboard'a eklenebilir.

Değişiklik Tipi

Brand update, template update veya manual rewrite gibi classification yapılabilir. Formula rule version değişimi default type olabilir. Değişiklik type performance analysis'e yardımcı olur. Regression durumunda hangi rule'un etkili olduğu görülür. Rollback daha hedefli yapılabilir.

Review Status

Not Started, Reviewed veya Approved gibi değerler kullanılabilir. Reviewer ve timestamp eklenebilir. High-priority page önce işlenebilir. Filter ile yalnız unreviewed changes gösterilir. Workflow bütün ekibin ilerlemeyi görmesini sağlar.

Yüksek Değerli Sayfalar Otomasyondan Nasıl Korunur?

Her URL aynı risk seviyesine sahip değildir. Yüksek organik trafik, gelir, conversion veya backlink değeri taşıyan sayfalar daha kontrollü güncellenmelidir. Priority flag bu kayıtları formula-generated output'tan human-only review'a yönlendirebilir. Otomasyon düşük riskli long-tail sayfalarda daha geniş kullanılabilir. Böylece ölçek kazanırken en değerli SEO varlıkları korunur.

Organic Traffic

Traffic yüksek sayfa metadata değişimine daha hassas olabilir. Historical performance export edilerek priority score'a eklenebilir. High traffic page otomatik publish edilmemelidir. Search intent ve current CTR değerlendirilmelidir. Değişiklik sonrası performance monitoring gerekir.

Revenue

Revenue üreten landing page business risk taşır. SEO improvement potansiyeli kadar conversion etkisi düşünülmelidir. Human review zorunlu olabilir. Batch size bu sayfalarda daha küçük tutulabilir. Rollback dosyası hazır olmalıdır.

Conversion

High conversion page title ve description search snippet davranışını etkileyebilir. Formula generic copy ile mevcut güçlü positioning'i kaybetmemelidir. Existing metadata override olarak korunabilir. Test ve monitoring daha dikkatli yapılır. Conversion source analytics'ten import edilebilir.

Backlink

Backlink değeri yüksek pages önemli SEO asset'tir. Metadata değişikliği URL kadar kritik olmasa da page intent korunmalıdır. Existing positioning bilinçsizce değişmemelidir. Human-only flag verilebilir. Link equity URL değişimiyle birlikte risk daha da büyür.

Priority Flag

Priority High, Medium ve Low gibi basit sınıflandırılabilir. Formula generation devam edebilir ama publish policy farklılaşır. High priority manual approval ister. Low priority QA pass sonrası batch'e girebilir. Priority calculation config-driven olabilir.

Human-Only Metadata

Bazı pages tamamen manual olabilir. Editorial landing page veya yüksek gelir sayfası buna örnektir. Formula sadece suggestion üretebilir. Final value reviewer tarafından yazılır. Human-only status automation'ın yanlış overwrite yapmasını engeller.

Otomatik ve Manuel Metadata Hibrit Modeli

En iyi metadata süreçleri çoğu zaman tamamen otomatik veya tamamen manuel değildir. Long-tail ve katalog sayfaları formula ile ölçeklenebilirken high-traffic landing page'ler uzman edit'i alabilir. Automation threshold page value ve template güvenilirliğine göre belirlenir. Override rate zamanla formül kalitesini ölçer. Hibrit yaklaşım hem verimlilik hem kalite sağlar.

Long-Tail Sayfalar

Çok sayıda düşük hacimli structured page formula için uygundur. Source data iyi olmalıdır. Duplicate ve length QA zorunludur. Small sample manual review kaliteyi izler. Batch publish riskleri azaltır.

Ürün Kataloğu

Product catalog deterministic metadata için güçlü use case'tir. Product, category ve brand source verileri mevcuttur. Varyant yapısı duplicate riskini etkiler. High revenue products manual override alabilir. Katalog güncellemesi düzenli batch olarak çalıştırılabilir.

High-Traffic Landing Page

Bu sayfalarda formula yalnız draft olabilir. SEO uzmanı search intent ve CTR geçmişini değerlendirmelidir. Existing metadata kolayca korunabilmelidir. Change impact ayrı takip edilir. Rollback hızlı olmalıdır.

Editorial Pages

Blog ve campaign landing page'ler daha özgün copy gerektirir. Formül topic ve brand bilgisi verebilir. Final title editor tarafından optimize edilebilir. Description AI-assisted olabilir ancak human review gerekir. Structured template yalnız başlangıç noktasıdır.

Automation Threshold

Threshold page value, confidence ve QA score'a göre belirlenebilir. Örneğin low priority ve QA 100 otomatik approval alabilir. High traffic her durumda human review olabilir. Policy zamanla ölçülen hata oranına göre güncellenir. Automation rate dashboard KPI'ı olarak izlenebilir.

Formül Tabanlı Metadata ile AI Tabanlı Metadata Farkı

Formula tabanlı üretim deterministic olduğu için aynı girdiye aynı çıktıyı verir. AI tabanlı üretim daha özgün metin üretebilir ancak doğruluk ve tutarlılık için daha fazla QA gerektirir. Formula maliyeti düşük ve ölçeklenebilirken AI token ve evaluation maliyeti yaratır. En uygun seçim metadata alanına göre değişir. Hibrit pipeline source cleaning için formula, creative draft için AI ve final QA için tekrar formula kullanabilir.

Deterministic Formula

Formula aynı source data için aynı sonucu üretir. Audit ve rollback kolaydır. Hallucination riski yoktur çünkü yalnız tanımlı alanları birleştirir. Özgünlük template yapısıyla sınırlıdır. Product catalog için güçlüdür.

Generative AI

Generative AI daha doğal ve çeşitli description üretebilir. Ancak source'ta olmayan özellik ekleme riski vardır. Prompt ve model version izlenmelidir. Cost ve latency büyük katalogda önemlidir. Human veya automated fact validation gerektirir.

Tutarlılık

Formula brand ve separator standardını doğal olarak korur. AI farklı biçimde yazabilir. Structured output ve prompt rule tutarlılığı artırabilir. Yine de model version davranışı değişebilir. Final normalization her iki yönteme uygulanabilir.

Özgünlük

AI template tekrarını azaltabilir. Formula unique source fields sayesinde sınırlı özgünlük sağlar. Her description tamamen farklı olmak zorunda değildir. Search intent ve gerçek içerik daha önemlidir. AI diversity doğruluk pahasına artırılmamalıdır.

Maliyet

Spreadsheet formula neredeyse ek inference maliyeti yaratmaz. AI binlerce satırda token harcaması oluşturur. Retry ve QA cost'u da hesaba katılmalıdır. High-value pages AI kullanırken long-tail formula tercih edilebilir. Cost per approved metadata ölçülebilir.

QA Gereksinimi

Formula syntax ve source quality QA ister. AI buna ek olarak factuality ve unsupported claim kontrolü gerektirir. Length ve duplicate checks iki yöntemde de aynıdır. Human review risk seviyesine göre uygulanır. Output source type QA policy'yi belirleyebilir.

Hangi Metadata Formülle Üretilmeli?

Deterministic ve yapısal SEO alanları formül üretimine daha uygundur. Product title, location page title, category title, canonical, robots ve URL pattern açık source alanlardan oluşturulabilir. Bu alanlarda yaratıcı üretim yerine tutarlılık daha değerlidir. Page type rule ve fallback açık olmalıdır. Formül output yine QA ve approval aşamasından geçmelidir.

Ürün Title Kalıpları

Product name, category ve brand template için yeterlidir. Variant source varsa conditional eklenebilir. Long name rule tanımlanmalıdır. Duplicate control uygulanır. High-value product manual review olabilir.

Lokasyon Landing Page’leri

Service, keyword ve location kombinasyonu formula ile üretilebilir. Thin content problemi metadata dışında ayrıca çözülmelidir. Location normalization önemlidir. Duplicate local page kontrolü yapılır. Human sample review düzenli uygulanabilir.

Kategori Title’ları

Category name ve brand deterministic template oluşturur. Value proposition config'ten gelebilir. Hierarchy duplicate title'ları ayrıştırabilir. Exact keyword aşırı kullanılmamalıdır. Final title length QA alır.

Canonical

Canonical teknik deterministic alandır. URL mapping rule kullanılabilir. Varyant ve pagination policy açık olmalıdır. Formula sonucu crawl ile test edilir. Yanlış canonical high severity issue'dur.

Robots

Robots page status veya indexability config'ten üretilebilir. Noindex gibi değerler yüksek risklidir. Approval veya automated test gerekir. Formula deterministic olması avantajdır. Final crawl production state'i doğrular.

URL Kalıpları

Yeni pages için slug pattern formula ile üretilebilir. Türkçe karakter transliteration ayrı helper olabilir. Existing URL'ler otomatik değiştirilmemelidir. Redirect gereksinimi kontrol edilir. Duplicate slug validation yapılır.

Hangi Metadata AI ile Üretilebilir?

AI daha doğal ve özgün copy gerektiren alanlarda yardımcı olabilir. Meta description, CTA ve benefit copy bunların başında gelir. Ancak ürün özelliği veya iş iddiası source data dışında üretilmemelidir. Structured input ve explicit constraints kullanılmalıdır. Human review özellikle yüksek değerli veya regülasyon hassasiyeti olan sayfalarda zorunlu tutulabilir.

Meta Description

AI source fields'tan doğal açıklama oluşturabilir. Prompt yalnız verilen gerçekleri kullanma kuralı taşımalıdır. Output length daha sonra formula ile kontrol edilir. Duplicate similarity ayrıca izlenir. Low-risk pages sample review ile yönetilebilir.

Özgün CTA

AI sayfa tipine uygun CTA varyasyonları üretebilir. CTA gerçek feature veya action'a dayanmalıdır. Çok agresif veya yanlış promise engellenmelidir. Approved phrase library oluşturulabilir. Final text brand tone review alabilir.

Benefit Copy

Source benefit alanlarından daha doğal cümle üretilebilir. AI yeni avantaj uydurmamalıdır. Structured input ile hangi özelliklerin kullanılacağı sınırlandırılır. Human validation sample uygulanır. Sensitive ürünlerde manual-only policy seçilebilir.

Karmaşık Ürün Özeti

Birden fazla specification alanını kısa description'a dönüştürmek AI için uygun olabilir. Kaynak fields prompt'a açık verilir. Missing feature tamamlanmamalıdır. Fact check script source-value inclusion kontrolü yapabilir. High-value product human review alır.

İnsan Kontrolü Gerektiren Alanlar

Legal claim, sağlık iddiası veya finansal promise içeren metadata otomatik yayınlanmamalıdır. Marka positioning açısından kritik pages de manual approval gerektirebilir. AI draft yalnız destek sağlar. Review reason ve approver kaydedilebilir. Risk-based governance ölçeklenebilir yapı sunar.

AI Hallucination Nasıl Önlenir?

AI metadata üretiminde en büyük risk source'ta bulunmayan özellik veya faydanın metne eklenmesidir. Bu nedenle prompt yalnız mevcut kolonları kullanma kuralına bağlanmalıdır. Eksik veri varsa modelin tahmin yapması yerine boş veya review status üretmesi istenmelidir. Fact validation source değerlerle output'u karşılaştırabilir. Human approval yüksek riskli alanlarda son güvenlik katmanı olarak kalmalıdır.

Yalnızca Mevcut Sütunları Kaynak Olarak Kullan

Prompt structured fields almalıdır. Model internet veya genel bilgisinden ek özellik kullanmamalıdır. Allowed facts açık listelenebilir. Empty fields unavailable olarak belirtilir. Generated output source lineage taşıyabilir.

Bilinmeyen Özellik Üretme

"Ek bilgi uydurma" instruction açık olmalıdır. Özellikle product feature ve certification risklidir. Unknown durumda cümle sade tutulmalıdır. Automated keyword extraction unsupported noun phrase bulabilir. Human sample review devam eder.

Kaynak Veri Eksikse Output Vermeme

Critical source eksikse modelden draft istenmemelidir. Pipeline Missing Source Data status üretir. Bu yaklaşım yanlış iddiadan daha güvenlidir. Source data enrichment ayrı workflow'dur. Completion rate yerine correctness önceliklendirilmelidir.

Fact Validation

Output içindeki numbers ve named attributes source'a karşı kontrol edilebilir. Regex veya LLM judge kullanılabilir. Deterministic validation mümkün olduğunda tercih edilmelidir. Failed output manual review'a gider. Validation result trace edilebilir.

Human Approval

İnsan reviewer business context'i değerlendirebilir. AI veya formula QA'nın kaçırdığı anlam problemlerini bulur. Risk yüksek pages yüzde yüz review alabilir. Low-risk pages sampling ile yönetilebilir. Approval status export gate olarak kullanılır.

Formül + AI Hibrit Pipeline

Formula ve AI birbirinin alternatifi olmak zorunda değildir. Formula source data'yı temizler, AI natural draft üretir, formula tekrar length ve keyword QA yapar, insan final review uygular. Bu pipeline özellikle description üretiminde etkilidir. Her aşamanın output'u ayrı sütunda tutulmalıdır. Böylece hata kaynağı ve maliyet kolayca izlenir.

Formülle Source Data Temizleme

TRIM, CLEAN ve normalization önce uygulanır. Empty ve fallback fields belirlenir. Structured AI input oluşturulur. Sensitive data varsa redaction yapılır. Source quality status AI generation gate'i olabilir.

AI ile Draft

Model yalnız approved source fields alır. Structured output istenir. Prompt version kaydedilir. Retry count ve cost takip edilir. Draft generated description sütununa yazılır.

Formülle Length/Keyword QA

AI output tekrar deterministic rules'tan geçer. LEN, keyword presence ve duplicate kontrolü yapılır. Unsupported character temizlenebilir. Failed draft regenerate veya review'a gider. QA sonucu model prompt iyileştirmesini destekler.

Human Review

Reviewer yüksek riskli veya failed output'ları inceler. Override alanına final edit yazılır. Reason code kaydedilebilir. Approval verildikten sonra export mümkün olur. Review rate zaman içinde azalabilir.

Final Output

Final generated veya override değerini seçer. Approval gate sonrası import-ready tab'a taşınır. Formula code değil value export edilir. Batch ID atanır. Publish sonrası actual metadata doğrulanır.

Büyük E-Tablolarda Performans Nasıl Korunur?

Spreadsheet ölçeği büyüdükçe formül performansı gerçek operasyon problemine dönüşür. Gereksiz full-column references, ağır REGEX ve çok fazla volatile function hesaplama süresini artırır. Helper columns bazı durumlarda uzun tek formülden daha hızlı ve anlaşılır olabilir. Eski batch'ler values olarak freeze edilebilir. 10.000 üzeri satırlarda formula cost ölçülmeli ve script'e geçiş eşiği belirlenmelidir.

Gereksiz Full-Column Reference’lardan Kaçınmak

A:A gibi açık uçlu range büyük dataset'te gereksiz hesap yapabilir. Gerçek data sınırı kullanılabilir. Dynamic named ranges alternatif sunar. Dashboard helper queries ayrı sheet'te olabilir. Formula profiling manuel de olsa yapılmalıdır.

Çok Fazla Volatile Formula Kullanılmaması

NOW, RAND veya INDIRECT gibi functions sık recalculation yaratabilir. Metadata üretiminde çoğu zaman gerekli değildir. Stable references tercih edilmelidir. Dynamic config için lookup kullanılabilir. Volatile formula sayısı minimum tutulmalıdır.

Helper Columns

Normalization, fallback ve length işlemlerini ayrı kolonlara bölmek performance ve debug kolaylığı sağlar. Çok fazla helper da tabloyu karmaşıklaştırabilir. Hidden technical section kullanılabilir. Naming convention açık olmalıdır. Final formula sade kalır.

Sheet Bölümleme

Raw, Working, QA, Config ve Export tabs ayrılabilir. Büyük category'ler ayrı sheet olabilir. Aynı data'nın gereksiz duplicate kopyaları memory kullanır. Query veya filter view tercih edilebilir. Architecture data lineage'i korumalıdır.

Değerleri Gerektiğinde Freeze Etmek

Published batch artık formül gerektirmiyorsa values olarak archive edilebilir. Active working set küçük tutulur. Formula version ve output history saklanır. Freeze öncesi backup alınmalıdır. Audit ihtiyaçları için original file korunabilir.

Hesaplama Maliyeti

Formula runtime ölçülebilir olmasa da kullanıcı deneyimi üzerinden izlenebilir. Refresh süresi çok uzuyorsa script daha uygun olabilir. API veya database işlemleri spreadsheet dışında yapılmalıdır. Cost yalnız zaman değil error riskini de içerir. Tool selection problem büyüklüğüne göre yapılmalıdır.

10.000+ Satırda Metadata İşleme

On binlerce URL hâlâ spreadsheet ile yönetilebilir ancak daha kontrollü çalışma gerekir. Batch işleme, category segmentation ve formula range sınırlaması performansı artırır. QA bütün dataset üzerinde çalışırken human review sampling ile yapılabilir. Export küçük batch'lere bölünmelidir. Binlerce URL için Excel formülleriyle toplu SEO metadata optimizasyonu yapılırken spreadsheet sınırları düzenli olarak değerlendirilmelidir.

Batch İşleme

Dataset 1.000 veya 2.000 URL'lik gruplara ayrılabilir. Her batch QA ve approval alır. Publish sonrası monitoring yapılır. Hata çıkarsa etki alanı küçülür. Batch ID rollback'i kolaylaştırır.

Category Bazlı Sheet

Büyük catalog category bazında bölünebilir. Her sheet aynı schema kullanmalıdır. Formula library ortak kalmalıdır. Cross-category duplicate QA merkezi table'da yapılabilir. Manual copy-paste drift engellenmelidir.

Formula Range Sınırı

Gerçek dataset uzunluğuna göre range belirlenebilir. Boş yüz binlerce hücre üzerinde hesap yapılmaz. Named range veya dynamic end row kullanılabilir. Performance ölçülmelidir. Range logic debug edilebilir olmalıdır.

Export Batch

Approved rows small CSV batch'lere ayrılır. CMS limitleri dikkate alınır. Her dosya batch ID taşır. Import result ayrı kaydedilir. Failed subset yeniden işlenebilir.

QA Sampling

Automated QA bütün satırlara uygulanır. Human review stratified sample kullanabilir. High priority pages yüzde yüz incelenebilir. Category ve page type temsil edilmelidir. Sample error rate automation confidence'ı ölçer.

E-Tablodan Script’e Ne Zaman Geçilmelidir?

Spreadsheet belirli noktaya kadar çok hızlı çözüm sunar. Ancak veri hacmi, API ihtiyacı, günlük tekrar ve audit gereksinimi arttığında script daha uygun hale gelir. Geçiş bir başarısızlık değil doğal olgunlaşma aşamasıdır. İyi tasarlanmış row-level schema Python veya Apps Script'e kolay taşınır. Tool seçiminde bakım maliyeti ve ekip yetkinliği birlikte değerlendirilmelidir.

Çok Büyük Veri Seti

Yüz binlerce row spreadsheet için zorlayıcıdır. Formula recalculation yavaşlar. CSV ve Pandas daha verimli olabilir. Database kullanmak gerekebilir. Spreadsheet yalnız review interface olarak kalabilir.

API Gereksinimi

CMS'e otomatik update gerekiyorsa script avantajlıdır. Authentication ve rate limit yönetilir. Response status loglanır. Failed records retry edilebilir. Formula tek başına bu davranışı güvenli yönetemez.

Tekrarlayan Günlük İş

Her gün yeni product metadata üretmek manuel dosya işlemini yorucu hale getirir. Scheduled script source data'yı çekip pipeline'ı çalıştırabilir. Approval yine spreadsheet üzerinden verilebilir. Changed-only records sync edilir. Audit log otomatik tutulur.

Rate Limit Yönetimi

External API belirli request sınırına sahip olabilir. Script batching ve backoff uygular. Retry count izlenir. Formula API call yaklaşımı kontrolsüz olabilir. Production sync dedicated worker'a taşınmalıdır.

Veri Tabanı Entegrasyonu

Metadata source doğrudan database'de tutuluyorsa CSV export gereksiz olabilir. Python veya SQL data pipeline oluşturabilir. Spreadsheet approval layer olarak bağlantı kurabilir. Unique ID association korunur. Source of truth net tanımlanır.

Audit Log Gereksinimi

Kim hangi kaydı ne zaman değiştirdi bilgisi kritikse script ve database daha güçlüdür. Spreadsheet edit history yardımcı olabilir ama structured audit sınırlıdır. Publish event ayrı table'a yazılabilir. Old-new values saklanır. Compliance ve rollback kolaylaşır.

Google Apps Script ile Metadata Otomasyonu

Apps Script Google Sheets'i basit çalışma tablosundan otomasyon aracına dönüştürebilir. Range okuma, batch update, menu ve trigger ile repetitive işler azaltılır. External API entegrasyonu yapılabilir. Ancak script error handling ve rate limit tasarımı gerektirir. Source spreadsheet schema sabit kaldığında script daha güvenilir çalışır.

Custom Function

Custom Function karmaşık metadata logic'i JavaScript içinde tanımlayabilir. Hücrede normal function gibi kullanılabilir. External API çağrılarında limitler vardır. Deterministic computation için uygundur. Çok fazla row'da performance test edilmelidir.

Range Okuma

Tek tek hücre yerine batch range okumak performansı artırır. Data 2D array olarak işlenebilir. Header map column index sorununu azaltır. Empty rows skip edilir. Unique ID her record'a bağlanır.

Batch Update

Sonuçlar tek hücre update yerine toplu yazılmalıdır. Apps Script execution süresi daha verimli kullanılır. Failed rows ayrı loglanabilir. Output yalnız generated columns'a yazılmalıdır. Protected override alanları korunur.

Menu / Button

Custom menu ekip için kolay workflow sağlar. "QA Çalıştır" veya "Export Oluştur" gibi aksiyonlar eklenebilir. Yetki kontrolü yapılmalıdır. Script action loglanabilir. Button sadece convenience sağlar, data validation yerini almaz.

API Entegrasyonu

CMS API ile metadata publish edilebilir. Token güvenli property store'da tutulmalıdır. Request payload ID ve final fields içerir. Response code record edilir. Failed updates retry queue'ya alınabilir.

Trigger

Time-driven trigger günlük processing çalıştırabilir. On-edit trigger ağır iş için uygun olmayabilir. Infinite recursion engellenmelidir. Trigger owner hesabı dikkatle seçilmelidir. Failure notification kurulabilir.

Python ile Spreadsheet Metadata İşleme

Python daha büyük metadata dataset'leri ve karmaşık validation için güçlü seçenektir. CSV ve Pandas ile binlerce satır hızlı işlenebilir. Regex ve custom functions spreadsheet'ten daha test edilebilir yapı sağlar. Google Sheets API veya CMS API ile iki yönlü sync kurulabilir. Spreadsheet yine human review interface olarak kullanılabilir.

CSV

CSV en basit interchange formatıdır. UTF-8 encoding kullanılmalıdır. Formula değil calculated values export edilmelidir. ID field korunmalıdır. Type inference leading zero gibi değerleri bozmamalıdır.

Pandas

Pandas tabular metadata processing için uygundur. Vectorized string operations hızlıdır. QA columns programmatically üretilebilir. Unit test kolaylaşır. Çok büyük data için başka araçlar değerlendirilebilir.

Google Sheets API

Python Sheets API ile source ve approval data okuyabilir. Batch request kullanmak quota kullanımını azaltır. Authentication service account veya OAuth ile yönetilir. Protected data erişimi sınırlandırılmalıdır. Sync status tekrar sheet'e yazılabilir.

Regex

Python regex daha kapsamlı cleaning sağlar. Pattern unit test ile doğrulanabilir. Turkish Unicode davranışı test edilmelidir. Near-duplicate extraction yapılabilir. Overly broad pattern data kaybı yaratmamalıdır.

Validation

Length, duplicate ve required fields kodla kontrol edilir. Validation result structured issue listesi olabilir. Failing rows export dışı bırakılır. Golden sample regression test'te kullanılır. Validation version release ile eşleştirilebilir.

CMS API

Final metadata direct API üzerinden güncellenebilir. Dry-run mode payload'ı publish öncesi gösterir. Rate limit ve retry uygulanır. Old values transaction log'a yazılır. Rollback API üzerinden otomatik hale gelebilir.

“En İyi Programlama Dili” Bu İş İçin Hangisidir?

Metadata otomasyonunda en iyi araç problemin boyutuna göre değişir. Küçük ve orta projede kod yazmadan spreadsheet formula yeterli olabilir. Google Workspace kullanan ekip Apps Script ile doğal şekilde ilerleyebilir. Büyük dataset ve API yoğun süreçte Python daha esnek olur. SQL ise source data warehouse içinde hazırlanıyorsa güçlü destek sağlar.

Kod Yazmadan Formula

Formula en düşük başlangıç maliyetine sahiptir. SEO ekibi developer beklemeden prototip oluşturabilir. Deterministic ve görünürdür. Çok karmaşık workflow'da bakım zorlaşır. Belirli eşikten sonra script'e geçiş planlanmalıdır.

Apps Script / JavaScript

Google Sheets ile yakın entegrasyon sağlar. Menü, trigger ve API bağlantısı kurulabilir. Küçük automation ekipleri için uygundur. Execution quotas bilinmelidir. Production sync'te error handling zorunludur.

Python

Data processing ve API automation için güçlüdür. Testing ve package yapısı sürdürülebilirlik sağlar. Pandas büyük catalog işlerinde rahatlık sunar. Deployment bilgisi gerektirir. Spreadsheet'ten bağımsız backend pipeline kurulabilir.

SQL

Source data warehouse'da ise normalization ve joining SQL ile yapılabilir. Metadata template bazı durumlarda SQL string functions ile üretilebilir. Final review spreadsheet'e export edilebilir. Complex natural text SQL'de yönetmek zorlaşabilir. Data transformation source'a yakın kalır.

Problem Büyüklüğüne Göre Araç Seçimi

Yüzlerce URL formula ile rahat yönetilebilir. On binlerce satır için optimized spreadsheet veya Python değerlendirilebilir. Daily API sync script gerektirir. Team skill ve maintenance cost kararın parçasıdır. Gereksiz engineering complexity'den kaçınılmalıdır.

CSV ile Toplu Metadata Import

CSV bulk import süreçlerinde yaygın kullanılan formattır. Başarılı import yalnız doğru title üretmekten değil backup, encoding, ID koruma ve verification adımlarından oluşur. Formula hücreleri doğrudan gönderilmemelidir. Calculated values export edilmelidir. İlk deneme küçük sample batch ile yapılmalıdır.

Export

CMS'ten existing data önce export edilir. Required ID ve metadata fields dahil edilmelidir. Export version veya date kaydedilir. Raw file değiştirilmeden saklanır. Working copy ayrı oluşturulur.

Backup

Original export immutable backup olarak tutulur. File naming batch ve date içermelidir. Cloud versioning kullanılabilir. Erişim yetkisi sınırlanabilir. Rollback bu dosyaya dayanır.

ID Alanını Korumak

ID CSV'de text veya numeric olabilir. Leading zeros korunmalıdır. Spreadsheet otomatik scientific notation yapmamalıdır. Import mapping exact field kullanmalıdır. Duplicate ID gate çalıştırılır.

UTF-8

Türkçe karakterler için UTF-8 zorunlu tercih olmalıdır. CSV export encoding kontrol edilmelidir. İ, ı, ş ve ç sample kayıtlar test edilmelidir. CMS import sonrası actual values doğrulanır. Encoding issue büyük batch'e yayılmadan yakalanmalıdır.

Formula → Value Dönüşümü

CMS spreadsheet formula syntax'ini anlamaz. Final output calculated values olarak export edilmelidir. Paste Values veya script kullanılabilir. Import-ready tab formulasız olabilir. Formula source working sheet'te korunur.

Import

İlk import küçük batch ile yapılır. Mapping preview dikkatle kontrol edilir. Only changed fields gönderilebilir. Failure log alınmalıdır. Production run batch ID ile ilişkilendirilir.

Verification

Import sonrası yeniden export yapılabilir. Expected ve actual values ID üzerinden karşılaştırılır. Sample crawl title ve description'ı doğrular. Encoding ve truncation sorunları kontrol edilir. Batch Verified status ancak bundan sonra verilir.

Formüller CMS’e Direkt Import Edilmeli mi?

Hayır, çoğu durumda CMS'e gönderilmesi gereken şey formül kodu değil hesaplanmış final değerdir. Formula spreadsheet'in üretim mantığıdır. CMS yalnız metadata string'ini saklamalıdır. Import-ready sheet formülsüz ve approved values içermelidir. Bu ayrım yanlışlıkla "=IF(...)" gibi ifadelerin siteye yazılmasını engeller.

Formula Hücresi

Formula working layer içinde kalmalıdır. Kullanıcı generated logic'i burada görür. CMS export bu hücreyi doğrudan okumamalıdır. Protected column olabilir. Versioning bu formula definition'ı takip eder.

Calculated Value

Formula'nın kullanıcıya görünen sonucudur. Import için gereken veri budur. Override varsa final calculated value farklı olabilir. QA final result üzerinde çalışır. CSV yalnız final string taşır.

Paste Values

Import-ready tab values-only olabilir. Manual paste values kullanılabilir. Büyük sistemde script daha güvenlidir. Source formula değişmeye devam eder. Values snapshot batch tarihini temsil eder.

Import-Ready Sheet

Bu tab yalnız ID ve publish fields içerir. Formula veya QA helper bulunmaz. Approved rows filtrelenir. Values freeze edilir. Batch ID metadata eklenebilir.

Formül Kodunun Yanlışlıkla CMS’e Gitmesini Önlemek

Export step otomatik script ile values-only oluşturabilir. CSV sample kontrolü yapılır. "=" ile başlayan final values ayrıca validation alabilir. Import mapping sınırlandırılır. Dry run riski daha da azaltır.

Import-Ready Tab Nasıl Tasarlanır?

Import-ready tab çalışma alanının sade ve güvenli yayın görünümüdür. Yalnız CMS'in gerçekten ihtiyacı olan ID, URL veya handle ve final metadata alanlarını içerir. QA helper, formulas ve draft columns burada bulunmamalıdır. Approved records values olarak taşınır. Bu ayrım yanlış alanların production'a gönderilmesini ciddi biçimde azaltır.

ID

Primary mapping key'tir. Missing olmamalıdır. Duplicate kontrolünden geçmiş olmalıdır. Format CMS ile uyumlu tutulur. Leading zero korunmalıdır.

URL/Handle

Secondary verification key olabilir. URL değişmişse ID primary kalır. Handle CMS mapping gerektiriyorsa included edilir. Normalized ve actual değer ayrılabilir. Import sonrası expected mapping kontrol edilir.

Final Meta Title

Approved final value olmalıdır. Formula değil string olarak bulunur. Empty check yapılır. Duplicate ve length QA geçmiş olmalıdır. High-priority page approval şartı korunur.

Final Meta Description

Final approved description values-only tutulur. Empty policy açık olmalıdır. Encoding ve line break normalization yapılır. Duplicate warning resolve edilmiş olmalıdır. CMS limitleri sample test ile doğrulanır.

Final H1

H1 güncellenecekse ayrı alan olarak bulunur. Metadata ve page content update aynı batch'te yapılacaksa risk artabilir. H1 optional olabilir. Existing value backup'ta korunur. Import sonrası page crawl yapılır.

Yalnızca Yayınlanacak Alanlar

Gereksiz source columns export edilmemelidir. Sensitive business data CMS import dosyasına konulmamalıdır. Narrow schema hata ihtimalini düşürür. File review kolaylaşır. API payload da aynı prensibi kullanabilir.

Formula Olmayan Değerler

Import-ready hücrelerde formül bulunmaması tercih edilir. Snapshot deterministic hale gelir. Formula recalculation publish sırasında sürpriz değişiklik yaratmaz. Batch archive kolaylaşır. Rollback dosyasıyla karşılaştırma yapılabilir.

Toplu Import Öncesi QA

Import öncesi quality gate, bulk metadata projesinin en kritik aşamalarından biridir. Missing veya duplicate ID yanlış kaydı güncelleyebilir. Empty output ve duplicate metadata kalite sorunu yaratabilir. Approval status publish kararını kontrol eder. Sample test küçük batch'te gerçek CMS davranışını doğrular.

Missing ID

ID boşsa kayıt import edilmemelidir. URL fallback key ancak bilinçli policy varsa kullanılabilir. Missing ID source data problemi olarak işaretlenir. Row quarantine edilir. Owner düzeltme yapar.

Duplicate ID

Aynı ID iki final output ile bulunmamalıdır. COUNTIF veya script check critical failure üretir. Duplicate rows comparison yapılır. Tek doğru record seçilir. Import bu issue çözülmeden başlamaz.

Empty Output

Final title empty ise çoğu durumda block edilir. Description optional policy'ye göre farklı olabilir. Generated missing ve intentional blank ayrılmalıdır. Override deletion special case olabilir. CMS empty value behavior test edilmelidir.

Invalid Character

Control character veya line break import'u bozabilir. Encoding validation yapılır. CSV delimiter içeren text doğru quote edilmelidir. UTF-8 test edilir. Sample special-character records kullanılır.

Duplicate Metadata

Exact duplicate titles ve descriptions batch öncesi listelenir. Severity threshold belirlenir. Existing duplicates ile new duplicates ayrılabilir. Formula change duplicate oranını artırdıysa release durdurulabilir. Root cause düzeltilir.

Approval Status

Only Approved rows export edilir. QA OK ama approval empty record yayınlanmaz. Automation threshold bazı low-risk pages için auto-approve verebilir. High priority human approval ister. Status tam değer eşleşmesiyle kontrol edilir.

Sample Test

10 veya 20 temsilci kayıt önce import edilir. Product, category ve Türkçe karakter örnekleri dahil edilir. Actual output crawl edilir. Mapping ve truncation kontrol edilir. Test başarıyla tamamlandıktan sonra batch büyütülür.

Metadata Değişiklikleri Neden Batch Halinde Yayınlanmalı?

Binlerce metadata değişikliğini tek seferde yayınlamak hata olduğunda root cause ve rollback işlemini zorlaştırır. Batch yaklaşımı etki alanını küçültür. Category veya vendor bazlı gruplar kolay izlenir. Search performance değişikliği daha kontrollü analiz edilir. Batch publish operasyon riskini önemli ölçüde azaltır.

QA Kolaylığı

Küçük batch reviewer'ın gerçek değişiklikleri görmesini kolaylaştırır. Error rate ölçülebilir. Formula problem early stage'de yakalanır. Sample crawl daha hızlıdır. Sonraki batch kural düzeltmesiyle yayınlanabilir.

Rollback

Her batch kendi backup ve import file'ına sahiptir. Hata yalnız ilgili group'ta geri alınır. Entire site restore gerekmez. Batch ID audit log'da bulunur. Rollback test pilot aşamada yapılmalıdır.

Hata İzolasyonu

Encoding veya mapping problemi sadece küçük grup etkiler. Root cause hangi batch'te başladığıyla bulunur. Formula version aynı batch'e bağlanır. Error pattern daha kolay analiz edilir. Large-scale incident riski düşer.

Search Performance Monitoring

Batch publish date analytics'e marker olarak eklenebilir. CTR ve ranking trendleri segment bazında izlenir. SEO etkisini tek değişikliğe atfetmek yine dikkat ister. Seasonal ve algorithmic factors olabilir. Controlled rollout daha anlaşılır veri sağlar.

Category/Vendor Bazlı Batch

Benzer page type aynı batch'te tutulabilir. Formula template aynı olduğu için issue root cause daha nettir. High-value category küçük batch olabilir. Vendor source quality farkları görülebilir. Publish success rate segment bazında ölçülür.

Import Sonrası Doğrulama

Import tool'un "başarılı" mesajı gerçek metadata'nın doğru yayınlandığını garanti etmez. Yeniden export ve crawl ile actual state doğrulanmalıdır. Missing update, encoding problemi veya CMS truncation görülebilir. Expected vs actual comparison stable ID üzerinden yapılmalıdır. Verified status ancak bu kontrollerden sonra verilmelidir.

Yeniden Export

CMS'ten güncel metadata tekrar alınır. Same fields ve ID bulunmalıdır. Export timestamp kaydedilir. Batch subset filtrelenir. Original working file ile join yapılır.

Expected vs Actual

Final intended value actual CMS value ile karşılaştırılır. Exact equality veya normalized comparison kullanılabilir. Mismatch listesi oluşturulur. Unexpected transformation CMS behavior gösterebilir. Retry veya manual fix uygulanır.

Missing Updates

Bazı rows API veya import tarafından atlanmış olabilir. ID-based left join bunu gösterir. Error log ile eşleştirilir. Missing rows ayrı retry batch olur. Silent failures önemli operasyon riskidir.

Encoding Problems

Türkçe karakter bozulması actual export'ta görülebilir. UTF-8 source ve import config kontrol edilir. Problemli batch rollback gerekebilir. Sample test bu riski önceden yakalamalıdır. Character regression test oluşturulabilir.

CMS Tarafından Kesilen Değerler

Bazı CMS alan limitleri beklenenden farklı olabilir. Actual value kısa gelirse truncation incelenir. Formül limit config'i CMS davranışına göre güncellenebilir. Automatic truncation server-side ise kelime kaybı oluşabilir. Import schema documentation kontrol edilir.

Final Crawl

Crawler actual HTML head içindeki metadata'yı doğrular. CMS database'de doğru olup frontend render'da yanlış olabilir. Canonical ve robots da aynı crawl ile kontrol edilir. Sample yerine batch-wide crawl mümkünse tercih edilir. Verified status crawl sonucu ile güncellenebilir.

Rollback Planı Nasıl Hazırlanır?

Rollback planı bulk metadata değişikliğinin güvenlik ağıdır. Original metadata backup, batch ID, change date ve import file birlikte saklanmalıdır. Önceki values geri yüklemeye hazır formatta tutulmalıdır. Rollback prosedürü sadece dokümanda bulunmamalı, pilot batch'te test edilmelidir. Hata durumunda hızlı aksiyon için owner açıkça belirlenmelidir.

Original Metadata Backup

Pre-change export temel rollback kaynağıdır. Immutable olarak saklanır. ID ve all changed fields bulunur. Encoding doğrulanır. Retention project lifecycle boyunca korunabilir.

Batch ID

Her publish group unique batch ID taşır. Working sheet, CSV ve audit log aynı ID'yi kullanır. Incident hangi changes'in geri alınacağını kolayca bulur. Formula version batch'e bağlanır. Monitoring marker aynı ID'yi kullanabilir.

Change Date

Publish timestamp performance ve audit için gereklidir. Timezone standard kullanılmalıdır. Multiple updates aynı gün ayrı batch olarak kaydedilir. Rollback eligibility bu tarih üzerinden belirlenebilir. Analytics release marker sağlar.

Import File

Gerçek production'a gönderilen exact file saklanmalıdır. Working sheet sonradan değişebilir. Import snapshot actual action'ı temsil eder. Checksum bile tutulabilir. Incident analysis daha güvenilir olur.

Previous Values

Her changed record old value taşımalıdır. Rollback file yalnız bu values'i içerir. URL yerine ID mapping tercih edilir. Deleted veya new pages ayrı state olabilir. Data type CMS formatıyla uyumlu tutulur.

Geri Yükleme

Rollback küçük test ile başlatılabilir. Previous values tekrar import edilir. Actual state yeniden doğrulanır. Incident reason kaydedilir. Formula fix sonrası new batch hazırlanır.

Formula Versioning Neden Gereklidir?

Metadata kuralı zaman içinde değişir. Separator, brand, fallback veya template update edilince generated values topluca farklılaşabilir. Hangi satırın hangi formula version ile üretildiğini bilmek reproducibility sağlar. Rule change impact publish öncesi karşılaştırılabilir. Versioning spreadsheet otomasyonunu daha güvenilir yazılım pratiğine yaklaştırır.

Metadata Rule v1

İlk production template version'ıdır. Formula text veya named function snapshot saklanır. Test outputs kaydedilir. Published batches bu version'a referans verir. Sonradan değiştirilmez.

Metadata Rule v2

Yeni rule ayrı version olarak tanımlanır. v1 üzerine sessiz overwrite yapılmaz. Sample dataset iki version ile çalıştırılır. Diff report oluşturulur. Approval sonrası yeni batch v2 kullanır.

Hangi Satır Hangi Versiyonla Üretildi?

Generated row formula_version sütunu taşıyabilir. Override kullanılmış olsa bile generated source bilinmelidir. Published batch rule version ile eşleşir. Regression root cause kolaylaşır. Dashboard version distribution gösterebilir.

Rule Change Impact

Yeni formula bütün sample veya full dataset üzerinde dry-run çalıştırılır. Değişen row count hesaplanır. Unexpected high change release riskidir. High-value pages diff review alır. Impact report release notes'a eklenebilir.

Reproducibility

Aynı source data ve rule version aynı output'u üretmelidir. Config version da saklanmalıdır. Random AI output bu özellikten farklıdır. Formula metadata-as-code yaklaşımının avantajı buradadır. Audit ve rollback kolaylaşır.

Metadata Kuralları Config Tabında Tutulabilir mi?

Evet, marka adı, separator, karakter limitleri ve CTA gibi değerleri config tabında tutmak formül bakımını kolaylaştırır. Formül logic sabit kalırken business rules değişebilir. Named ranges config kullanımını daha okunabilir yapar. Edit permission config tabında sınırlandırılmalıdır. Her config change version ve tarih ile kaydedilebilir.

Marka Adı

Global brand value tek hücrede tutulabilir. Rebrand durumunda formula code değişmez. Multi-brand kataloglarda mapping table kullanılabilir. Invalid blank value QA failure üretebilir. Config edit only authorized role tarafından yapılmalıdır.

Separator

Pipe veya başka separator merkezi yönetilir. Formula hard-code yapmaz. Template-specific separator gerekirse mapping eklenebilir. Output normalization aynı değeri kullanır. Rule change impact test edilir.

Title Limit

QA threshold config'te tutulabilir. Page type'a göre farklı limit tanımlanabilir. Formula generation hard truncation yerine status üretir. Limit değişimi historic rows'u etkiler. Versioning gereklidir.

Description Limit

Description threshold ayrı tutulur. Minimum ve maksimum değer bulunabilir. CMS field limit ile SEO warning threshold ayrılmalıdır. Config documentation bunu açıklamalıdır. Dashboard aynı source'u kullanır.

CTA

Approved CTA phrase listesi config'te bulunabilir. Page type'a göre mapping yapılabilir. Formula rastgele text üretmez. AI prompt aynı listeden beslenebilir. Değişiklik sonrası duplicate rate kontrol edilir.

Sayfa Tipi Templates

Product, category ve service templates tablo halinde saklanabilir. Formula lookup ile template code seçebilir. Full text placeholder replacement spreadsheet'te karmaşıklaşabilir. Named Function bu yapıyı sadeleştirebilir. New page type config update ile eklenebilir.

Formülü Değiştirmeden Kural Güncellemek

Config-driven tasarımın en büyük avantajıdır. Marka veya CTA güncellemesi formula code'a dokunmadan yapılır. Risk yine tamamen yok olmaz. Config change preview ve regression test gerekir. Approval owner ayrı olabilir.

Metadata-as-Code Yaklaşımı

Metadata-as-Code, SEO kurallarını geçici e-tablo formülü yerine versionlanan ve test edilen kurallar olarak ele alır. Formula repository, test cases, expected outputs ve release notes bu yaklaşımın temelidir. Küçük ekip bile basit Git dosyasıyla başlayabilir. Spreadsheet kullanıcı arayüzü olarak kalırken core logic script veya documented formulas içinde saklanır. Bu model kurumsal otomasyonun sürdürülebilirliğini artırır.

Formula/Rule Repository

Formula definitions tek doküman veya code repository içinde tutulur. Sheet içindeki live formula tek source olmamalıdır. Named Function export veya documentation yapılabilir. Rule owner bellidir. Review history korunur.

Version Control

Git gibi sistem değişiklik geçmişi sağlar. Formula text plain file olarak saklanabilir. Apps Script veya Python zaten doğal olarak version control'a uygundur. Commit formula change reason içerir. Rollback daha kontrollüdür.

Test Cases

Normal ve edge case rows sabit dataset'te tutulur. Missing brand, long product ve Turkish character gibi örnekler bulunur. Her rule version test edilir. Unexpected output release blocker olabilir. Tests automation'a güven kazandırır.

Expected Outputs

Her sample input için beklenen title ve description tanımlanır. Formula result bunlarla karşılaştırılır. Intentional change expectation update gerektirir. Reviewer diff'i onaylar. Golden dataset zaman içinde büyür.

Change Review

Rule update en az bir başka ekip üyesi tarafından incelenebilir. SEO mantığı ve teknik formula birlikte değerlendirilir. High-impact change full-dataset preview alır. Comments decision history sağlar. Approved version release edilir.

Release Notes

Hangi template veya fallback'in değiştiği yazılır. Etkilenen page types belirtilir. Migration veya regenerate gereksinimi açıklanır. Batch publish date eklenir. Incident analysis için değerli referans olur.

Spreadsheet Formülleri Nasıl Test Edilir?

Spreadsheet formula da kod gibi test edilmelidir. Normal satır kadar eksik marka, eksik keyword, uzun ürün adı ve özel karakter gibi edge case'ler önemlidir. Beklenen output önceden belirlenmelidir. Formula update sonrası bütün test satırları yeniden çalıştırılır. Böylece küçük bir syntax değişikliğinin binlerce URL'yi bozması önlenir.

Normal Satır

Tüm source fields dolu standard case'tir. Expected title ve description açıkça belirlenir. Length ve QA pass olmalıdır. İlk smoke test budur. Ancak tek başına yeterli değildir.

Eksik Marka

Brand field blank test edilir. Separator kalmamalıdır. Final text doğal görünmelidir. Brand required page type farklı sonuç verebilir. QA expected status kontrol edilir.

Eksik Keyword

Fallback hierarchy çalışmalıdır. Secondary veya product name seçilebilir. Missing keyword warning beklenebilir. Output tamamen boş kalmamalıysa policy uygulanır. Test result document edilir.

Çok Uzun Ürün Adı

Title limit aşımı test edilir. Formula low-priority fields çıkarıyor mu kontrol edilir. Hard truncation varsa kelime bütünlüğü incelenir. Review status beklenebilir. Extreme length regression case olarak kalır.

Özel Karakter

Türkçe karakter, ampersand ve punctuation sample içinde olmalıdır. Encoding korunur. CSV export sonrası da doğrulanır. Regex yanlış character silmemelidir. Display metadata doğal kalmalıdır.

Duplicate Kayıt

İki row aynı normalized title üretir. Duplicate flag beklenir. Unique ID yine farklı olabilir. Overall QA status policy'ye göre oluşur. Fix template test edilebilir.

Beklenen Output

Expected values test fixture olarak tutulur. Formula result exact compare edilir. QA status da expectation'a dahil edilebilir. Intentional rule change review edilerek expected value güncellenir. Regression otomatikleşebilir.

Formula Regression Testing

Regression testing yeni formula version'ının daha önce çalışan satırları beklenmedik biçimde bozup bozmadığını kontrol eder. Sample dataset eski ve yeni rule ile çalıştırılır. Diff summary çıkarılır. Beklenen değişiklikler onaylanırken sürpriz sonuçlar incelenir. Bu yaklaşım özellikle binlerce URL'lik SEO otomasyonunda kritik güvence sağlar.

Yeni Formula Sürümü

Yeni rule ayrı version olarak çalıştırılır. Production formula hemen overwrite edilmez. Sample ve mümkünse full dry-run yapılır. Performance cost da gözlemlenir. Approval sonrası rollout başlar.

Sample Dataset

Farklı page type ve edge cases içerir. High-value gerçek rows anonymized örnek olarak eklenebilir. Dataset stable tutulur. Yeni incident sonrası yeni case eklenir. Regression coverage zamanla büyür.

Eski Output

Current production version'ın sonucu baseline'dır. Snapshot values olarak tutulur. Formula recalculation baseline'ı değiştirmemelidir. New result bununla karşılaştırılır. Change count raporlanır.

Yeni Output

Candidate version output ayrı columns'ta bulunur. QA tekrar çalışır. Length ve duplicate rate değişimi hesaplanır. High-impact rows manual review alır. Approved difference release note'a girer.

Beklenmeyen Değişiklikleri Bulmak

Diff count expected kapsamı aşarsa release durdurulabilir. Örneğin brand change yalnız belirli pages'i etkilemelidir. Unrelated categories değişiyorsa formula reference hatası olabilir. Root cause düzeltilir. Yeni dry-run yapılır.

Collaborative Metadata Editing

Toplu metadata düzenleme çoğu zaman SEO, content, merchandising ve developer ekiplerinin birlikte çalışmasını gerektirir. Her rolün edit edebileceği alan farklı olmalıdır. Formula ve source columns protected tutulabilir. Approval owner yayın kararını verir. Bu yaklaşım yanlışlıkla formül silinmesi veya source verinin değiştirilmesi riskini azaltır.

SEO Ekibi

Template, keyword ve QA kurallarından sorumlu olabilir. Generated output ve diff review eder. High-value pages override yapabilir. Search performance monitoring yürütür. Formula change request oluşturur.

Content Ekibi

Description ve editorial title'larda human copy sağlar. Brand tone kontrol eder. Override columns'a edit yapabilir. Formula source alanlarına dokunmamalıdır. Review status güncelleyebilir.

Merchandising

Product name, category ve approved benefit source data sağlayabilir. Metadata doğrudan düzenlemek zorunda değildir. Data quality issue'larını çözer. New categories için template need bildirir. Source ownership netleşir.

Developer

API, Apps Script ve import automation'dan sorumlu olabilir. Schema değişikliklerini yönetir. CMS mapping test eder. Audit ve rollback mekanizmasını kurar. SEO rule decision'ını tek başına belirlememelidir.

Approval Owner

Final publish kararını verir. High-risk batch'leri review eder. Approval status edit yetkisine sahiptir. Release date ve batch planını koordine eder. Incident durumunda rollback owner ile çalışır.

Protected Columns

Source, generated formula ve final calculation columns kilitlenebilir. Override ve review fields editlenebilir bırakılır. Permission role bazında uygulanır. Protection security boundary olarak görülmemelidir. Audit ve backup yine gereklidir.

E-Tabloda Rol ve Yetki Yönetimi

Permission tasarımı collaborative spreadsheet'in güvenilirliğini belirler. Kaynak ve formula alanları yanlışlıkla değişmemelidir. Override alanları edit yapılabilirken approval yalnız yetkili kişilerde olmalıdır. Export tab çoğu kullanıcı için salt okunur tutulabilir. Bu ayrım workflow'u daha kontrollü hale getirir.

Source Columns: Kilitli

CMS export veya katalog source değerleri protected tutulur. Düzeltme gerekiyorsa source owner tarafından yapılır. Manual edit lineage'i bozabilir. Normalization helper kullanılır. Changes ayrı diff ile izlenir.

Formula Columns: Kilitli

Generated fields manual overwrite almamalıdır. Formula owner veya developer edit yetkisine sahip olabilir. Version change documented edilir. Accidental deletion önlenir. Named Functions merkezi yönetilebilir.

Override Columns: Editlenebilir

Content ve SEO ekipleri bu alanlarda çalışır. Validation text formatı kontrol edebilir. Editor metadata tutulabilir. Empty value generated output anlamına gelir. Manual clear operation ayrı policy gerektirebilir.

Approval Column: Yetkili Kullanıcı

Approval sadece designated role tarafından değiştirilebilir. Dropdown allowed values kullanılır. Timestamp automation eklenebilir. Approved-to-edit değişiklik sonrası status resetlenebilir. Böylece eski approval yeni metadata'ya yanlışlıkla taşınmaz.

Export Tab: Salt Okunur

Export tab generated snapshot olmalıdır. Kullanıcı burada edit yapmamalıdır. Only approved records bulunur. Values freeze edilebilir. Batch archive için kopya saklanır.

Metadata Workflow Durumları

Workflow status metadata projesinin hangi aşamada olduğunu görünür yapar. Not Started'dan Verified'a kadar ilerleyen basit lifecycle ekip koordinasyonunu kolaylaştırır. Generated ve QA Failed gibi otomatik durumlar olabilir. Approved insan kararını temsil eder. Published ve Verified production sürecini tamamlar.

Not Started

Henüz source veya generation işlemi tamamlanmamıştır. Owner atanabilir. Missing data burada ayrıştırılabilir. Dashboard backlog count gösterir. Automated job bu records'u işleyebilir.

Generated

Formula veya AI draft hazırdır. QA henüz geçmemiş olabilir. Generated timestamp eklenebilir. Formula version tutulur. Sonraki adım validation'dır.

QA Failed

Critical automated check başarısızdır. Issue reason listelenir. Export engellenir. Source veya formula fix gerekir. Re-run sonrası status güncellenir.

Review Required

Automated QA karar veremediğinde veya high priority olduğunda kullanılır. Human reviewer atanabilir. Override gerekli olabilir. Review deadline eklenebilir. Approval sonrası ilerler.

Approved

Final metadata publish için onaylanmıştır. Approval timestamp ve user saklanır. Sonradan final value değişirse approval reset edilmelidir. Export job bu records'u alır. Batch ID oluşturulabilir.

Exported

Import file veya API payload hazırlanmıştır. Production'a henüz gitmemiş olabilir. Export snapshot archive edilir. Changes bu aşamadan sonra freeze edilebilir. Publish owner devralır.

Published

CMS update işlemi tamamlanmıştır. Teknik success response alınmıştır. Ancak actual front-end henüz doğrulanmamış olabilir. Publish timestamp saklanır. Next status Verified'dır.

Verified

Expected metadata'nın production'da gerçekten göründüğü doğrulanmıştır. Re-export veya crawl kullanılır. Mismatch yoktur. Batch lifecycle tamamlanır. Performance monitoring devam edebilir.

Open Source ve İşbirliği ile Metadata Otomasyonu

Metadata spreadsheet template ve formula library açık kaynak olarak geliştirilebilir. Böyle bir proje SEO, spreadsheet logic ve automation becerilerini aynı yerde buluşturur. Apps Script veya n8n workflow entegrasyonları eklenebilir. GitHub repository test dataset ve contributor guidelines içerebilir. Örnek topluluk projelerini görmek için https://www.diyarbakiryazilim.com.tr/projects adresi kullanılabilir.

Açık Kaynak Spreadsheet Template

Template sample source, generated, override ve QA columns içerebilir. Gerçek müşteri verisi bulunmamalıdır. Documentation setup adımlarını açıklar. Version release kullanılabilir. Community contribution yeni page types ekleyebilir.

Formula Library

Common title, description ve normalization functions paylaşılabilir. Google Sheets ve Excel örnekleri ayrı tutulabilir. Test cases her formula ile birlikte gelir. Locale farkları document edilir. Pull request regression test gerektirebilir.

Apps Script

Export, QA veya batch publish helper scriptleri geliştirilebilir. Secrets repository'ye konulmamalıdır. Config example kullanılabilir. Error handling test edilir. License ve contribution rules açık olmalıdır.

n8n Workflow

Approval sonrası CMS sync gibi workflow tasarlanabilir. Spreadsheet trigger ve API node kullanılabilir. Credentials güvenli store'da tutulmalıdır. Rate limit ve rollback planlanır. Workflow export repository'de örnek olarak paylaşılabilir.

GitHub Repository

Formula docs, scripts ve sample CSV aynı repository'de tutulabilir. Issue tracker feature request toplar. Pull request code review sağlar. Release tags formula versioning'e yardımcı olur. Sensitive production data asla commit edilmemelidir.

Contributor Guidelines

Yeni contribution'ın test ve documentation standardı belirtilir. Formula naming convention açıklanır. SEO claim'leri kaynaklı ve kontrollü olmalıdır. Breaking change release process tanımlanır. New contributors daha hızlı adapte olur.

Test Dataset

Dummy product, category ve location rows içerir. Turkish character edge cases bulunur. Expected metadata values saklanır. Duplicate ve missing source örnekleri eklenir. Regression testing herkes tarafından tekrar edilebilir hale gelir.

Diyarbakır Yazılım Topluluğu İçin SEO Spreadsheet Lab Modeli

SEO spreadsheet laboratuvarı, yazılım ve dijital içerik becerilerini birlikte geliştirmek için iyi topluluk çalışması olabilir. Katılımcılar gerçek müşteri verisi yerine demo katalog üzerinde formül, regex, Apps Script ve QA deneyebilir. Bulk metadata template ortak repository'de geliştirilebilir. Workshop sonunda küçük CMS demo import süreci simüle edilebilir. Diyarbakır Yazılım Topluluğu hakkında bilgi için https://www.diyarbakiryazilim.com.tr/about adresi incelenebilir.

Google Sheets SEO Workshop

Workshop source-data tab ile başlayabilir. Katılımcılar generated title ve QA columns oluşturabilir. ARRAYFORMULA, MAP ve TEXTJOIN örnekleri uygulanabilir. Son bölümde import-ready tab hazırlanabilir. Sample dataset herkes için aynı olmalıdır.

Bulk Metadata Template

Ortak template product ve service page örnekleri içerebilir. Override ve approval workflow gösterilir. Config tab kullanılır. Dashboard temel KPI'ları özetler. GitHub üzerinden versionlanabilir.

Regex Workshop

URL parsing ve whitespace cleanup örnekleri çalışılabilir. Türkçe karakter testleri eklenir. Overly broad regex riskleri gösterilir. Test-first yaklaşım anlatılır. Real production data yerine dummy values kullanılmalıdır.

Apps Script Otomasyonu

Menu oluşturma ve batch export örneği geliştirilebilir. API yerine mock endpoint kullanılabilir. Error handling ve logging öğretilir. Trigger örneği gösterilir. Script source repository'de paylaşılabilir.

Open Source Formula Library

Katılımcılar farklı page type functions ekleyebilir. Her contribution test case getirir. Review formula readability ve SEO mantığını değerlendirir. Version tags kullanılabilir. Türkçe locale uyumluluğu ayrıca test edilir.

E-Ticaret Demo Kataloğu

Dummy ürün, category, price ve brand alanları bulunabilir. Thousands-row synthetic dataset performans testine yarar. Gerçek işletme bilgisi kullanılmaz. Metadata generation ve duplicate QA uygulanır. Final CSV simulated import için hazırlanır.

GitHub İşbirliği

Issue ve pull request süreçleri kullanılır. Contributor belirli formula veya test case üstlenebilir. Code review ekip çalışma pratiği sağlar. Release notes yazılır. Community knowledge kalıcı dokümana dönüşür.

Diyarbakır'daki Yazılımcılar Bu Alanda Hangi Yetkinlikleri Geliştirebilir?

Metadata otomasyonu yalnız SEO öğrenmek isteyenler için değil yazılım mantığını pratik veri problemi üzerinde çalışmak isteyenler için de faydalıdır. Spreadsheet logic koşullu düşünmeyi, regex veri temizlemeyi ve API entegrasyonu gerçek sistemlerle iletişimi öğretir. Python ve Apps Script kullanımı automation bakışını geliştirir. QA ve rollback yaklaşımı production düşüncesi kazandırır. Bu beceriler farklı veri ve yazılım projelerine doğrudan taşınabilir.

Spreadsheet Logic

IF, lookup ve array functions koşullu problem çözmeyi öğretir. Dependency mantığı görünürdür. Küçük data pipeline'ları spreadsheet içinde kurulabilir. Debug becerisi gelişir. Daha sonra programlama diline geçiş kolaylaşır.

Regex

Pattern matching veri temizlemede sık kullanılır. URL ve text normalization pratiği sağlar. Greedy veya boundary gibi kavramlar öğrenilir. Test cases önem kazanır. Python ve JavaScript regex bilgisine taşınabilir.

SEO Temelleri

Title, description, canonical ve robots gibi kavramlar öğrenilir. Search intent ve duplicate problemi anlaşılır. Technical SEO ile content workflow birlikte görülür. Automation'ın SEO stratejisinin yerine geçmediği fark edilir. Crawl ve verification pratiği gelişir.

Data Cleaning

Trim, missing value ve normalization gerçek dataset üzerinde öğrenilir. Source ve derived data ayrımı anlaşılır. Unique ID'nin önemi görülür. QA columns veri kalitesini görünür yapar. Bu beceriler data engineering'e temel sağlar.

Apps Script

JavaScript syntax gerçek spreadsheet problemi üzerinde öğrenilir. Range read-write ve trigger kullanılır. API call pratiği yapılır. Error handling eklenir. Small automation project portföye dönüşebilir.

API

CMS veya mock service ile request-response mantığı öğrenilir. Authentication ve rate limit kavramları görülür. JSON payload hazırlanır. Error status loglanır. Idempotent update düşüncesi gelişir.

Python

Pandas ile spreadsheet logic script'e taşınabilir. Unit test uygulanır. CSV ve API workflows birleştirilir. Büyük dataset performansı öğrenilir. Command-line veya scheduled job geliştirilebilir.

Automation

Manual step'lerin repeatable workflow'a dönüşmesi temel automation becerisidir. Approval ve human review korunur. Error ve rollback planlanır. Monitoring eklenir. Production zihniyeti gelişir.

Yazılımcı Olmak İçin Spreadsheet Formülleri Öğrenmek Faydalı mı?

Evet, spreadsheet formülleri programlama dilinin yerine geçmez ancak temel düşünme becerilerini geliştirebilir. Koşullu mantık, fonksiyon, dizi ve hata yönetimi doğrudan yazılım kavramlarıyla ilişkilidir. LAMBDA ve reusable function yaklaşımı abstraction fikrini öğretir. Küçük otomasyon problemlerini hızlı çözmek iş hayatında önemli avantajdır. Daha sonra JavaScript veya Python öğrenildiğinde birçok kavram tanıdık gelir.

Koşullu Mantık

IF ve IFS condition-result ilişkisini öğretir. Nested conditions complexity problemini gösterir. Helper columns refactoring benzeri düşünce sağlar. Edge case testing önem kazanır. Aynı mantık programlama dilinde devam eder.

Fonksiyonlar

Fonksiyon belirli input'u output'a dönüştürür. TEXTJOIN, LEN ve SUBSTITUTE buna örnektir. Reusable Named Function abstraction sağlar. Pure function mantığı görülebilir. Programlama eğitimine iyi zemin oluşturur.

Veri Yapıları

Rows records, columns fields olarak düşünülebilir. Tabular schema database düşüncesine yakındır. Unique ID primary key fikrini öğretir. Lookup relation kavramı join'e benzer. Structured data mantığı gelişir.

Diziler

ARRAYFORMULA ve MAP collections üzerinde işlem yapmayı öğretir. Tek cell yerine range düşüncesi vectorization'a benzer. Functional patterns ortaya çıkar. Large data performance konusu anlaşılır. Python NumPy veya Pandas geçişi kolaylaşabilir.

Hata Yönetimi

IFERROR hata durumuna kontrollü cevap verir. Ancak hatayı gizlemek risklidir. Validation ve error status ayrı tutulmalıdır. Bu düşünce try-catch mantığına taşınabilir. Production error handling için temel farkındalık sağlar.

LAMBDA

LAMBDA inline function kavramını öğretir. Variable naming okunabilirliği artırır. MAP ile birlikte functional composition görülür. Named Function reusable module benzeri davranır. Testability önem kazanır.

Otomasyon Mantığı

Tekrarlanan işi kurala dönüştürmek software thinking'in temelidir. Source, transformation ve output ayrımı data pipeline yaklaşımına benzer. QA ve approval workflow design öğretir. Script'e geçiş doğal olur. Spreadsheet küçük automation laboratuvarına dönüşür.

Kurumsal Metadata Spreadsheet Dashboard

Dashboard metadata operasyonunun durumunu yöneticiler ve ekip üyeleri için özetler. Toplam URL, missing metadata, duplicate, length issue, generated, overridden, approved ve published sayıları görülebilir. Trend verisi workflow hızını gösterir. Dashboard source of truth QA ve status alanlarından beslenmelidir. Manuel hesap yerine pivot veya formula summary kullanılabilir.

Toplam URL

Scope içindeki toplam unique ID sayısıdır. Duplicate ID hariç tutulmamalı, ayrı issue olarak gösterilmelidir. Page type breakdown faydalıdır. Active scope filter bilinmelidir. Dashboard denominator olarak kullanılır.

Missing Metadata

Final title veya required description empty rows sayılır. Existing missing ve generated missing ayrı metric olabilir. High priority count ayrıca gösterilir. Trend source cleanup ilerlemesini ölçer. Threshold alert belirlenebilir.

Duplicate Titles

Exact normalized duplicate rows sayılır. Duplicate group count ayrıca gösterilebilir. Site-wide ve category-level ayrım yapılabilir. New duplicate after formula change önemli metric'tir. High-impact groups review edilir.

Duplicate Descriptions

Exact ve template duplicate ayrılabilir. Description optional policy dashboard'a yansıtılmalıdır. High repetition category listelenebilir. Formula change sonrası trend izlenir. Human rewrite backlog'u planlanabilir.

Length Issues

Too short ve too long ayrı sayılır. Title ve description breakdown yapılır. Threshold config'ten gelir. Issue rate total URL'ye oranlanır. Manual override sonrası azalma görülebilir.

Generated

Generated metadata hazır records'u gösterir. QA veya approval henüz tamamlanmamış olabilir. Daily generation throughput ölçülebilir. Formula ve AI source ayrıştırılabilir. Cost analysis AI generation için eklenebilir.

Manually Overridden

Override dolu rows sayılır. Page type bazında yüksek oran template problemini gösterebilir. High-value pages doğal olarak yüksek olabilir. Override reason analysis yapılabilir. Formula improvement backlog'una veri sağlar.

Approved

Publish için hazır kayıt sayısıdır. QA pass ve human approval policy'ye göre oluşur. Backlog ile karşılaştırılır. Reviewer throughput görülebilir. Export job bu metric'i kullanabilir.

Published

Production'a gönderilmiş records'u gösterir. Verified ayrı metric olabilir. Publish failure count takip edilir. Batch trend görünür. Rollback event dashboard'a işaretlenebilir.

Metadata Otomasyon KPI’ları

Metadata otomasyonunun başarısı yalnız kaç URL üretildiğiyle ölçülmemelidir. Coverage, duplicate rate, QA pass, manual override, error ve publish success birlikte değerlendirilmelidir. Time per 1.000 URLs operasyon verimliliğini gösterir. Rollback rate kalite riskini görünür yapar. KPI'lar formül ve workflow iyileştirmelerini yönlendirmelidir.

Coverage Rate

Final metadata bulunan URL oranıdır. Required fields bazında hesaplanabilir. Missing source coverage'ı sınırlar. Yüksek coverage yanlış metadata pahasına artırılmamalıdır. QA pass ile birlikte okunmalıdır.

Duplicate Rate

Duplicate title veya description oranını gösterir. Exact ve near duplicate ayrılabilir. Formula version karşılaştırmasında önemlidir. Rate artarsa template çok generic olabilir. Category breakdown root cause verir.

QA Pass Rate

Automated quality rules'u geçen row oranıdır. Critical ve warning ayrı değerlendirilebilir. High pass rate source quality veya good formula gösterebilir. Rule çok gevşekse yanıltıcı olabilir. Human sample accuracy ile kalibre edilmelidir.

Manual Override Rate

Generated output'un ne kadarında insan değişikliği gerektiğini gösterir. High-value pages doğal olarak yüksek olabilir. Low-risk catalog'da yüksek oran formula problemidir. Override reason trendleri değerlidir. Template refinement bu metric'i azaltabilir.

Error Rate

Formula error, missing source veya import failure ayrı kategoriler olabilir. Overall error rate workflow health'i gösterir. Incident threshold tanımlanabilir. Error reason priority belirler. Time trend regression tespit eder.

Publish Success Rate

Attempt edilen update'lerin kaçının CMS'de doğru uygulandığını gösterir. API 200 tek başına verification değildir. Actual metadata check kullanılırsa metric daha güvenilir olur. Failed records retry edilir. Batch ve CMS endpoint bazında breakdown yapılabilir.

Time per 1.000 URLs

Operasyonun ölçek verimliliğini gösterir. Generation, QA, review ve publish süreleri ayrı ölçülebilir. Manual modelle karşılaştırma yapılır. Daha hızlı olmak kaliteyi düşürmemelidir. Automation ROI hesaplamasına yardımcı olur.

Rollback Rate

Publish edilen batch'lerin ne kadarında geri alma gerektiğini gösterir. Yüksek oran QA veya import process problemi olabilir. Root cause category tutulmalıdır. Formula regression ve CMS mapping ayrı incelenir. Hedef yalnız düşük rate değil güvenilir rollout'tur.

En Sık Yapılan Hatalar

Toplu metadata projelerinde en büyük hatalar genellikle formülün kendisinden değil veri ve workflow tasarımından kaynaklanır. Source üzerine yazmak, unique ID kullanmamak ve backup almamak geri dönüşü zor problemler yaratır. Formül ile manual output'u aynı hücrede tutmak sürdürülebilirliği bozar. Tek template'i bütün page type'lara uygulamak kaliteyi düşürür. Küçük batch, verification ve performance monitoring bu risklerin çoğunu azaltır.

Formülü Direkt Kaynak Verinin Üzerine Yazmak

Original data kaybolur. Diff ve rollback yapılamaz. Source hatası ile transformation ayrımı ortadan kalkar. Generated column ayrı olmalıdır. Raw export immutable tutulmalıdır.

Unique ID Kullanmamak

URL değişince record association bozulur. Duplicate update riski artar. Re-export comparison zorlaşır. Stable ID temel veri modeli olmalıdır. Missing ID import blocker olabilir.

Existing Metadata Backup Almamak

Toplu hata durumunda geri dönüş zorlaşır. Performance comparison yapılamaz. Existing strong title yanlışlıkla kaybolabilir. Backup değişiklikten önce alınmalıdır. Batch archive korunmalıdır.

Boş Alanları Hesaba Katmamak

Separator ve yarım cümle sorunları oluşur. Fallback hierarchy çalışmaz. Empty source yanlış default üretebilir. Required fields açık tanımlanmalıdır. Edge case testleri zorunludur.

Formül ve Manuel Çıktıyı Aynı Hücrede Tutmak

Manual edit formula'yı siler. Formula update insan düzenlemesini kaybeder. Audit mümkün olmaz. Generated, override ve final ayrılmalıdır. Bu mimari en temel kurallardan biridir.

Duplicate Kontrolü Yapmamak

Template binlerce aynı title üretebilir. Formula syntax doğru olsa bile SEO sonucu kötü olabilir. Exact duplicate otomatik bulunmalıdır. Near duplicate sampling yapılabilir. Publish gate duplicate rate'i izler.

Her Sayfa Tipine Aynı Title Şablonunu Uygulamak

Product ve blog intent'i farklıdır. Generic template relevancy'yi azaltır. Page type taxonomy kullanılmalıdır. Template mapping config'te tutulabilir. High-value pages manual edit alabilir.

Binlerce Kaydı Tek Seferde Import Etmek

Tek hata bütün siteyi etkileyebilir. Root cause ve rollback zorlaşır. Small batch rollout daha güvenlidir. Pilot category ile başlanmalıdır. Monitoring sonrası ölçek büyütülür.

Import Sonrası Kontrol Yapmamak

CMS update success actual frontend success değildir. Re-export ve crawl yapılmalıdır. Encoding ve truncation sorunları ancak sonra görülebilir. Verified status ayrı tutulmalıdır. Production check workflow'un zorunlu parçasıdır.

Formula Performance’ını İzlememek

Sheet büyüdükçe recalculation süresi artabilir. Full-column ranges ve regex maliyeti gizlenir. Kullanıcı çalışma deneyimi bozulur. Belirli noktada script'e geçmek gerekir. Performance teknik borç gibi yönetilmelidir.

30 Günlük Toplu Metadata Otomasyon Planı

Metadata otomasyonuna kontrollü geçiş dört haftalık bir pilot planla yapılabilir. İlk hafta veri modeli, ikinci hafta formula layer, üçüncü hafta QA ve override, son hafta export ve pilot yayına ayrılır. Her aşama bir sonraki için quality gate oluşturur. İlk ay bütün siteyi güncellemek yerine sistemi doğrulamak hedeflenmelidir. Pilot sonrası KPI ve hata oranına göre kapsam büyütülebilir.

1–7. Gün: Veri Modeli

İlk hafta URL ve ID inventory hazırlanır. Source columns ve page types tanımlanır. Existing metadata backup alınır. Unique ID quality check yapılır. Config tab ve ownership modeli oluşturulur.

URL/ID Inventory

Tüm kapsam unique ID ve URL ile listelenir. Duplicate ve missing key bulunur. Existing metadata eklenir. Page status veya priority alınabilir. Dataset başlangıç snapshot'ı kaydedilir.

Source Columns

Keyword, product, category, brand ve location alanları belirlenir. Required ve optional columns document edilir. Raw ve normalized alanlar ayrılır. Missing source rate ölçülür. Owner ataması yapılır.

Page Types

Product, category, service ve blog taxonomy oluşturulur. Her type için template ihtiyacı tanımlanır. Unknown type ayrı queue olur. Page type validation dropdown kullanılabilir. İlk test sample'ları bu gruplardan seçilir.

8–14. Gün: Formula Layer

İkinci hafta generated title ve description formülleri geliştirilir. Normalization ve fallback helper'ları eklenir. Formula version v1 olarak kaydedilir. Test dataset üzerinde edge cases çalıştırılır. Full dataset dry-run sonunda change count ölçülür.

Title

Page type bazlı title templates geliştirilir. Separator ve brand config'ten gelir. Empty handling test edilir. Length QA helper eklenir. Duplicate risk dry-run'da incelenir.

Description

TEXTJOIN ve conditional fields kullanılır. CTA page type'a göre config'ten seçilebilir. Missing benefit doğal biçimde atlanır. Length ve duplicate checks eklenir. Human sample quality review yapılır.

Validation

Required fields ve formula errors kontrol edilir. Test cases expected output ile karşılaştırılır. Turkish characters ve long names included edilir. Critical issue formulası hazırlanır. QA status v1 oluşur.

15–21. Gün: QA ve Override

Üçüncü hafta automated QA ve human workflow kurulur. Duplicate, length ve approval mekanizması tamamlanır. Override columns protected formula yapısından ayrılır. High priority pages manual-only olarak işaretlenebilir. Reviewer feedback formula improvement için toplanır.

Duplicate

Title ve description exact duplicate ölçülür. Normalized helper kullanılır. Category-level groups incelenir. High duplicate template düzeltilir. Near-duplicate sample manuel incelenebilir.

Length

Min ve max thresholds config'te tanımlanır. Too short ve too long status oluşur. Automatic truncation yerine review tercih edilir. Formula field priority gerekirse güncellenir. Override sonrası final length tekrar kontrol edilir.

Approval

Approval workflow ve roles tanımlanır. QA pass low-risk rows auto-ready olabilir. High priority human approval ister. Approval timestamp saklanır. Final change sonrası approval reset mekanizması düşünülür.

22–30. Gün: Export ve Pilot

Son hafta values-only export tab hazırlanır. Backup doğrulanır ve küçük batch production'a gönderilir. Re-export ile expected vs actual kontrol edilir. Rollback prosedürü test edilir. Pilot KPI'ları kabul edilebilir durumdaysa sonraki ay kapsam büyütülür.

Backup

Original metadata ve working file archive edilir. Batch ID oluşturulur. Import file snapshot saklanır. Previous values ayrı rollback sheet'te hazırdır. Access ve naming standard kontrol edilir.

Small Batch

Temsilci 20 veya 50 URL ilk production batch olabilir. Farklı page type included edilir. Publish outcome kaydedilir. Search impact için hemen sonuç beklenmemelidir. Teknik verification önce tamamlanır.

Verification

CMS re-export ve crawler kullanılır. ID mapping ve UTF-8 kontrol edilir. Final title-description exact compare edilir. Missing updates ayrı retry listesine alınır. Verified status set edilir.

Rollback Test

Pilot içinden kontrollü örnek previous value'ya geri alınabilir. Procedure gerçekten çalışıyor mu görülür. Restore sonrası yeniden doğrulama yapılır. Runbook güncellenir. Gerçek incident öncesi ekip hazır hale gelir.

Toplu Metadata Spreadsheet Kontrol Listesi

Kontrol listesi production öncesi temel riskleri tek yerde toplar. Unique ID, source-output ayrımı, fallback, duplicate, length ve override yapısı doğrulanmalıdır. Approval ve backup olmadan import başlatılmamalıdır. Small batch ve post-import verification sürecin zorunlu parçası olmalıdır. Rollback dosyasının gerçekten kullanılabilir olduğu önceden kontrol edilmelidir.

Her satırın unique ID’si var mı?

Her record stable key taşımalıdır. Missing ve duplicate ID critical issue'dur. URL tek başına yeterli olmayabilir. ID CMS ile eşleşmelidir. Import bu kontrol geçmeden başlamamalıdır.

Kaynak ve output sütunları ayrıldı mı?

Raw source değişmeden korunmalıdır. Generated output başka columns'ta olmalıdır. Override ve final ayrıca ayrılmalıdır. Diff böylece yapılabilir. Lineage açık kalır.

Formüller satır bağımsız mı?

Her row yalnız kendi source values'ını kullanmalıdır. Sort ve filter sonrası association korunmalıdır. Excel structured reference veya MAP yaklaşımı tercih edilebilir. Cross-row temporary reference'lardan kaçınılır. Test ile doğrulanır.

Boş alan fallback’i var mı?

Required ve optional fields tanımlıdır. Empty brand veya keyword behavior bellidir. Separator artığı oluşmaz. Critical missing source output'u engelleyebilir. Fallback usage QA'da görünürdür.

Duplicate kontrolü var mı?

Final title ve description normalized duplicate check almalıdır. Exact duplicate minimum gereksinimdir. Near duplicate sample düşünülebilir. Duplicate group priority page value ile belirlenir. Rate dashboard'da izlenir.

Length QA var mı?

LEN ve threshold status bulunmalıdır. Title ve description ayrı kurallar kullanır. Character count absolute quality değildir. Warning veya review trigger görevi görür. Override sonrası yeniden hesaplanır.

Manuel override alanı var mı?

Human edit generated formula'dan ayrıdır. Override boşsa generated value kullanılır. Doluysa human value korunur. Editor metadata opsiyonel olarak kaydedilir. High-value pages bu alanı sık kullanabilir.

Final output ayrı mı?

CMS yalnız final value almalıdır. Generated veya override doğrudan import edilmez. Selection logic tek yerde bulunur. Final üzerinde last QA çalışır. Export values-only olur.

Approval status var mı?

QA OK otomatik publish anlamına gelmemelidir. Human veya policy-based approval bulunmalıdır. High priority page rules açık olmalıdır. Approved status değişiklik sonrası resetlenebilir. Export yalnız approved records'u alır.

Existing metadata backup alındı mı?

Pre-change export saklanmalıdır. ID ve old values bulunmalıdır. File immutable tutulur. Encoding doğrulanır. Rollback buna dayanır.

Import küçük batch ile test edildi mi?

Pilot batch gerçek CMS behavior'ını gösterir. Mapping ve encoding kontrol edilir. Sample page types temsil edilmelidir. Success sonrası batch büyütülür. Test atlanmamalıdır.

Import sonrası tekrar doğrulandı mı?

Re-export ve crawl yapılmalıdır. Expected vs actual karşılaştırılır. Missing update ve truncation bulunur. Published ile Verified status ayrılır. Silent import failure yakalanır.

Rollback dosyası hazır mı?

Previous values import-ready formatta bulunmalıdır. Batch ID açık olmalıdır. Procedure test edilmiş olmalıdır. Owner kim olduğu bilinmelidir. Rollback teorik değil uygulanabilir süreç olmalıdır.

Sıkça Sorulan Sorular

E-tablo tabanlı metadata otomasyonunda en sık sorulan sorular formül seçimi, duplicate kontrolü, manual override ve büyük katalog ölçeği çevresinde toplanır. Google Sheets ve Excel farklı syntax kullansa da temel row-level data modeli aynıdır. Source, generated, override ve final ayrımı çoğu problemi sadeleştirir. QA ve rollback sistemi olmadan bulk update güvenli kabul edilmemelidir. Aşağıdaki cevaplar uygulamada karşılaşılan temel kararları özetler.

Google Sheets ile toplu meta title nasıl oluşturulur?

Her satırda keyword, product, category ve brand gibi kaynak kolonlar tutulur. Basit yapıda ARRAYFORMULA, daha karmaşık row logic için MAP + LAMBDA kullanılabilir. Empty fields koşullu biçimde atlanmalıdır. Generated title ayrı sütunda tutulmalı ve length ile duplicate QA yapılmalıdır. Final title override ve approval mekanizmasından sonra export edilmelidir.

Meta description’lar formülle oluşturulabilir mi?

Evet, özellikle structured product ve service pages için oluşturulabilir. TEXTJOIN ve IF koşullu alanları birleştirmeyi kolaylaştırır. Ana konu, benefit ve CTA yalnız source mevcutsa eklenebilir. Template tekrar oranı duplicate QA ile izlenmelidir. High-value pages human edit alabilir.

Satır bağımsız formül nedir?

Her kaydın yalnız kendi satırındaki source values ile output üretmesidir. Bir row'daki hata diğer row'ları etkilemez. Sort veya filter sonrası relation korunur. Stable ID record identity sağlar. Spreadsheet'ten script'e geçişi kolaylaştırır.

ARRAYFORMULA nedir?

Google Sheets'te tek formülün bir range için çoklu sonuç üretmesini sağlar. Fill down ihtiyacını azaltır. Basit metadata columns için güçlüdür. Generated area manual edit kabul etmez. Karmaşık row logic'te MAP daha okunabilir olabilir.

MAP ile ARRAYFORMULA arasındaki fark nedir?

ARRAYFORMULA array operation'ı genel biçimde uygular. MAP her input item için explicit LAMBDA çalıştırır. Birden fazla source column ve conditional logic MAP ile daha anlaşılır olabilir. İki yaklaşım aynı projede kullanılabilir. Performance gerçek dataset üzerinde test edilmelidir.

BYROW ne işe yarar?

Bir row içindeki birden fazla alanı birlikte function'a verir. QA score ve complex validation için faydalıdır. Row-level business rules yazılabilir. Column order dependency dikkat gerektirir. Named Function ile okunabilirlik artırılabilir.

Excel structured reference nedir?

Excel Table içindeki columns'u isimle referans etmeyi sağlar. Hücre adresi yerine column name kullanılır. Current row relation daha güvenilir olur. New row formula'yı otomatik alabilir. Büyük metadata tablolarında güçlü yaklaşım sunar.

E-tabloda duplicate meta title nasıl bulunur?

Final title normalize edilip COUNTIF ile sayılabilir. Count birden büyükse duplicate flag verilir. TRIM, lowercase ve whitespace cleanup kullanmak faydalıdır. Turkish character behavior test edilmelidir. Near-duplicate için script veya similarity yöntemi gerekebilir.

Meta title uzunluğu nasıl kontrol edilir?

LEN karakter sayısını hesaplar. Minimum ve maximum threshold üzerinden status üretilebilir. Conditional formatting sorunları görsel hale getirir. Character length tek quality metric değildir. Relevance ve duplicate ayrıca kontrol edilmelidir.

Formülle üretilen metadata manuel düzenlenebilir mi?

Evet, ancak generated hücre doğrudan edit edilmemelidir. Ayrı override column kullanılmalıdır. Final output override varsa onu seçer. Formula update manual edit'i silmez. Bu hibrit model en güvenli yaklaşımlardan biridir.

Formül değişince manuel metadata nasıl korunur?

Generated ve override ayrı tutulursa korunur. Formula yalnız generated column'u etkiler. Final value override doluysa insan değerini kullanır. Formula version change impact report hazırlanabilir. Override rows protected kabul edilebilir.

Binlerce URL Google Sheets’te yönetilebilir mi?

Evet, fakat formül performansı izlenmelidir. Full-column references ve ağır regex azaltılmalıdır. Batch ve category segmentation kullanılabilir. On binlerce satırdan sonra Apps Script veya Python daha uygun olabilir. Spreadsheet human review layer olarak kalabilir.

Ne zaman Apps Script kullanılmalıdır?

Repeated button action, batch export veya API integration gerektiğinde değerlidir. Formula'nın yapamadığı workflow otomasyonu sağlar. Rate limit ve error handling gerekir. Sheet schema stable olmalıdır. Small-to-medium automation için iyi ara adımdır.

Ne zaman Python’a geçilmelidir?

Data çok büyüdüğünde veya güçlü API ve validation ihtiyacı oluştuğunda Python mantıklıdır. Pandas büyük catalog işlemlerini kolaylaştırır. Tests ve version control daha güçlü hale gelir. Scheduled pipeline kurulabilir. Spreadsheet yalnız approval interface olabilir.

AI ile toplu meta description üretmek güvenli midir?

Doğru guardrail ile kullanılabilir ancak tamamen risksiz değildir. Model yalnız source columns'tan bilgi kullanmalıdır. Unsupported feature üretmemesi istenmelidir. Formula length ve duplicate QA yapmalıdır. High-risk pages human approval almalıdır.

Shopify metadata spreadsheet ile toplu güncellenebilir mi?

Birçok e-ticaret sisteminde CSV veya API tabanlı bulk update yaklaşımı mümkündür ancak kullanılan platformun güncel import alanları ayrıca kontrol edilmelidir. Stable product veya variant ID korunmalıdır. Önce export ve backup alınmalıdır. Small batch test zorunlu tutulmalıdır. Platform-specific alan eşleştirmesi production öncesi doğrulanmalıdır.

WordPress metadata e-tabloyla toplu düzenlenebilir mi?

WordPress tabanlı sitelerde eklenti, CSV veya API yaklaşımına göre bulk metadata workflow kurulabilir. Hangi metadata alanının nerede saklandığı kullanılan yapılandırmaya bağlıdır. E-tablo final values hazırlamak için kullanılabilir. Import öncesi backup alınmalıdır. Actual HTML metadata crawl ile doğrulanmalıdır.

Open source metadata otomasyonu yapılabilir mi?

Evet, spreadsheet template, formula library ve scripts açık repository'de paylaşılabilir. Sample data gerçek müşteri bilgisi içermemelidir. Test dataset ve contributor rules eklenebilir. Apps Script veya Python tools aynı workflow'u destekleyebilir. Açık kaynak yaklaşım ekip içinde ortak öğrenmeyi kolaylaştırır.

E-tablo formülleriyle satır bazında toplu meta veri düzenleme nasıl yapılır?

Önce her URL için stable ID ve gerekli source columns hazırlanmalıdır. Generated title ve description değerleri her satırın kendi keyword, product, category veya location bilgisinden oluşturulmalıdır. E-Tablo Formülleriyle Satır Bağımsız Toplu Meta Veri Düzenleme yapılırken generated, override ve final sütunları birbirinden ayrılmalı, duplicate ve length QA ayrı çalıştırılmalıdır. Onaylanan final values import-ready tab'a values-only olarak taşınmalıdır. Küçük batch ile publish edildikten sonra yeniden export ve crawl ile doğrulama yapılmalıdır.

Excel veya Google Sheets’te her satır için bağımsız meta title ve meta description nasıl oluşturulur?

Excel'de Table ve structured references, Google Sheets'te MAP, BYROW veya ARRAYFORMULA kullanılabilir. Her formula aynı satırdaki source values'ı okuyacak biçimde kurulmalıdır. E-tabloda her satır için dinamik meta title description formülü oluşturma yaklaşımında boş alan ve fallback davranışları açıkça tanımlanmalıdır. Formül sütunlarına manual edit yapılmamalı, ayrı override alanı kullanılmalıdır. Final output üzerinden yeniden QA çalıştırılması güvenilirliği artırır.

CONCATENATE, TEXTJOIN ve IF gibi formüller toplu SEO meta veri üretiminde nasıl kullanılır?

CONCATENATE basit string birleştirme yapabilir ancak boş alan yönetiminde TEXTJOIN çoğu zaman daha rahattır. TEXTJOIN boş değerleri atlayarak product, category ve brand parçalarını gereksiz separator oluşturmadan birleştirebilir. IF ve IFS sayfa tipi veya source varlığına göre hangi parçanın kullanılacağını belirler. Excel ve Google Sheets ile toplu SEO metadata düzenleme hizmeti tasarlanırken bu formüller helper columns ve QA rules ile birlikte kullanılmalıdır. Karmaşıklık arttığında LAMBDA veya script yaklaşımına geçmek daha okunabilir olabilir.

Binlerce URL için benzersiz meta veriler oluştururken karakter sınırı ve tekrar eden içerik nasıl kontrol edilir?

LEN karakter sayısını hesaplayarak kısa veya uzun değerleri warning olarak işaretleyebilir. COUNTIF normalized title veya description üzerinde exact duplicate kontrolü yapabilir. Near-duplicate metadata için template extraction veya script tabanlı similarity analizi kullanılabilir. Her page type farklı source fields kullandığında benzersizlik doğal olarak artar. Binlerce URL için Excel formülleriyle toplu SEO metadata optimizasyonu yapılırken automated QA bütün satırlarda, human review ise risk bazlı sampling ile uygulanabilir.

Toplu meta veri düzenleme ve SEO otomasyonu konusunda yakınımda danışmanlık nerede bulabilirim?

Toplu metadata ve teknik SEO danışmanlığı yakınımda araması yapıyorsanız yalnız title üretmeye değil veri modeli, QA, import ve rollback süreçlerini birlikte ele alan çalışma yaklaşımını tercih etmek faydalıdır. Diyarbakır'da yazılım, veri, otomasyon ve SEO projeleriyle ilgilenenler https://www.diyarbakiryazilim.com.tr üzerinden Diyarbakır Yazılım Topluluğu'na ulaşabilir. Topluluk projelerine https://www.diyarbakiryazilim.com.tr/projects adresinden göz atabilirsiniz. Excel ve Google Sheets ile toplu SEO metadata düzenleme hizmeti planlanırken stable ID, formula versioning, approval, batch publishing ve rollback mekanizmaları birlikte değerlendirilmelidir. Bu yaklaşım kısa süreli tablo düzenlemesini sürdürülebilir SEO otomasyon sistemine dönüştürür.

Sonuç

E-Tablo Formülleriyle Satır Bağımsız Toplu Meta Veri Düzenleme, yüzlerce veya binlerce URL üzerinde çalışırken hız kazanmanın yanında kontrolü korumayı da sağlayan güçlü bir yöntemdir. Sağlam yapı source data, normalization, generated output, QA, manual override, final output, approval ve export katmanlarını birbirinden ayırır. Pratikte en güvenilir yaklaşım düşük riskli ve yapısal sayfalarda deterministic formülleri kullanmak, yüksek değerli sayfalarda insan kontrolünü korumak ve bütün değişiklikleri küçük batch'lerle yayınlamaktır. Yapılandırılmış veri tarafında benzer otomasyon mantıklarını incelemek için https://www.diyarbakiryazilim.com.tr/posts/blog-ve-kurumsal-iceriklerde-json-ld-schema-manipulasyonu içeriğine göz atabilirsiniz. Spreadsheet otomasyonu, SEO, açık kaynak ve ortak proje çalışmaları hakkında daha fazla bilgi almak için https://www.diyarbakiryazilim.com.tr/about ve https://www.diyarbakiryazilim.com.tr adresleri üzerinden Diyarbakır Yazılım Topluluğu'na ulaşabilirsiniz.