Composable Commerce için SEO

TL;DR — Composable commerce, mağazanızı hepsi bir arada tek bir platform satın almak yerine ayrı, alanının en iyisi araçlardan oluşturmanız demektir — arama için bir tedarikçi, CMS’iniz için başka biri, ödeme adımı için bir başkası, ödemeler için de başka biri. Bu, “headless” kavramından daha kapsamlı bir fikirdir. Headless yalnızca mağaza arayüzünü arka uçtan ayırır; composable ise her şeyi ayırır. SEO açısından sorun şudur: Sitenin farklı bölümlerini çok sayıda tedarikçi çalıştırdığında URL’lerinizin, yönlendirmelerinizin ve canonical etiketlerinizin bütününden kimsenin sorumlu olmaması kolaydır.

Composable commerce nedir?

E-ticaret yıllar boyunca her şeyi yapan büyük bir platform satın almak anlamına geldi — mağaza arayüzü, ürün kataloğu, arama, ödeme adımı, ödemeler ve diğer her şey. Buna monolitik platform denir. Basittir: tek tedarikçi, tek ekip ve tüm SEO ayarlarının bulunduğu tek yer.

Composable commerce bunun tam tersi bir yaklaşımdır. Tek platform kullanmak yerine her iş için en iyi aracı seçer ve bunları API’lerle birbirine bağlarsınız: site araması için bir tedarikçi, içerik sayfalarınız için başka biri, ödeme adımı için bir başkası, ödemeler için de başka biri. Mağazanızı bağımsız parçalardan “oluşturursunuz”.

Bunun MACH kısaltmasıyla tanımlandığını sık sık duyarsınız — Microservices, API-first, Cloud-native ve Headless. Çoğu composable yığının üzerine kurulduğu teknik ilkeler bunlardır.

Composable ve headless — aynı şey değiller

İnsanlar bu sözcükleri birbirinin yerine kullanır, ancak bunlar aynı fikrin farklı kapsamdaki biçimleridir:

• Headless, yalnızca frontend’i (alışveriş yapanların gördüğü kısmı) arkasındaki ticaret motorundan ayırır. Tek bir şey birbirinden ayrıştırılır. (headless ecommerce SEO merkezi de bunu ele alır.)
• Composable, aynı “birbirinden ayır” mantığını yalnızca frontende değil, her yeteneğe uygular. Headless bir bileşendir — MACH’teki “H”. Composable ise tarifin tamamıdır.

Dolayısıyla headless, composable’a doğru atılan bir adımdır; onun eş anlamlısı değildir.

SEO açısından neden önemlidir?

Başlangıç düzeyinde anlaşılması gereken nokta şu: composable commerce SEO’nuza otomatik olarak yardımcı olmaz veya zarar vermez. Varsayılan olarak nötrdür. Googlebot’un sayfalarınızı görüp görememesi gibi oluşturmayla ilgili konular aslında headless frontend ile ilgilidir ve merkez içerikte ele alınır.

Composable’ın getirdiği şey bir koordinasyon sorunudur. Beş farklı tedarikçinin her biri sitenizde URL oluşturduğunda — arama tedarikçisi filtre/facet URL’leri, CMS blog ve açılış sayfası URL’leri, ticaret motoru ürün URL’leri oluşturur — bütün resmi kimsenin izlememesi çok kolaydır. Yönlendirmeler atlanır. Canonical etiketleri birbiriyle çelişir. Daha iyi bir tedarikçiye geçtiğinizdeyse bir grup URL değişir, ancak kimse bunu gerçekte olduğu gibi bir taşıma olarak ele almaz.

Çözüm sıkıcı ama etkilidir: Birinin yalnızca kendi bölümünden değil, tüm tedarikçilerdeki URL, yönlendirme ve canonical yapısının bütününden sorumlu olması gerekir.

MACH mimarisini, “her tedarikçi değişimi küçük bir taşımadır” sorununu ve uygulamaya dönük sahiplik kontrol listesini içeren tam sürümü mü istiyorsunuz? Advanced sekmesine geçin.

TL;DR — Composable commerce bir mimari stratejisidir — yığın, API’lerle bağlanan bağımsız ve alanının en iyisi tedarikçilerden (mağaza arayüzü, arama, CMS, ödeme adımı, ödemeler, sipariş karşılama), genellikle MACH ilkeleri (Microservices, API-first, Cloud-native, Headless) temelinde oluşturulur. Headless’tan daha kapsamlıdır: headless frontendi, composable ise her şeyi ayrıştırır. Oluşturma kuralları headless katmanına (merkez içeriğe) aittir. Composable’ın kendine özgü SEO riski teknik değil, yapısaldır: Yığın, birbiriyle koordinasyon kurmayan tedarikçilerden birleştirildiği için yönlendirme haritasının, canonical stratejisinin veya URL yapısının tamamından tek bir tedarikçi ya da ekip sorumlu değildir. URL’leri değiştiren her tedarikçi değişimi de Google’a hiç bildirilmemiş kısmi bir site taşımasıdır — Google’ın site taşıma yönergeleri (en az bir yıl korunan yönlendirmeler, kendine referans veren canonical’lar, Change of Address) tek ve koordineli bir taşıma varsayar; composable ise bunu parçalara böler. Çözüm sahipliktir: Her tedarikçinin uyduğu, sahibi belirlenmiş tek bir URL yapısı belgesi; ortak bir yönlendirme haritası; tedarikçiler arası görünürlüğe sahip, adı belirlenmiş bir teknik SEO sorumlusu ve URL değiştiren tedarikçi geçişlerinin gerçek taşıma olarak ele alınması.

Composable commerce gerçekte nedir?

Composable commerce, monolitik ve hepsi bir arada bir platform satın almak yerine yığınınızı bağımsız, alanının en iyisi tedarikçi hizmetlerinden — mağaza arayüzü, site araması, CMS, ödeme adımı, ödemeler, promosyonlar, abonelikler, sipariş karşılama — oluşturduğunuz; her birini ayrı seçip API’ler üzerinden bağladığınız bir geliştirme yaklaşımıdır.

