İzlediğimiz yazılım geliştirme standartları

Bir işin bitmiş sayılması için doğru olması gerekenleri açıkça yazan ortak tanım.

Nasıl uyguluyoruz Her değişiklikten önce aynı kontrol çalışır: şablon, YAML ve servis kapsayıcısı denetimi, statik analiz, testler ve canlı sayfa kontrolü. Biri geçmezse iş bitmemiştir.

Belgeler depoda düz metin olarak durur ve kodla aynı incelemeden geçer.

Nasıl uyguluyoruz Mimari kararlar, modül belgeleri, yayın adımları ve iş planları depoda Markdown olarak tutuluyor ve kodla aynı değişiklikte güncelleniyor.

Her değişiklik birleştirilmeden önce yazarından başka biri tarafından okunur.

Nasıl uyguluyoruz Değişiklikler yazılı bir inceleme listesinden geçiyor; bir kısmı GitLab birleştirme isteğiyle birleştiriliyor. Tek geliştiricili işlerde inceleme araç destekli yapılıyor, ikinci bir kişi tarafından değil.

Yinelemeli ve iş birliğine dayalı teslim için dört değer ve on iki ilke.

Nasıl uyguluyoruz İşi küçük paketler halinde yayına alıyor, sonucu canlı sistemde ölçüyor ve her aşamada proje sahibinin kararlarını yazılı tutuyoruz.

Belgeleri öğretici, nasıl yapılır, başvuru ve açıklama olarak dört türe ayıran çerçeve.

Nasıl uyguluyoruz Kararların gerekçesi, modül başvuru belgeleri ve adım adım yayın rehberleri ayrı yerlerde duruyor; belgeler türe göre etiketli değil ve öğretici türünde belge yok.

Taşınabilir servisler için on iki kural: yapılandırma ortamda, derleme, sürüm ve çalıştırma ayrı, geliştirme ile canlı ortam aynı.

Nasıl uyguluyoruz Yapılandırma ortam değişkenlerinden okunuyor, paket bir kez derlenip yayına alınıyor ve geliştirme, test ve canlı ortam aynı PHP sürümünü kullanıyor. Tek bilinçli istisna: loglar sunucu yapısı gereği dosyaya yazılıyor.

Bağlamı, kararı ve sonuçlarını anlatan, kodun yanında tutulan kısa ve numaralı belgeler.

Nasıl uyguluyoruz Teknoloji yığını, yazı tipleri, yayın hattı, pazar bazlı yerelleştirme ve dil politikası gibi kararlar numaralı karar kayıtları olarak depoda duruyor.

Uygulamanın çekirdeği dış dünyayla yalnızca portlar üzerinden konuşur; e-posta, HTTP ve dış servisler için adaptörler bu portları uygular.

Nasıl uyguluyoruz E-posta, CRM ve bot doğrulaması için portlar ve onları uygulayan adaptörler kullanıyoruz; bağımlılık kuralını denetleyen bir test henüz yok.

Bağımlılıklar iş kurallarına doğru içeri bakar; çatı ve giriş çıkış işleri kenarda kalır.

Nasıl uyguluyoruz Girdiler ve sonuçlar değiştirilemez veri nesneleriyle taşınıyor, iş mantığını yürüten servisler HTTP isteğini bilmiyor.

HTTP yöntemleri, durum kodları, içerik anlaşması ve Retry-After gibi başlıklar.

Nasıl uyguluyoruz İletişim formu her sonuç için doğru durum kodunu döner: 200, 303, 403, 422, 503 ve Retry-After ile 429; dış servisin Retry-After başlığına da uyuyoruz.

Uzak çağrıların zaman aşımı vardır, başarısız çağrı artan aralıklarla yeniden denenir ve iş bu arada bir kuyrukta korunur.

Nasıl uyguluyoruz CRM çağrısının beş saniyelik zaman aşımı var; geçici hatada gönderim kuyruğa alınıyor ve zamanlanmış bir görevle yeniden deneniyor. E-posta ve CRM birbirinden bağımsız çalışıyor.

Sunucu tarafındaki bir istemcinin kimlik bilgileriyle erişim belirteci aldığı yetkilendirme çerçevesi.

Nasıl uyguluyoruz Bu site ONLINEKURUM API'sine istemci kimlik bilgileriyle bağlanıyor, aldığı belirteci süresi boyunca saklıyor ve 401 yanıtında bir kez yeniliyor.