Bu modeli sistemleştiren sektör kuruluşu MACH Alliance, onu bir geliştirme yaklaşımı olarak tanımlar: “that enables organizations to activate their entire product record across every channel by leveraging best-of-breed commerce vendors composed together into a singular, custom-built application.” Vaat edilen yaklaşım şudur: “a best-of-breed approach that allows your organization to personalize your tech stack to fit and scale with your needs.”

Genellikle MACH — Microservices, API-first, Cloud-native, Headless — temelinde kurulur. MACH Alliance bunu açık, composable ve bağlantılı kurumsal teknolojinin temeli olarak tanımlar. Shopify’ın kurumsal ekibinden yararlı bir nüans: “MACH is best understood as a pattern for building composable systems, not a merit badge that automatically makes a commerce stack better.” Bunu aklınızda tutun — aşağıdaki mitler bölümünün temel noktası budur.

Şunu bilmekte yarar var: MACH Alliance’ın kendi tanımsal çerçevesi, klasik dört harfli kısaltmanın ötesine geçti. Güncel ilkeler sayfası Composable kavramını “modular — independently deployable and built for continuous evolution without disruption,” şeklinde tanımlar; Open ilkesi “every action your team — or your agent — takes is visible, auditable, and trustworthy,” koşulunu getirir; Connected ise “when something happens in your business, the systems and agents that need to know, know instantly.” olarak açıklanır. Bu makalenin amacı açısından yararlı bir ölçüttür: Bir tedarikçi, yalnızca platformunuzdan ayrı satın alındığı için “composable” olmaz; yığının geri kalanını bozmadan bağımsız olarak devreye alabiliyor, gözlemleyebiliyor ve değiştirebiliyorsanız composable’dır. Platformunuzdan farklı bir tedarikçiden gelmesine rağmen sıkı biçimde bağlı bir entegrasyon bu ölçütü karşılamaz. Yığının geri kalanıyla nasıl iletişim kurduğunu açıklayan belgelenmiş ve incelenebilir bir sözleşmesi olmayan bir yetenek de karşılamaz.

Composable ⊃ headless — üç karar katmanı

Sektör basınındaki en yaygın hata, “composable” ve “headless” kavramlarını eş anlamlı saymaktır. Değillerdir. Headless, MACH’in bir sütunudur; composable ise bütünüdür. Composable.com ayrımı açıkça ifade eder: “Instead of just separating the front-end from the back-end, composable breaks every piece of the commerce stack into modular, API-connected components.” Shopify aynı ayrımı katmanlara göre çerçeveler: “Headless changes the presentation layer. Composable extends modularity across the rest of the stack. Monolithic or tightly integrated platforms keep more capabilities within a single managed unit.”

Bu nedenle, her biri öncekinden daha fazlasını ayrıştıran üç karar katmanı düşünün:

Headless orta adımdır. Yayımlanmış headless ecommerce SEO merkezi bu katmanı ele alır — SSR/SSG/CSR oluşturma, headless frontendin kendisinin oluşturması gerekenler (meta etiketleri, canonical’lar, site haritaları, yapılandırılmış veri) ve Google’ın JavaScript işleme kuralları. Burada oluşturma konusunu yeniden tartışmayacağım. Bu makale, bir katman daha ileri gittiğinizde nelerin değiştiğiyle ilgilidir.

Composable’a özgü SEO riski: URL grafiğinin bütününe kimse sahip değil

Bu bölüm iki kez okunmaya değer; çünkü composable commerce hakkındaki başka hiçbir yazının ele almadığı tek noktayı kapsıyor.

Bir monolitte, tek platformun SEO modülü varsayılan olarak metadata, canonical’lar ve site haritalarını yönetir. Headless yapıda bunların tümünü oluşturma sorumluluğu tek bir frontend ekibindedir (bu, merkez içeriğin alanıdır). Composable yapıda ise SEO ile ilgili yüzeylerin oluşturulması, birbiriyle koordinasyon kurmayan N bağımsız tedarikçi arasında bölünür:

• Arama tedarikçiniz (Algolia, Constructor ve benzerleri) facet ve filtre URL’leri üretir.
• CMS tedarikçiniz (Contentful, Contentstack) içerik ve açılış sayfası URL’leri üretir.
• Ticaret motorunuz (commercetools, Elastic Path) ürün ve kategori URL’leri üretir.
• Ödeme adımı veya ödeme tedarikçiniz, alışveriş yapanları dönüşüm hunisinin ortasında kendi alan adı üzerinden yönlendirebilir.

Her tedarikçi kendi bölümü için makul varsayılanlar sunar. Hiçbiri URL grafiğinin tamamını göremez. Bu nedenle klasik ve birden çok alanı kesen teknik SEO konuları — yönlendirme haritası, canonical stratejisi, URL yapısı — tedarikçiler arasındaki, kimsenin bakmadığı boşluklara düşer. Composable yığınlarda yönlendirme açıklarının, aynı üründe çelişen canonical etiketlerinin (biri CMS, diğeri ticaret motoru tarafından üretilir) ve kimsenin site haritasına hiç eklenmemiş facet URL’lerinin bu kadar yaygın olmasının nedeni budur.

Bu sitede sürekli döndüğüm daha derin nokta şudur: Yeni mimariler SEO’nun temellerini değiştirmez; ancak bunlardan kimin sorumlu olduğu değişir ve sorumlu tarafların sayısı risk değişkenidir. headless merkezi, headless yapıda “every default you relied on is now your responsibility.” savını ortaya koyar. Composable bunu bir adım ileri taşır: Sorumluluk artık yalnızca kendi frontend ekibinizde değil, birden çok bağımsız tedarikçi arasında bölünmüştür. Daha fazla taraf, daha fazla bağlantı noktası ve bir URL’nin sahipsiz kalabileceği daha fazla yer demektir.