Önbelleğe alınabilir kaynaklar üzerinde durumsuz istemci sunucu etkileşimi; model, HTTP API'lerini olgunluk düzeyine göre sınıflar.

Nasıl uyguluyoruz Site durumsuz çalışıyor, GET sayfaları önbelleğe alınabiliyor ve form tek bir kaynağa her sonuç için ayrı durum koduyla yanıt veriyor.

Yazılımı ortak bir dil, değer nesneleri ve açık sınırlarla iş alanının modeli üzerine kurmak.

Nasıl uyguluyoruz Sınıflarımızı iş alanının adlarıyla adlandırıyor, dil gibi kavramları değer nesnesi olarak modelliyoruz; site tek ve küçük bir bağlam olduğu için ayrı sınırlar yok.

Parçaları uyumsuz değişiklik, yeni özellik ya da düzeltme anlamına gelen MAJOR.MINOR.PATCH numaraları.

Nasıl uyguluyoruz Bağımlılıkları anlamsal sürüm kısıtlarıyla tanımlıyoruz; sitenin kendisi sürüm etiketi taşımıyor.

declare(strict_types=1) sessiz tip dönüşümünü TypeError hatasına çevirir.

Nasıl uyguluyoruz Uygulama ve test kodundaki her sınıf dosyası, çatının Kernel sınıfı hariç, katı tip denetimiyle başlıyor ve inceleme listesi bunu kontrol ediyor.

Kodu çalıştırmadan, kural düzeylerine göre ne kadar sıkı denetleneceğini belirleyen analiz.

Nasıl uyguluyoruz PHPStan 6. düzeyde uygulama, test ve yapılandırma kodunu tarıyor; her değişiklikten önce ve sürekli entegrasyonda çalışıyor.

PHP-FIG'in, PSR-12'nin yerini alan ve Symfony'nin kod standardının dayandığı yaşayan biçim standardı.

Nasıl uyguluyoruz Kodu bu stille yazıyoruz: önce katı tip bildirimi, EditorConfig ile dört boşluk, Symfony alışkanlıkları. Otomatik bir biçim denetleyicisi henüz yok, yani standart uygulanıyor ama zorunlu kılınmıyor.

Bir ad alanı önekini bir klasöre eşleyerek sınıfın tam adından bulunmasını sağlar.

Nasıl uyguluyoruz Uygulama ve test sınıfları Composer üzerinden PSR-4 ile yükleniyor.

İnce controller, iş mantığı için servis, yönlendirme için öznitelik ve altyapı için ortam değişkeni öneren resmi rehber.

Nasıl uyguluyoruz Controller eylemleri yirmi satırın altında kalıyor, yönlendirmeler öznitelikle tanımlı ve altyapı ayarları ortam değişkenlerinden geliyor.

Tek sorumluluk, açık kapalı, Liskov yerine geçme, arayüz ayrımı ve bağımlılığın tersine çevrilmesi.

Nasıl uyguluyoruz Servisler tek bir iş yapıyor ve e-posta, CRM, bot doğrulaması ve dil ayarları gibi dış bağımlılıklara arayüz üzerinden bağlanıyor; bunu denetleyen bir mimari testi yok.

Blok, eleman ve değiştirici adlarıyla stili tek bir bileşene bağlayan adlandırma yöntemi.

Nasıl uyguluyoruz Bileşenlerimiz BEM ile adlandırılıyor ve bir test, şablonlarda kullanılan her sınıfın bir stil dosyasında tanımlı olduğunu denetliyor.

Karakter kümesini, girintiyi ve satır sonlarını her düzenleyicide aynı tutan dosya.

Nasıl uyguluyoruz Depodaki EditorConfig dosyası UTF-8, LF satır sonu, dört boşluk girinti ve dosya sonunda yeni satır kuralını tanımlıyor.

PHP dosyaları için temel kurallar: dosya başına bir bildirim, sınıf ve yöntem adlandırması, bildirimin yanında yan etki olmaması.

Nasıl uyguluyoruz Uygulama ve test kodu bu kurallarla yazılıyor; otomatik bir denetleyici yok.

Servislerin bir kütüphaneye değil ortak bir arayüze bağlanmasını sağlayan log arayüzü.

Nasıl uyguluyoruz Servisler log için PSR-3 arayüzünü alıyor; iletişim kayıtları ayrı bir kanalda tutuluyor.

Bağımlılık enjeksiyonu kapsayıcıları için ortak arayüz.

Nasıl uyguluyoruz Servisler Symfony kapsayıcısından kurucu üzerinden otomatik bağlanıyor.

Anlamlı adlar, küçük fonksiyonlar, tekrarsız kod ve neyi değil nedeni anlatan yorumlar.

Nasıl uyguluyoruz Değiştirilemez servisler ve veri nesneleri, niyetini söyleyen adlar ve kararların gerekçesini kaydeden sınıf yorumları kullanıyoruz; bunu ölçen bir araç yok.

Çok sayıda hızlı birim testi, daha az entegrasyon testi ve çok az uçtan uca test.

Nasıl uyguluyoruz Testler birim ve entegrasyon olarak iki takımda çalışıyor; bunların üstünde canlı sayfalara giden tek bir HTTP kontrolü var.

Hazır veriler ve doğrulamalarla otomatik testler; uygulama testleri istekleri gerçek çekirdek üzerinden gönderir.

Nasıl uyguluyoruz PHPUnit kullanımdan kalkma uyarısında, bildirimde ve uyarıda testi başarısız sayıyor; sayfalar entegrasyon testlerinde gerçek çekirdek üzerinden iki pazarda da üretiliyor.

Kod değiştikçe bir mimari ya da proje kuralını doğru tutan otomatik kontroller.

Nasıl uyguluyoruz Stil sınıflarının kapsamı, metin kuralları, iki pazarın çeviri eşitliği, İngilizce adresler, sayfa önbelleği ve içerik güvenlik politikası için koruyucu testler var; stil sınıfları, metin kuralları, çeviri eşitliği ve İngilizce adresler için olan koruyucu testler kendi kontrolünün başarısız olabildiğini de kanıtlıyor.

Bir yapının ana işlevinin çalıştığını, başka bir şey test edilmeden önce gösteren küçük kontrol kümesi.

Nasıl uyguluyoruz Yerelde ve her yayından sonra canlıda aynı adres listesi çağrılıyor; her sayfa yalnızca PHP'nin ürettiği bir işareti taşımak zorunda.

Önce başarısız bir test yazmak, sonra onu geçirmek ve ardından kodu düzenlemek.

Nasıl uyguluyoruz Her değişiklik kendi testleriyle birlikte geliyor ve her servisin ve veri nesnesinin testi var; testin kodun önünde yazıldığı ayrıca kayıt altında değil.

Davranışı iş dilinde anlatmak ve testleri bu anlatımdan türetmek.

Nasıl uyguluyoruz Testlerimizi davranışı anlatan adlarla yazıyoruz; Behat ya da Gherkin kullanmıyoruz.

Bir sitenin WCAG'ye ne kadar uyduğunu denetlemek için yöntem ve araçlar.

Nasıl uyguluyoruz Lighthouse erişilebilirlik puanını ölçüp sonucu (100) kaydettik; sürekli entegrasyonda çalışan otomatik bir erişilebilirlik testi henüz yok.

Her gönderim otomatik olarak derlenir ve ortak dala karşı test edilir.

Nasıl uyguluyoruz Her dalda sürekli entegrasyon işi denetimleri, statik analizi ve testleri çalıştırıyor.

Yazılım her zaman yayına hazırdır; tek bir paket bir kez derlenir ve otomatik bir hatla ilerler.

Nasıl uyguluyoruz Paket bir kez derleniyor ve canlıya o paket gidiyor; yayın betikleri sahte bir sunucuda uçtan uca prova edilebiliyor.

Yeni sürüm canlı sürümün yanında hazırlanır, trafik tek bir bağlantı değişimiyle geçer, geri alma da geri dönüş değişimidir.

Nasıl uyguluyoruz Her sürüm ayrı bir klasörde hazırlanıyor ve tek bir bağlantı değişimiyle canlıya geçiyor; son beş sürüm saklanıyor ve geri alma tek adımlık bir iş.

Commit başlıklarının tür ve kapsam taşıdığı, geçmişi insanlar ve araçlar için okunur kılan kural.

Nasıl uyguluyoruz Commit başlıklarımız feat, fix, docs ve test gibi türlerle yazılıyor; bunu zorlayan bir kanca yok.

Davranışın yayınla değil yapılandırmayla açılıp kapatılması.

Nasıl uyguluyoruz Sayfa önbelleği, bot doğrulaması ve CRM bağlantısı ortam değişkenleriyle açılıp kapanıyor; önbellek ilk kez kapalı yayına alındı ve test edildikten sonra açıldı.