Her tedarikçi değişimi, Google’ın farkında olmadığı küçük bir site taşımasıdır

Composable’a en özgü olan ve bu makaleyi Google’ın resmî yönergelerine dayandıran başarısızlık biçimi şudur.

Google’ın site taşıma belgeleri tek ve koordineli bir site taşıması varsayar. Bir taşımanın gerektirdiği titizlik konusunda nettir. Her yeni URL kendine referans veren bir canonical içermelidir: “Each new URL should have a self-referencing rel="canonical" link tag.” Yönlendirmeleri kaldırmakta da acele edemezsiniz; onları “as long as possible, generally at least 1 year,” koruyun. Çünkü “this timeframe allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs.” (Bunun güncel yönerge olduğunu unutmayın — hâlâ ortalıkta dolaşan “180 days” değerinden daha uzun, tam bir yıl.)

Şimdi soruna gelelim. Composable bir yığında yalnızca arama tedarikçinizi veya yalnızca CMS’inizi değiştirmek URL’lerinizin bir alt kümesini değiştirir — yeni facet parametreleri, yeni içerik rotaları, yeni URL biçimleri. SEO açısından bu bir kısmi site taşımasıdır. Ancak taşıma gibi hissettirmediği için neredeyse hiçbir zaman site taşıma titizliğiyle ele alınmaz. “Yalnızca bir tedarikçiyi değiştirdik” gibi görünür. Kimse yönlendirme haritası hazırlamaz. Kimse yeni rotalara kendine referans veren canonical’lar eklemez. Kimse Change of Address aracını açmaz — sonuçta alan adı değişmemiştir.

301 hâlâ her zaman yaptığı işi yapar: Google, kalıcı yönlendirmeyi eski URL’yi yenisinde birleştiren güçlü bir canonicalization sinyali olarak değerlendirir. Mekanizma değişmemiştir. Değişen şey, composable bir yığında bunu gerçekten uygulamak için gereken koordinasyonun — her tedarikçi değişiminden etkilenen her URL genelinde — tek bir sahibinin bulunmamasıdır. Google tek ve koordineli bir site taşıması varsayar; composable ise bu koordinasyonu tedarikçi sınırlarına böler. (Sinyalleriniz çeliştiğinde Google’ın yinelenen URL’ler arasından gerçekte nasıl bir kazanan seçtiğini öğrenmek için canonicalization içeriğine bakın — kısa açıklaması şu: rel="canonical" bir kural değil ipucudur; dolayısıyla iki tedarikçiden gelen çelişkili etiketler tam da kaçınmak istediğiniz karmaşadır.)

Oluşturma hakkında bir not — çözmek composable’ın sorunu değildir

Kapsamı kesinleştirelim: Composable, Core Web Vitals’a, JavaScript oluşturmasına veya Googlebot’un içeriğinizi görüp görememesine özünde zarar vermez ya da yardımcı olmaz. Bunlar headless frontend katmanının özellikleridir ve Google’ın bu konudaki yönergesi değişmemiştir. Google, sunucu taraflı oluşturmanın veya önceden oluşturmanın neden hâlâ iyi bir fikir olduğunu şöyle açıklar: “still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript,” Ayrıca canonical URL’yi özgün HTML’dekinden farklı bir URL’ye çevirmek için hâlâ JavaScript kullanmamalısınız. Bunların tümü headless merkezinin konusudur. Composable’ın ayrı riski performans değil, koordinasyondur. Composable bir yeniden platformlandırmanın oluşturma sorunundan veya tam tersinin sorumlu tutulmasına izin vermeyin — bunlar farklı katmanlarda yer alır.

Composable veya headless ticaret mimarisine özgü ayrı bir Bing ya da Microsoft yönergesi yoktur; Google’ın JavaScript oluşturma ve site taşıma belgeleri, her iki arama motoru için de en yakın uygulanabilir resmî kaynaktır.

MACH tedarikçi ortamı (kısaca)

Composable ekosistemi büyüktür ve belirli tedarikçileri seçmek, burada bilinçli olarak yapmadığım bir satın alma rehberi işidir — platform karşılaştırması (Shopify Hydrogen, commercetools, Saleor, Medusa, BigCommerce headless ve hangi ekibe hangisinin uygun olduğu) headless commerce platforms kardeş içeriğinin alanıdır. Yalnızca bağlam vermek gerekirse composable bir yığın genellikle şunlardan yararlanır: commercetools veya Elastic Path (ticaret motoru), Contentful veya Contentstack (headless CMS — bkz. headless CMS), Algolia veya Constructor (arama), Stripe veya Adyen (ödemeler), ayrıca mağaza arayüzü framework’leri ve edge barındırma. SEO açısından önemli olan hangi tedarikçilerin kullanıldığı değil, her birinin URL yüzeyinizin bir bölümüne sahip olmasıdır.

”Composable öldü” tepkisi aslında entegrasyon yüküne karşı bir tepkidir

Son zamanlarda yeniden platformlandırma toplantılarına katıldıysanız composable’ın veya MACH’in ölmekte olduğunu duymuşsunuzdur. Bu tepkinin gerçekte ne olduğunu anlamaya değer; çünkü konu “mimari geçici bir modaydı” ifadesinden daha nüanslıdır ve yukarıdaki SEO riskiyle doğrudan bağlantılıdır.

64labs’ten John Duncan, tepkinin modüler mimariye değil, kısaltmaya bir kontrol listesi gibi dogmatik biçimde bağlı kalmaya yönelik olduğunu savunan, geniş kitlelerce okunan bir retrospektif yazdı. Çerçevesi şöyle: “most retailers don’t have a MACH problem. They have an ROI problem, a velocity problem,” ve “MACH promised architectural freedom. Retailers needed business agility.” MACH tedarikçilerini eskiden farklılaştıran ilkeler konusunda cloud-native ve API-first için şunu açıkça söyler: “aren’t differentiators anymore. They’re table stakes.” Özellikle microservices yükü hakkında da şunu sorar: “who’s got the team to manage dozens of services, each with its own SLA and quirks?” Ona göre artık kazanan yaklaşım “dogmatic adherence to MACH principles. It’s a practical, performance-driven composable strategy.” değildir.