Ortamların sürümlenen dosyalarla tanımlanması ve elle değil araçlarla kurulması.

Nasıl uyguluyoruz Geliştirme ortamı Docker dosyalarıyla, yayın hattı sürümlenen bir yapılandırmayla tanımlı ve sunucuda dosya elle düzenlenmiyor; barındırma hesabının ilk kurulumu ise elle yapıldı.

Özelliklerin bir geliştirme dalında toplandığı, sürümlerin ana dalda tutulduğu dallanma modeli.

Nasıl uyguluyoruz Özellik dalları geliştirme dalına, geliştirme dalı ana dala birleşiyor; sürüm ve acil düzeltme dalları ile sürüm etiketleri kullanmadığımız için modelin sadeleştirilmiş halini izliyoruz.

İstenen durum Git'te tanımlanır ve otomatik uygulanır; canlıya giden tek yol Git'tir.

Nasıl uyguluyoruz Ana dala gönderim yayına almanın tek yolu ve sunucu yapılandırması depoda sürümleniyor; sunucuyu Git'e göre sürekli eşitleyen bir ajan yok.

Servisleri hizmet düzeyi hedefleri, izleme, olay yönetimi ve suçlamasız değerlendirmelerle işletmek.

Nasıl uyguluyoruz Yayından sonra sağlık kontrolü ve geri alma yolu, saklama süreli dönen loglar kullanıyoruz; kesintisizlik izlemesi ve hizmet düzeyi hedefi tanımlı değil.

Betik, stil ve çerçeve kaynaklarını listeleyerek sayfaya sızdırılan satır içi kodu engelleyen başlık.

Nasıl uyguluyoruz Canlı politika unsafe-inline içermiyor, satır içi stil ve olay işleyicisi kullanmıyoruz ve bir test politikayı koruyor.

Her yanıtta Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy ve frame-ancestors.

Nasıl uyguluyoruz Bu başlıkların hepsi canlı sunucuda tanımlı ve HTTP istekleri kalıcı olarak HTTPS'e yönleniyor; yerel geliştirme de HTTPS ile çalışıyor.

CSRF önleme, girdi doğrulama, loglama ve sırlar gibi konularda kısa uygulama rehberleri.

Nasıl uyguluyoruz Form, Origin kontrolü ve çift gönderimli çerezle durumsuz CSRF koruması kullanıyor; girdiler izin listesiyle doğrulanıp kontrol karakterlerinden temizleniyor, loglarda e-posta adresi maskeleniyor.

İstek sınırları ve bot tuzakları formları kötüye kullanıma karşı korur.

Nasıl uyguluyoruz İletişim formu IP başına on beş dakikada beş gönderimle sınırlı; gizli bir tuzak alanı ve bot doğrulaması da var ve kontrollerin sırası sınıf yorumunda yazılı.

Her program ve kullanıcı yalnızca işinin gerektirdiği en küçük yetkiyle çalışır.

Nasıl uyguluyoruz Yayın yalnızca sürekli entegrasyona ait kısıtlı bir anahtarla yapılıyor, canlı ortam sırları yalnızca sahibinin okuyabildiği bir dosyada duruyor ve yalnızca giriş noktası çalıştırılabiliyor.

Sırlar depoya girmez, ortama göre ayrılır ve gönderimler sızıntıya karşı taranır.

Nasıl uyguluyoruz Depodaki yapılandırma sır taşımıyor, canlı sırlar korumalı sürekli entegrasyon değişkenlerinde duruyor ve yayın hattında otomatik sır taraması çalışıyor.

Veri korumanın tasarıma baştan dahil edilmesi: en az veriyi toplamak, varsayılan olarak korumak.

Nasıl uyguluyoruz Genel sayfalar çerez ve oturum kullanmıyor, analitik yalnızca izinden sonra yükleniyor ve iletişim kayıtları maskeli e-postayla sınırlı süre tutuluyor.

Türkiye'nin aydınlatma yükümlülüğünü ve rıza kurallarını içeren kişisel veri kanunu.

Nasıl uyguluyoruz Türkiye pazarında aydınlatma metni yayında ve form açık onay alıyor; metnin hukuki incelemesi bekleniyor.

Avrupa Birliği'nin hukuka uygunluk, veri en aza indirme, şeffaflık ve ilgili kişi hakları kurallarını içeren veri koruma tüzüğü.