“dozens of services, each with its own SLA and quirks” ifadesi, SEO tutarlılığının tam olarak koptuğu yeri gösterir. Herkesin şikâyet ettiği entegrasyon yükü, bağlantı noktası sorununun ta kendisidir: Yönettiğiniz bağımsız hizmet sayısı arttıkça bir yönlendirmenin, canonical’ın veya site haritası girişinin aradan düşebileceği yerlerin sayısı da artar. MACH’e yönelik tepki ile composable SEO riski, aynı madalyonun — tedarikçi sınırı yükünün — iki farklı açıdan görünümüdür. (Aynı 64labs yazısında bildirilen Vtex’in MACH markasından kamuya açık biçimde ayrılması da aynı “sonuçlar yerine dogma” eleştirisinin parçasıdır; ancak ayrıntıları kesinleşmiş bir olgu değil, sektör yorumu olarak ele alırım.)

Uygulamaya dönük kontrol listesi: Composable yığında SEO tutarlılığını korumak

Bütün resme hiçbir tedarikçi sahip olmadığı için sizin sahip olmanız gerekir. Somut olarak:

1. Her tedarikçinin uyması gereken, sahibi belirlenmiş tek bir URL yapısı belgesi — yalnızca her tedarikçinin kendi varsayılanları değil. Ürün, kategori, facet ve içerik URL biçimlerine bir kez ve merkezi olarak karar verin; uyumu bir tedarikçi entegrasyonu gereksinimi hâline getirin.
2. Ortak tek bir yönlendirme haritası deposu — her tedarikçinin içinde yaşayan ayrı bir yönlendirme listesi değil. Ürün, içerik ve facet URL’lerini kapsamalıdır; böylece herhangi bir sistemdeki değişim bütünle karşılaştırılarak uzlaştırılabilir.
3. Her tedarikçi değişimini ve yapılandırma değişikliğini görebilen, adı belirlenmiş bir teknik SEO sorumlusu — yalnızca frontend ekibi değil. Bu kişinin işi, hiçbir tedarikçi panelinin göstermediği URL grafiğini uçtan uca görmektir.
4. URL’leri değiştiren her tedarikçi değişimini resmî bir (kısmi de olsa) site taşıması olarak ele alın — Google’ın site taşıma disiplinini etkilenen URL alt kümesine uygulayın: 301’ler, yeni rotalarda kendine referans veren canonical’lar, en az bir yıl korunan yönlendirmeler ve yalnızca hostname gerçekten değişiyorsa Change of Address. Tam uygulama planı için site migrations içeriğine bakın.
5. Düzenli, tedarikçiler arası site haritası ve schema denetimi — yapılandırılmış veri birden fazla sistem tarafından üretilebilir (CMS içerik schema’sı ile ticaret motorunun Product schema’sı); bu nedenle tedarikçiler genelindeki yinelenen, çelişen veya eksik işaretlemeleri denetleyin ve üretilen her URL türünün tam olarak bir canonical site haritasında bulunduğunu doğrulayın.

Buradan sonra nereye gidilmeli?

• Headless ecommerce SEO — küme merkezi: oluşturma modelleri (SSR/SSG/CSR) ve headless frontendin kendisinin oluşturması gerekenler. Googlebot’un sayfalarınızı görüp göremediğiyle ilgili konulara buradan başlayın.
• Headless commerce platforms — gerçekten tedarikçi seçmek için platform bazında karşılaştırma (Shopify Hydrogen, commercetools, Saleor, Medusa, BigCommerce).
• Headless CMS — composable yığının içerik yarısı.
• Site migrations — URL değiştiren her tedarikçi geçişinin yararlanması gereken disiplin.

AI özeti

Advanced sürümün kısa özeti:

• Composable commerce = yığını alanının en iyisi tedarikçilerden oluşturmak (mağaza arayüzü, arama, CMS, ödeme adımı, ödemeler, sipariş karşılama); bunlar API’lerle bağlanır ve genellikle MACH ilkelerini (Microservices, API-first, Cloud-native, Headless) izler.
• Composable ⊃ headless. Headless yalnızca frontendi ayrıştırır; composable her yeteneği ayrıştırır. Üç katman vardır: monolitik → headless → composable; her biri daha fazlasını ayrıştırır.
• Gerçekte ne “composable” sayılır? MACH Alliance’ın güncel ilkeleri (klasik kısaltmanın ötesinde) bunu bağımsız olarak devreye alınabilir, belgelenmiş/gözlemlenebilir ve birlikte çalışabilir olmak şeklinde tanımlar — bir yeteneği farklı bir tedarikçiden satın almak, incelenebilir bir sözleşme olmadan sıkı biçimde bağlıysa tek başına yeterli değildir.
• Composable’ın SEO riski teknik değil, yapısaldır. Oluşturma/performans headless katmanına (merkeze) aittir. Composable’ın kendi riski şudur: Yığın birbiriyle koordinasyon kurmayan tedarikçilerden birleştirildiği için yönlendirme haritasının, canonical stratejisinin veya URL yapısının tamamına tek bir tedarikçi ya da ekip sahip değildir. Arama tedarikçisi facet URL’lerine, CMS içerik URL’lerine, ticaret motoru ürün URL’lerine sahiptir — bütün grafiği kimse görmez.
• Her tedarikçi değişimi, Google’a bildirilmeyen kısmi bir site taşımasıdır. Google’ın site taşıma yönergeleri (kendine referans veren canonical’lar, en az 1 yıl korunan yönlendirmeler, Change of Address) tek ve koordineli bir taşıma varsayar; yalnızca arama veya CMS’i değiştirmek, taşıma titizliğinin nadiren uygulandığı bir URL alt kümesini değiştirir.
• MACH “tepkisi”, mimariye değil entegrasyon yüküne yönelik bir tepkidir (64labs) — SEO tutarlılığının koptuğu yer de tam olarak bu yüktür.
• Çözüm araçlar değil, sahipliktir: Tüm tedarikçilerin uyduğu, sahibi belirlenmiş tek bir URL yapısı belgesi; ortak bir yönlendirme haritası; tedarikçiler arası görünürlüğe sahip, adı belirlenmiş bir teknik SEO sorumlusu; taşıma olarak ele alınan URL değiştirici geçişler ve düzenli tedarikçiler arası site haritası/schema denetimleri (schema hem CMS hem de ticaret motoru tarafından üretilebilir).
• Ortadan kaldırılması gereken mit: “composable” ile “headless” aynı şeydir — değildir; headless, MACH’in yalnızca bir sütunudur.