Nasıl uyguluyoruz İngilizce pazarda GDPR yapısında ayrı bir gizlilik bildirimi yayında ve bir test her pazarın kendi bildirimini taşıdığını denetliyor; hukuki inceleme bekleniyor.

Web uygulamaları için en kritik on risk kategorisi.

Nasıl uyguluyoruz Birkaç kategoriye karşı kontrolümüz var: erişim kısıtları, güvenlik başlıkları, doğrulama ve otomatik kaçırma, güvenlik logları. Listeyi rehber olarak izliyoruz; kategori kategori bir denetim belgesi yok.

CVE verilerine göre sıralanmış en tehlikeli 25 yazılım zayıflığı türü.

Nasıl uyguluyoruz XSS'e karşı şablon motorunun otomatik kaçırmasını, CSRF'ye karşı token korumasını kullanıyoruz; listeyi rehber olarak izliyoruz, zayıflık eşlemesi yok.

Yazılım tedarik zincirinde derleme kökeni ve kaynak bütünlüğü için düzeyler.

Nasıl uyguluyoruz Paketler sürümlenen bir hatla barındırılan bir çalıştırıcıda derleniyor ve her paket hangi commit'ten geldiğini kaydediyor; köken belgesi üretmiyoruz ve düzey değerlendirmesi yapılmadı.

Zorunlu olmayan çerezler ancak açık bir bilgilendirme ve onaydan sonra kullanılır.

Nasıl uyguluyoruz Analitik çerezleri yalnızca "İzin ver" seçildikten sonra yükleniyor; onay ekranı pazarın kuralına göre gösteriliyor ve testlerle korunuyor.

Alıcının gönderen alan adını doğrulamasını sağlayan DNS kayıtları.

Nasıl uyguluyoruz Form e-postası kendi alan adımızdan gönderiliyor, yanıt adresi ziyaretçi oluyor; DNS kontrol listesi yayın belgesinde yazılı.

Erişilebilir içerik için A, AA ve AAA düzeylerinde başarı ölçütleri.

Nasıl uyguluyoruz Sayfaları bu ölçütlere göre kuruyoruz: içeriğe geç bağlantısı, sayfa dili, görünür odak ve azaltılmış hareket desteği; resmi bir uygunluk denetimi yapılmadı.

Arayüzün değişen parçalarını yardımcı teknolojilere açan rol, durum ve özellikler.

Nasıl uyguluyoruz Şablonlarda aria-labelledby, aria-describedby, aria-expanded, aria-controls, aria-live ve role="status" kullanıyoruz.

LCP, INP ve CLS eşikleri ve bunları ölçen denetim aracı.

Nasıl uyguluyoruz Lighthouse ölçümünü kaydettik (ana sayfa: mobilde 97, masaüstünde 100); yazı tiplerini önceden yüklüyor, betikleri ertelenmiş yüklüyor ve yalnızca kullanılan ikonları sunuyoruz.

Genel kapsayıcılar yerine anlam taşıyan main, nav, header, footer, section, article ve dialog öğeleri.

Nasıl uyguluyoruz Sayfa iskeleti ve bileşenler anlamsal öğelerle kurulu, iletişim formunun pencereleri yerel dialog öğesi.

Çalışan HTML ile başlayıp CSS ve JavaScript'i olmasa da olur katmanlar olarak eklemek.

Nasıl uyguluyoruz İletişim formu JavaScript olmadan da gönderiliyor ve sayfaya geri dönen bir yanıt alıyor; bunu bir test koruyor.

Akışkan bir düzen ve medya sorgularıyla tek sayfanın her ekrana uyması.

Nasıl uyguluyoruz Sayfalar akışkan bir yazı ölçeği ve medya sorgularıyla kuruluyor; bir ölçümü mobilde ve masaüstünde ayrı ayrı alıp kaydettik.

Sayfanın dilini ve yazı yönünü bildirerek tarayıcının, ekran okuyucunun ve arama motorunun metni doğru işlemesi.

Nasıl uyguluyoruz Her sayfa pazarının dilini ve yönünü html öğesinde taşıyor; bir test iki pazarın aynı çeviri anahtarlarına sahip olduğunu denetliyor.

Arama motorlarına bir sayfanın her dil sürümünü ve varsayılan sürümü bildirmek.

Nasıl uyguluyoruz Her sayfa iki pazardaki karşılığını ve varsayılanı hem sayfa başlığında hem site haritasında listeliyor; pazara göre değişen adreslerde de aynı sayfaya gidiyor.