Resmî belgeler

Composable bir mimari modeli olduğundan “resmî” kaynaklar ikiye ayrılır: Composable bir yığının doğru uygulaması gereken SEO mekanikleri için arama motorları ve modelin tanımsal otoritesi olan MACH Alliance.

Google — SEO’nun temelini taşıyan belgeler

• Site moves with URL changes — URL değiştiren her tedarikçi geçişinin yararlanması gereken disiplin: yeni URL’lerde kendine referans veren canonical’lar ve yönlendirmelerin en az bir yıl korunması.
• Redirects and Google Search — 301/kalıcı yönlendirmenin, eski URL’yi yenisinde birleştiren canonicalization sinyali olarak nasıl çalıştığı.
• Understand JavaScript SEO basics — “not all bots can run JavaScript” ifadesi ve canonical’ı JavaScript ile değiştirmeme kuralı dâhil, headless frontendin devraldığı oluşturma kuralları (tarama → oluşturma → dizine ekleme).

MACH Alliance — modelin tanımsal otoritesi

• What is Composable Commerce and Why is it Important? — temel tanım: Tek ve özel geliştirilmiş bir uygulamada birleştirilen, alanının en iyisi tedarikçiler.
• MACH Alliance homepage — açık, composable ve bağlantılı kurumsal teknoloji sektör kuruluşu; MACH çerçevesinin kaynağı.
• MACH Explained — Open, Composable, Connected principles — Alliance’ın klasik kısaltmanın ötesindeki güncel tanımsal çerçevesi: Bir yeteneği yalnızca ayrı satın alınmış değil, gerçekten composable yapan özellikler (bağımsız devreye alınabilirlik, belgelenmiş ve gözlemlenebilir olma, sistemler arası birlikte çalışabilirlik).

Tedarikçi kaynakları (arama motorlarına değil, sektöre ait resmî kaynaklar)

• Shopify Enterprise — Composable Commerce Platform: Definition, Architecture, Benefits — sunum katmanı ile yığının geri kalanı arasındaki ayrım ve “MACH is a pattern… not a merit badge.”
• composable.com — Headless vs Composable Commerce — “breaks every piece of the commerce stack into modular, API-connected components” çerçevesi.

Kaynaktan alıntılar

Google, MACH Alliance ve tedarikçi/sektör kaynaklarının kayda geçmiş açıklamaları. Google derin bağlantıları doğrudan alıntılanan bölüme gider.

Google — composable bir yığının doğru uygulaması gereken SEO mekanikleri

• Taşıma sırasında yeni URL canonical’ları hakkında: “Each new URL should have a self-referencing rel="canonical" link tag.” — Google Search Central, Site moves with URL changes. Yönergeyi okuyun
• Yönlendirme süresi hakkında (not: 180 gün değil, tam bir yıl): “Keep the redirects for as long as possible, generally at least 1 year,” çünkü “this timeframe allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs.” Yönergeyi okuyun
• Oluşturmanın neden hâlâ frontendin işi olduğu hakkında: “Keep in mind that server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.” Alıntıya gidin

MACH Alliance — composable nedir?

• “Composable commerce is a development approach that enables organizations to activate their entire product record across every channel by leveraging best-of-breed commerce vendors composed together into a singular, custom-built application.” Kaynağı okuyun
• “A best-of-breed approach that allows your organization to personalize your tech stack to fit and scale with your needs.” Kaynağı okuyun
• “MACH Alliance is the global industry body for open, composable, and connected enterprise technology – the foundation and the framework for the agentic era.” Kaynağı okuyun
• Alliance’ın kendi güncel ilkelerinde “composable” kavramının bugünkü anlamı hakkında: “Your systems are modular – independently deployable and built for continuous evolution without disruption.” Kaynağı okuyun
• Bunun tamamlayıcısı olan “Open” ilkesi hakkında: “Every action your team – or your agent – takes is visible, auditable, and trustworthy.” Kaynağı okuyun

Composable ve headless karşılaştırması — tedarikçi çerçevesi

• “Instead of just separating the front-end from the back-end, composable breaks every piece of the commerce stack into modular, API-connected components.” — composable.com, Headless vs Composable Commerce. Kaynağı okuyun
• “Headless changes the presentation layer. Composable extends modularity across the rest of the stack. Monolithic or tightly integrated platforms keep more capabilities within a single managed unit.” — Shopify Enterprise. Kaynağı okuyun
• “MACH is best understood as a pattern for building composable systems, not a merit badge that automatically makes a commerce stack better.” — Shopify Enterprise. Kaynağı okuyun

2025–2026 tepkisi — John Duncan, 64labs

• “most retailers don’t have a MACH problem. They have an ROI problem, a velocity problem.” Makaleyi okuyun
• “MACH promised architectural freedom. Retailers needed business agility.” Makaleyi okuyun
• Microservices yönetimi hakkında: “who’s got the team to manage dozens of services, each with its own SLA and quirks?” Makaleyi okuyun
• Cloud-native/API-first hakkında: “These aren’t differentiators anymore. They’re table stakes.” Şimdi kazanan yaklaşım ise: “a practical, performance-driven composable strategy.” Makaleyi okuyun

Taşıma titizliği açısından — Jerry Trybuchowicz, Beecommerce

• “Every old URL must have one exact counterpart in the new structure. Relying on general rules or automations is asking for trouble.” Makaleyi okuyun
• “All meta tags, canonical tags, hreflang for language variants, and structured data (Schema.org like Products or Author) must be migrated and correctly implemented in the new frontend.” Makaleyi okuyun

Tedarikçiler arası SEO sahipliği kontrol listesi

Bu listenin amacı, her SEO yüzeyi için aynı soruyu sormaktır: Buna yalnızca tek bir tedarikçinin içinde değil, bütün yığın genelinde kim sahip?

URL yapısı

• Merkezi olarak sahiplenilmiş tek bir URL yapısı belgesi vardır (ürün, kategori, facet, içerik biçimleri) ve tedarikçilerin buna uyması sonradan düşünülen bir ayrıntı değil, entegrasyon gereksinimidir.
• Her URL türünü hangi tedarikçinin ürettiğini biliyorsunuz (ürün → ticaret motoru, facet → arama tedarikçisi, içerik → CMS, ödeme adımı → ödemeler/ödeme adımı tedarikçisi).
• İki tedarikçi aynı ürün/içerik için farklı URL üretmiyor (üretiyorsa biri tutarlı biçimde diğerini canonical olarak gösteriyor).

Yönlendirmeler

• Ortak tek bir yönlendirme haritası deposu tüm tedarikçileri kapsıyor — tedarikçi başına ayrı liste yok.
• URL’leri değiştiren, planlanmış veya tamamlanmış her tedarikçi geçişinde eski URL’lerden yenilerine 301s uygulanıyor.
• Yönlendirmeler en az bir yıl korunuyor (Google’ın güncel site taşıma yönergesi).

Canonical’lar

• Her ürün/içerik sayfası tam olarak bir rel="canonical" üretiyor — CMS’ten bir tane ve ticaret motorundan onunla çelişen başka bir tane değil.
• Tedarikçi değişiminin oluşturduğu yeni rotalarda kendine referans veren canonical’lar bulunuyor.
• Bildirilen canonical, özellikle iki sistemin çakışan URL’ler ürettiği yerlerde, Google’ın gerçekte seçtiği değerle karşılaştırılarak doğrulanıyor (GSC URL Inspection).

Site haritaları ve schema

• Üretilen her URL türü tam olarak bir canonical XML site haritasında yer alıyor.
• Yapılandırılmış veri tedarikçiler arasında yinelenmiyor veya çelişmiyor (CMS içerik schema’sı ile ticaret motorunun Product schema’sı birlikte denetleniyor).
• Düzenli tedarikçiler arası site haritası + schema denetimi planlanıyor — yalnızca bir şey bozulduktan sonra çalıştırılmıyor.

Sahiplik

• Adı belirlenmiş bir teknik SEO sorumlusu, yalnızca frontend ekibinin dağıtımlarını değil, her tedarikçi geçişini ve yapılandırma değişikliğini görebiliyor.
• URL’leri değiştiren her tedarikçi geçişi yayımlanmadan önce kısmi site taşıması olarak kapsamlandırılıyor (bkz. site migrations).

Bu tedarikçi değişimi gerçekten bir site taşıması mı?

Composable bir yığındaki en yararlı kararlardan biri, yayımlamak üzere olduğunuz değişikliğin taşıma kılığına girmiş bir işlem olup olmadığına karar vermektir. Herhangi bir tedarikçiyi değiştirmeden veya yeniden yapılandırmadan önce bu akışı izleyin.

Trafiğinize mal olan composable commerce mitleri

Bunların her biri composable/MACH tartışmalarında sürekli ortaya çıkan bir inançtır — neden yanlış olduğu ve yerine ne yapılması gerektiğiyle birlikte.

Mit: “Composable” ve “headless” aynı şeydir. Neden yanlış: Headless yalnızca frontendi backendden ayırır — MACH’in bir sütunudur (“H”). Composable bu ayrıştırmayı her yeteneğe (arama, CMS, ödeme adımı, ödemeler, sipariş karşılama) genişletir. Konuyla ilgili SEO odaklı makalelerin neredeyse tümü bu ikisini birbirine karıştırır ve composable bir sorun için genel headless tavsiyesi verir. Yerine şunu yapın: Bunları üç karar katmanı olarak ele alın — monolitik → headless → composable — ve composable’a özgü riskin (tedarikçiler arası koordinasyon), headless tavsiyelerinin hiç ele almadığı bir konu olduğunu kabul edin. Oluşturma sorularını headless merkezine yönlendirin; koordinasyon sorularını burada tutun.

Mit: Composable commerce, “daha modern” olduğu için SEO’yu otomatik olarak iyileştirir. Neden yanlış: Composable varsayılan olarak SEO açısından nötrdür. Alanının en iyisi arama veya CMS araçları uygulamayı iyileştirebilir, ancak mimarinin kendisi monolitte bulunmayan bir koordinasyon riski getirir — URL/yönlendirme/canonical yapısının tamamına kimse sahip değildir. Yerine şunu yapın: Nötr olduğunu varsayın, ardından tedarikçiler arası SEO sahipliği atayarak avantajı kazanın. Modernlik bir sıralama sinyali değildir; sizi koruyan şey tutarlılıktır.