Cache-Control yönergeleri tarayıcıların ve ara sunucuların yanıtları güvenle yeniden kullanmasını sağlar.

Nasıl uyguluyoruz Sürüm adlı dosyalar bir yıl ve immutable ile önbelleğe alınıyor; sayfa önbelleği dil kararına göre anahtarlanıyor ve her yayında temizleniyor.

Açılır kapanır bölüm, iletişim penceresi ve menü düğmesi gibi erişilebilir bileşen kalıpları.

Nasıl uyguluyoruz Menü düğmesinde açılır kapanır kalıbını, formun pencerelerinde yerel dialog öğesini kullanıyoruz; klavye davranışı otomatik test edilmiyor.

Web için sıkıştırılmış ve sitenin kendi kaynağından sunulan yazı tipi biçimi.

Nasıl uyguluyoruz IBM Plex yazı tiplerini alt kümeler halinde kendi sunucumuzdan veriyoruz; bu kararın gerekçesi bir karar kaydında yazılı.

tr ve en-US gibi etiketlerin söz dizimi ve iki harfli bölge kodları.

Nasıl uyguluyoruz Pazarlar tr ve en etiketleriyle, yerel ayarlar tr_TR ve en_US ile tanımlı; tarayıcı dili testlerle denenen bir çözümleyiciyle okunuyor.

Tarih, sayı ve adlar için yerel ayar verisi; ICU ve PHP'nin intl eklentisi bu veriyi kullanır.

Nasıl uyguluyoruz PHP'nin intl eklentisi ve pazar bazlı yerel ayar verisi kullanılıyor; tarihler CLDR biçimlendirmesi yerine sabit kalıplarla yazılıyor.

Dosyalarda, sayfalarda ve verilerde bütün metinler için tek kodlama.

Nasıl uyguluyoruz Sayfalar, dosyalar ve JSON çıktısı UTF-8; tam Türkçe karakter kuralını bir test denetliyor.

Farkıyla birlikte makinece okunabilen tarih ve saat ile Europe/Istanbul gibi adlı saat dilimleri.

Nasıl uyguluyoruz Form gönderimleri ve CRM kuyruğu zamanı ATOM biçiminde yazıyor; her pazarın saat dilimi yapılandırmada tanımlı.

Bağlantılı veri için JSON biçimi; schema.org işaretlemesinin taşıyıcısı.

Nasıl uyguluyoruz Her sayfa yapılandırılmış verisini tek bir JSON-LD grafiğinde taşıyor; grafiği şablon değil bir PHP servisi üretiyor.

Kurumlar, hizmetler ve sayfalar hakkında yapılandırılmış veri için ortak sözlük.

Nasıl uyguluyoruz Kurum, adres, iletişim noktası, web sitesi, hizmet, yazılım, kişi ve sayfa türlerini kullanıyoruz ve testler her sayfanın grafiğini denetliyor.

Bir sayfanın paylaşıldığında nasıl görüneceğini belirleyen etiketler.

Nasıl uyguluyoruz Her sayfa Open Graph ve Twitter etiketlerini taşıyor; her pazarın 1200x630 boyutunda kendi paylaşım görseli var.

Tarayıcılar için, dil sürümlerini de gösterebilen XML adres listesi.

Nasıl uyguluyoruz Site haritası yönlendirme tablosundan ve içerik kataloğundan üretiliyor, her adresin dil sürümlerini listeliyor ve bir test onu denetliyor.

robots.txt tarayıcılara hangi yolları alabileceklerini söyler.

Nasıl uyguluyoruz robots.txt site haritasını gösteriyor; önbellek denetim adresi ve hata sayfaları dizine eklenmeme işaretini taşıyor.

Artı işareti, ülke kodu ve en fazla on beş haneden oluşan uluslararası numara biçimi.

Nasıl uyguluyoruz Şirket numaralarını yapılandırılmış veride ve arama bağlantılarında E.164 biçiminde yayınlıyoruz; formdaki telefon alanı esnek bir kalıpla doğrulanıyor, dönüştürülmüyor.

API'ler için veri alışverişi ve insanın okuyabileceği yapılandırma ve içerik.

Nasıl uyguluyoruz Form yanıtları ve kuyruk dosyaları JSON; içerik, çeviriler ve yayın hattı YAML ve her değişiklikte denetleniyor.