Mit: Tek bir tedarikçiyi (örneğin yalnızca site aramanızı) değiştirmek düşük riskli ve SEO açısından görünmez bir değişikliktir. Neden yanlış: Herhangi bir URL’yi, facet’i veya oluşturulan içeriği değiştiriyorsa bu kısmi bir site taşımasıdır — Google’ın site taşıma yönergesi (kendine referans veren canonical’lar, en az bir yıl korunan yönlendirmeler) tam olarak bunun için vardır. Alan adı değişmediğinden yalnızca taşıma gibi hissettirmez. Yerine şunu yapın: Her değişimden önce yukarıdaki Decision Tree sekmesini çalıştırın. Her URL değişikliği için bir yönlendirme haritası, yeni rotalarda kendine referans veren canonical’lar ve site haritası güncellemesi gerekir; işlem kısmi taşıma olarak kapsamlandırılır. Jerry Trybuchowicz’in ifadesiyle, “general rules or automations is asking for trouble.”

Mit: Composable, tedarikçiye bağımlılığı ortadan kaldırır. Neden yanlış: Bağımlılık, platform maliyeti yerine entegrasyon maliyeti olarak yeniden ortaya çıkabilir. Entegre edilmesi veya değiştirilmesi zahmetli bir “composable” tedarikçi, değiştirme maliyeti üzerinden aynı tuzağı yeniden yaratır. 64labs’in tanımladığı microservices yükü — “dozens of services, each with its own SLA and quirks” — de başlı başına bir bağımlılık türüdür. Yerine şunu yapın: Yığını “oluştururken” yalnızca lisanslamayı değil, entegrasyon ve değiştirilebilirlik maliyetini de değerlendirin. Alanının en iyisi yaklaşımı, yalnızca parçaları daha sonra gerçekten değiştirebiliyorsanız karşılığını verir.

Mit: MACH/composable ölüyor; dolayısıyla doğru uygulamakla uğraşmaya gerek yok. Neden yanlış: 2025–2026 tepkisi modüler mimariye değil, kısaltmaya bir kontrol listesi gibi dogmatik biçimde bağlı kalmaya yöneliktir. John Duncan’a göre “dogmatik MACH”in yerini alan yaklaşım “a practical, performance-driven composable strategy” — modüler yığınlar ortadan kalkmıyor. Yerine şunu yapın: Kısaltma gösterisini görmezden gelin ve kalıcı bölüme odaklanın: Birileri hâlâ “MACH” desin veya demesin, tedarikçiler arası SEO koordinasyonu sorunu gerçektir.

Aylık tedarikçiler arası SEO sahipliği incelemesi

1. Değişiklik takvimini inceleyin. Her yığın sahibinden tedarikçi sürümlerini, yapılandırma değişikliklerini, rota değişikliklerini ve planlanan geçişleri toplayın. Tamamlanma ölçütü: URL’leri veya oluşturulan SEO sinyallerini etkileyebilecek her değişikliğin adı ve tarihi belirlenmiştir.
2. URL envanterini uzlaştırın. Ürün, kategori, facet ve içerik URL kalıplarını merkezi olarak sahiplenilen URL yapısı belgesiyle karşılaştırın. Tamamlanma ölçütü: Her kalıbın tek bir üretici sistemi ve tek bir canonical kuralı vardır.
3. Yönlendirme sahipliğini denetleyin. Her tedarikçiden gelen eklemeleri ortak yönlendirme deposunda birleştirin ve eski URL’lerden bir örneklem test edin. Tamamlanma ölçütü: Değişen hiçbir URL, tedarikçiye özgü bir listede mahsur kalmamıştır.
4. Sistemler arası canonical’ları ve schema’yı kontrol edin. Temsilî şablonları tarayın ve farklı hizmetlerin ürettiği yinelenen ya da çelişen etiketleri belirleyin. Tamamlanma ölçütü: Her sayfa tutarlı bir canonical ve uyumlu tek bir yapılandırılmış veri görünümü sunar.
5. Site haritalarını uzlaştırın. Her canonical URL türünün amaçlanan site haritasında bir kez yer aldığını ve kullanımdan kaldırılan URL’lerin çıkarıldığını doğrulayın. Tamamlanma ölçütü: Tedarikçilerin ürettiği URL alanları çakışmaz veya envanterden kaybolmaz.
6. Yaklaşan geçişleri sınıflandırın. Dizine eklenebilir bir URL’deki her değişiklik; yönlendirmeler, canonical’lar, site haritası değişiklikleri ve lansman doğrulaması içeren kısmi veya tam taşıma iş akışına dönüşür. Tamamlanma ölçütü: Hiçbir ekip URL değiştiren bir geçişi “backend only” olarak etiketlemez.
7. Eylemleri atayın ve kapatın. Her çelişkiye tedarikçi sınırları genelinde sorumlu tek bir kişi ve son tarih atayın. Tamamlanma ölçütü: Sonraki inceleme aynı bağlantı noktasını yeniden keşfetmek yerine çözümlenmiş bir eylem günlüğünden başlar.

Composable commerce SEO framework’leri

Yüzey, kaynak, sorumlu

Her SEO yüzeyini üç sütunda eşleyin:

• Yüzey: URL, canonical, yönlendirme, site haritası girişi, yapılandırılmış veri, oluşturulan içerik.
• Kaynak: Onu üreten tedarikçi veya hizmet.
• Sorumlu: Bütün yığın genelindeki davranıştan hesap veren kişi.

Adı belirlenmiş tek bir kaynağı olmayan yüzeyde hata ayıklamak zordur. Uçtan uca tek bir sorumlusu olmayan yüzeyin tedarikçi sınırında çelişki yaratması olasıdır.

Bağlantı noktası riski modeli

Aynı SEO sinyalini üretebilen veya değiştirebilen bağımsız sistemlerin sayısıyla risk artar. Tedarikçileri değil, çakışmaları sayın: Canonical URL’lere dokunan iki sistem, birbirinden yalıtılmış beş sipariş karşılama hizmetinden daha büyük risktir.

URL’ler değiştiğinde tedarikçi değişimi taşıma demektir

Bir değişikliği satın alma etiketine göre değil, gözlemlenebilir çıktısına göre sınıflandırın. Dizine eklenebilir bir URL, canonical hedefi veya iç bağlantı hedefi değişiyorsa etkilenen alt kümeye site taşıma disiplini uygulayın.

Merkezi doğruluk, yerel bağdaştırıcılar

URL kurallarını, yönlendirmeleri, canonical politikasını ve schema sahipliğini merkezi tutun. Her tedarikçinin bu kararları kendi bağdaştırıcısında uygulamasına izin verin; ancak yerel varsayılanların bağımsız site mimarisine dönüşmesine izin vermeyin.

Composable yığın değişikliklerini doğrulayın

URL’leri koruyan tedarikçi değişimi

Çalıştırılacak test: Etkilenen her şablon için değişiklik öncesi/sonrası temsilî URL kümesini ve oluşturulan SEO sinyallerini karşılaştırın. Beklenen sonuç: Herkese açık URL’ler aynı kalır; canonical, metadata, yapılandırılmış veri ve iç bağlantılar aynı amacı korur. Başarısızlık yorumu: Yalnızca backendi etkilediği varsayılan geçiş, taranabilir bir yüzeyi değiştirmiştir ve taşıma olarak yeniden sınıflandırılmalıdır. İzleme aralığı: Staging, üretimde hemen gerçekleştirilen smoke test ve sonraki tarama döngüsü. Rollback tetikleyicisi: Canonical veya dizine eklenebilir URL çıktısı onaylanmış bir harita olmadan değişirse geri alın.

Kısmi taşıma eşlemesi

Çalıştırılacak test: Değişen her eski URL’yi isteyin, yönlendirmeleri izleyin ve son hedefi onaylanmış bire bir haritayla karşılaştırın. Beklenen sonuç: Tek bir kalıcı atlama, başarılı yanıt veren ve kendisini canonical olarak gösteren amaçlanan yeni URL’ye ulaşır. Başarısızlık yorumu: Tedarikçiye özgü bir kural eşlemeyi atlamış, zincirlemiş veya genellemiştir. İzleme aralığı: Lansmandan önce, lansmanın hemen ardından ve arama motorunun yeniden taraması boyunca. Rollback tetikleyicisi: Değerli URL’lerin önemli bir kümesi hatalara, zincirlere veya ilgisiz hedeflere gidiyorsa geçişi durdurun veya geri alın.

Tedarikçiler arası canonical ve schema sahipliği

Çalıştırılacak test: Temsilî ürün, kategori, facet ve içerik şablonlarını tarayın; sunucu HTML’sindeki ve oluşturulan HTML’deki canonical etiketlerini ve yapılandırılmış veri varlıklarını sayın. Beklenen sonuç: Sayfa başına amaçlanan tek bir canonical ve atanan kaynaktan gelen uyumlu, çelişmeyen schema. Başarısızlık yorumu: İki hizmet çakışan veya birbiriyle çelişen sinyaller üretiyor. İzleme aralığı: CMS, arama, ticaret veya frontend çıktısını değiştiren her sürüm. Rollback tetikleyicisi: Canonical hedefleri veya ürün kimliği geniş ölçekte çelişiyorsa üretici değişikliğini geri alın.

Kendinizi sınayın: Composable Commerce

Composable commerce’ın headless’tan nasıl ayrıldığı ve SEO riskinin gerçekte nerede bulunduğu hakkında beş kısa soru. Her biri için bir yanıt seçip kontrol edin.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• The Beginner’s Guide to Technical SEO — bu tür mimari kararların daha geniş teknik SEO resmi içindeki yeri.
• JavaScript SEO Issues & Best Practices — composable bir yığının headless frontendinin doğru uygulaması gereken oluşturma tarafı (composable’ın kendisi oluşturma değil, koordinasyon sorunudur).

Konuşmalarım

• How Search Works (SlideShare) — tarama, oluşturma, dizine ekleme ve sıralamayı anlattığım sunum; yönlendirmelerin ve canonical’ların her mimaride neden önemli olduğunu anlamak için yararlı bir arka plan. (Standart sorumluluk reddim geçerlidir: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Resmî

• Google — Site moves with URL changes — URL değiştiren her tedarikçi geçişinin yararlanması gereken disiplin.
• Google — Redirects and Google Search — 301’in eski URL’yi yenisinde nasıl birleştirdiği.
• Google — Understand JavaScript SEO basics — headless frontendin devraldığı oluşturma kuralları.
• MACH Alliance — What is Composable Commerce? — modelin tanımsal otoritesi.

Sektörden

• Shopify Enterprise — Composable Commerce Platform: Definition, Architecture, Benefits — sunum katmanı ile yığının geri kalanı arasındaki en açık ayrım ve “MACH is a pattern, not a merit badge.”
• composable.com — Headless vs Composable Commerce — composable’ın neden headless’tan daha kapsamlı olduğunu açıkça ortaya koyan bir açıklama.
• What Happened to the MACH Alliance? Composable Commerce in 2025 (John Duncan, 64labs) — composable tepkisi ve bu makalenin SEO’yla ilişkilendirdiği entegrasyon yükü savı hakkında temel okuma.
• Composable Commerce: How to Select Best-of-Breed Components (Algolia) — bir arama bileşeni tedarikçisinin bakış açısından tedarikçi seçimi çerçevesi.
• Headless Commerce and SEO in 2026: A Guide to Winning and Losing in Google (Jerry Trybuchowicz, Beecommerce) — taşıma titizliği konusunda iyidir (“every old URL must have one exact counterpart”); ancak bu makalenin düzelttiği şekilde headless ile composable’ı birbirine karıştırır.
• Composable Commerce SEO: How to Build a Headless SEO Strategy (Mirumee) — karşılaştırmaya değer bir uygulayıcı composable SEO değerlendirmesi.
• r/TechSEO — tedarikçiler arası yönlendirme, canonical ve URL yapısı sorunlarında hata ayıklama topluluğu.

Değişiklik günlüğü