Astro ile SEO

TL;DR — Astro, SEO için harika bir seçimdir. Varsayılan olarak sayfalarınızı önceden düz HTML dosyalarına dönüştürür; dolayısıyla Google (veya herhangi bir bot) geldiğinde içeriğiniz zaten oradadır — JavaScript’in çalışmasını beklemek gerekmez. Ayrıca çok hızlıdır. Bilmeniz gereken tek şey şudur: Astro size temiz HTML sunar ancak sayfa başlıklarınızı, site haritanızı veya canonical etiketlerinizi otomatik olarak eklemez. Bunları kendiniz ayarlarsınız (bu kolaydır).

”Astro SEO” ne anlama gelir?

Astro, web siteleri oluşturmak için kullanılan bir web framework’üdür. Temel fikri “daha az JavaScript”tir. React veya Next.js gibi framework’ler sayfayı çoğu zaman tarayıcınızda JavaScript kullanarak oluştururken Astro, sayfalarınızı derleme zamanında düz HTML dosyalarına dönüştürür ve sayfanın bir bölümü gerçekten ihtiyaç duymadığı sürece neredeyse hiç JavaScript göndermez. Evidence for this claim Astro prerenders pages as static HTML by default and only sends client JavaScript for explicitly hydrated components. Scope: Astro default static output and islands architecture. Confidence: high · Verified: 2026-07-14 Astro: Why Astro

Bu tek fark, Astro’nun arama motorlarıyla neden bu kadar uyumlu olduğunu açıklıyor. Bir arama motoru sayfayı taradığında içeriğinizi okumak ister. Yoğun JavaScript kullanan bir sitede içerik bazen henüz sayfada bulunmaz — botun önce JavaScript’i çalıştırması gerekir ve bu işlem gecikebilir. Astro’da ise sayfa yüklenir yüklenmez içerik zaten HTML’nin içindedir. Beklenecek hiçbir şey yoktur.

Kendi sitem patrickstox.com’u Astro üzerinde çalıştırıyorum — dolayısıyla bu benim için teoriden ibaret değil. Gerçekten kullandığım teknoloji yığını bu.

Astro SEO için neden iyidir?

• İçerik hemen HTML’nin içindedir. Oluşturma gecikmesi veya eksik içerik yoktur.
• Hızlıdır. Astro siteleri hafiftir ve Google’ın sayfa deneyimi metriklerinde (Core Web Vitals) genellikle çok iyi puan alır.
• Her sayfanın kendine ait gerçek bir URL’si vardır. Tarayıcı botlarını şaşırtabilecek karmaşık tek sayfalı uygulama yönlendirmeleri yoktur.
• JavaScript yalnızca gerektiği yerde yüklenir. Bir fotoğraf galerisi veya arama kutusu, sayfanın geri kalanını yavaşlatmadan etkileşimli olabilir.

Astro sizin için neleri YAPMAZ?

Bu nokta insanların kafasını karıştırır. “Astro SEO için optimize edilmiştir” ifadesi yalnızca yarı yarıya doğrudur. Astro size temiz bir temel sunar ancak şunları otomatik olarak yapmaz:

• Sayfanızın başlıklarını ve meta açıklamalarını yazmak.
• Bir site haritası oluşturmak (bunun için ücretsiz resmî eklentiyi eklersiniz).
• Canonical etiketleri eklemek (bunlar Google’a bir sayfanın “resmî” sürümünü bildirir).
• Yapılandırılmış veri eklemek (zengin sonuçları sağlayan kod).
• Bir robots.txt dosyası oluşturmak. Evidence for this claim Astro's official sitemap integration generates sitemap files from statically generated routes. Scope: Astro @astrojs/sitemap integration. Confidence: high · Verified: 2026-07-14 Astro: Sitemap integration

Bunların hiçbiri zor değildir — yalnızca kurulumu sizin yapmanız gerekir. Astro’yu harika bir mutfak gibi düşünün: cihazlar mükemmeldir ancak yine de yemeği sizin pişirmeniz gerekir.

Basit başlangıç kontrol listesi

• Resmî @astrojs/sitemap eklentisiyle bir site haritası ekleyin.
• Her sayfada bir title, description ve canonical URL belirleyin (genellikle ortak bir layout dosyası üzerinden).
• Fotoğraflar için Astro’nun yerleşik <Image /> bileşenini kullanın — hızlı yüklenmelerini sağlar ve sayfanın yer değiştirmesini önler.
• public/ klasörünüze bir robots.txt dosyası koyun.

Server Islands, View Transitions, statik ve sunucu taraflı oluşturma ile kaçınılması gereken hataları ayrıntılı olarak mı görmek istiyorsunuz? Advanced sekmesine geçin. Arama motorlarının JavaScript’i nasıl işlediğine ilişkin genel görünüm için JavaScript SEO sayfasına bakın.

TL;DR — Astro, mimari açıdan SEO için iyi hazırlanmıştır: sayfalar ve endpoint’ler varsayılan olarak statik HTML biçiminde önceden oluşturulur; dolayısıyla bu içerik için bir oluşturma kuyruğu dalgasını beklemek gerekmez. Ancak bu yalnızca varsayılandır, evrensel bir garanti değildir; statik/sunucu HTML’si tek başına üretim URL’lerinizin taranabilirliğini, dizine eklenmesini, sıralamalarını veya Core Web Vitals sonuçlarını kanıtlamaz. Islands mimarisi yalnızca client:* direktifiyle işaretlediğiniz bileşenleri hydrate eder — diğer her şey kendi hydration JS’i olmadan HTML gönderir; ancak sayfa script’leri, diğer island’lar ve router geliştirmeleri sayfanın başka yerlerine yine de JavaScript ekleyebilir. Astro meta etiketleri, canonical’ları, site haritalarını veya yapılandırılmış verileri otomatik oluşturmaz — bunları açıkça bağlayın; tercihen Content Collections + Zod ile doğrulayın. Bir adapter gerektiren Server Islands, statik kabuğu ilk belgede fallback içeriğiyle sunar ve ertelenmiş içeriği sonrasında bağımsız olarak getirir — varsayımda bulunmak yerine belirli bir tarayıcının gerçekte ne aldığını doğrulayın. View Transitions, history.pushState kullanır ve SEO açısından güvenlidir; Google alttaki MPA sayfalarını normal biçimde tarar. patrickstox.com’u Astro üzerinde çalıştırıyorum ve aşağıdaki özellikler gerçekten kullandıklarımdır — yalnızca yerel geliştirmede değil, dağıtılmış sitede doğrulanmıştır. Evidence for this claim Astro prerenders pages as static HTML by default and only sends client JavaScript for explicitly hydrated components. Scope: Astro default static output and islands architecture. Confidence: high · Verified: 2026-07-14 Astro: Why Astro

Astro, JavaScript oluşturma sorununu neden tamamen aşar?

JavaScript SEO’nun zor olmasının temel nedeni ikinci dalgadır. Google önce ham HTML’nizi alır, ardından sayfayı daha sonra headless Chromium’da oluşturulmak üzere kuyruğa koyar — risk de bu kuyruktur. Google’ın kendi dokümanları bunu şöyle açıklar: “Googlebot queues all pages with a 200 HTTP status code for rendering unless a robots meta tag tells Google not to index the page. The page may stay on this queue for a few seconds, but it can take longer than that.” İstemci tarafında oluşturulan bir SPA’da içeriğiniz, bu oluşturma dalgası çalışana kadar mevcut değildir.

Astro’nun varsayılan çıktı modu static’tir: sayfalar ve endpoint’ler derleme zamanında eksiksiz bir HTML dosyası olarak önceden oluşturulur. Dolayısıyla bu varsayılanı kullanan bir route için ham HTML, oluşturulmuş sayfanın kendisidir. Bu route’ta çalıştırılacak hiçbir şey kalmadığından beklenmesi gereken ikinci bir dalga yoktur. Googlebot ilk istekte tüm içeriği görür. Joost de Valk’ın (Yoast’ın kurucusu) ifadesiyle, “From an SEO perspective, static HTML on a CDN is a better starting point than most CMSes will ever give you.” Evidence for this claim Astro uses static output and prerenders routes at build time by default. Scope: Astro default output mode; routes can opt out of prerendering. Confidence: high · Verified: 2026-07-14 Astro: On-demand rendering

Ancak bu varsayılandır — her route’un evrensel bir özelliği değildir. output: 'server' ayarladığınızda varsayılan, isteğe bağlı oluşturmaya geçer (aşağıda daha fazlası var); statik varsayılanlı bir projede bile adapter, tek bir route’un export const prerender = false ile bunun dışında kalmasına olanak tanır. Bunların hiçbiri yalnızca mimari tarafından garanti edilmez: statik veya sunucu HTML’si, island’lar ve adapter’lar kendi başlarına taranabilirliği, dizine eklenmeyi, sıralamaları veya Core Web Vitals sonuçlarını garanti etmez — bunlar dağıtılmış route’a ve belirli tarayıcıya bağlıdır; bu nedenle framework’ün bunları hallettiğini varsaymak yerine doğrulayın.

Bu, hiç oluşturma yapamayan tarayıcılara da yardımcı olur. Google açıkça “not all bots can run JavaScript” diyor — çoğu AI tarayıcısı ve birçok üçüncü taraf araç açısından 2026 gerçeği de budur. Astro’nun HTML öncelikli çıktısı, yalnızca Googlebot tarafından değil, gerçekten önceden oluşturulduğu yerlerde bunların tümü tarafından okunabilir. (Headless CMS için SEO yazımda da aynı noktayı vurguluyorum: oluşturma modu ürünün kendisidir.)

Islands mimarisi: Yalnızca istediğiniz yerde JS

Astro bileşenlerinizi HTML’ye dönüştürür ve kendi ifadesiyle “just HTML & CSS, stripping out all client-side JavaScript automatically.” Etkileşim isteğe bağlıdır. Bir bileşeni client:* direktifiyle — client:load, client:idle veya client:visible — işaretlersiniz ve JavaScript ile yalnızca o island hydrate edilir. Diğer her şey statik HTML olarak kalır. Evidence for this claim Astro client directives selectively hydrate interactive islands while other components remain static HTML. Scope: Astro islands and client directives. Confidence: high · Verified: 2026-07-14 Astro: Islands

SEO açısından bu ideale yakındır. Googlebot’un dizine eklemesi gereken içerik düz HTML’dir ve etkileşimli widget’larınız onu yavaşlatmaz. client:visible özellikle kullanışlıdır: ekranın ilk görünümünün altındaki bir bileşen, görünür alana kaydırılana kadar hydrate edilmeye başlamaz; dolayısıyla LCP’nizi hiçbir zaman engellemez. Kavram, Preact’in yaratıcısı Jason Miller’dan gelir; seçici hydration için “rendering HTML pages on the server, and inject[ing] placeholders or slots around highly dynamic regions” ifadesini kullanmıştır.

Rakip içeriklerde birbirine karıştırılma eğilimi gösterdikleri için iki ayrımı netleştirmekte yarar var:

• client:only farklı bir yapıdır. client:load/client:idle/client:visible aksine, client:only bileşeni sunucu taraflı oluşturmayı tamamen atlar — sunucuda hiçbir HTML üretmez. Yalnızca bir client:only bileşeninin içine yerleştirilen dizine eklenebilir içerik, Googlebot’un aldığı belgede bulunmaz; ancak tarayıcı bileşeni hydrate ettikten sonra mevcut olur. Birincil içeriği buraya koymayın.
• Bu, resumability değil seçici hydration’dır. Astro her island’ın istemci kodunu tarayıcıda sıfırdan yeniden çalıştırır; örneğin Qwik’in resumability modelinde olduğu gibi sunucuda serileştirilmiş yürütme durumunu sürdürmez. Yazılarda bu ikisi birbirine karıştırılır — aynı mekanizma değildir. Evidence for this claim A client:only component skips server rendering, so indexable content placed only inside it cannot be assumed to exist in the initial page HTML. Scope: client and server islands Confidence: high · Verified: 2026-07-16 Template directives reference

Hydrate edilmemiş bir bileşen, sayfadaki JavaScript tablosunun tamamı değildir. “Zero JS”, client:* direktifi olmayan tek bir bileşeni tanımlar — Astro aynı sayfanın başka yerlerinde sayfa düzeyinde <script> etiketleri, View Transitions router’ı ve diğer island’ları yine de gönderebilir. Gönderilenleri sayfa hakkında genel bir iddia olarak değil, bileşen/route bazında açıklayın.

Astro otomatik olarak neleri YAPMAZ?

Astro temiz, semantik HTML üretir — SEO açısından başka hiçbir şey üretmez. Kutudan çıktığı hâliyle metadata, canonical, site haritası veya yapılandırılmış veri yoktur. “Astro otomatik olarak SEO için optimize edilmiştir” iddiası tam anlamıyla bir mittir. Şunlar sizin sorumluluğunuzdadır:

• Meta etiketleri (title, description, Open Graph, Twitter)
• Canonical URL’ler
• Site haritası (resmî entegrasyon aracılığıyla)
• Yapılandırılmış veri / JSON-LD
• robots.txt

Astro, kullandığım en iyi temeldir; ancak tamamlanmış bir ev değil, yalnızca temeldir.

Site haritası: @astrojs/sitemap

npx astro add sitemap komutuyla kurun. Statik olarak oluşturulan route’larınızı tarar ve derleme zamanında bir sitemap-index.xml ile parçalara ayrılmış sitemap-0.xml dosyaları üretir. İnsanların karşısına çıkan iki sorun vardır: Evidence for this claim Astro's official sitemap integration generates sitemap files from statically generated routes. Scope: Astro @astrojs/sitemap integration. Confidence: high · Verified: 2026-07-14 Astro: Sitemap integration

• astro.config.mjs içinde site: ayarlamalısınız. Bu olmadan entegrasyon sessizce hiçbir şey üretmez. “Site haritam nerede?” sorusunun en yaygın nedeni budur.
• Site haritası satırını robots.txt dosyasına kendiniz eklemelisiniz. Astro bunu yapmaz.

Kontrol amacıyla filter() route’ları hariç tutar (önizleme/taslak sayfaları — bu sitede tam olarak bunun için kullanıyorum), serialize() ile lastmod/changefreq/priority belirleyebilirsiniz ve i18n seçeneği site haritasında hreflang girdileri üretir. Güncel @astrojs/sitemap dokümanlarında belirtilen davranış budur — eski bir sürüm kullanıyorsanız kurulu sürümünüzle karşılaştırarak doğrulayın; entegrasyon davranışı daha önce ana sürümler arasında değişmiştir.

İnsanların kafasını karıştıran kapsam: Entegrasyonun keşif mekanizması statik olarak oluşturulmuş route’ları hedefler. URL’lerinizden herhangi biri yalnızca çalışma zamanında mevcutsa — sunucu tarafında oluşturulan (output: 'server') route’lar veya derleme zamanı yerine talep üzerine oluşturulan route’lar — bunların site haritasında olduğunu varsaymayın. customPages ile açıkça ekleyin ve ardından gerçekten orada olduklarını doğrulamak için bir derlemeden sonra sitemap-index.xml dosyasını açın. Derleme zamanında oluşturulan statik bir route olmayan hiçbir şey için “entegrasyon bunu hallediyor” varsayımına güvenmeyin.

Meta etiketleri ve canonical’lar: BaseLayout kalıbı

Astro’nun özel bir <Head> bileşeni yoktur — .astro dosyalarında <head> üzerinde doğrudan kontrol sahibisiniz. Standart kalıp (benim de kullandığım), title, description ve canonicalURL değerlerini props olarak alan ve head bölümünü yazan tek bir BaseLayout.astro dosyasıdır. Her sayfada canonical’ı açıkça belirleyin ve og:url ile tutarlı tutun. Bir kütüphaneye ihtiyacınız yoktur; ancak isterseniz topluluğa ait astro-seo paketi (npm), title/description/OG/Twitter/canonical için kullanışlı, tek bileşenli bir sarmalayıcıdır.

SEO güvenlik ağı olarak Content Collections

Bu, Astro’nun değeri yeterince bilinmeyen SEO özelliğidir. Content Collections, Markdown/MDX/JSON içeriğiniz için Zod şema doğrulaması sunan, tür güvenli bir içerik katmanıdır. Bu sayede title ve description alanlarını zorunlu alanlar yapabilirsiniz — bir sayfada bunlardan biri eksikse derleme başarısız olur. Yanlışlıkla başlıksız bir sayfa yayımlayamazsınız. Sorgu fonksiyonları (getCollection(), getEntry()) derleme zamanında statik sayfalar üretir; bu nedenle dağıtıldığında çıktı düz HTML’dir. MDX ham Markdown’ı tek doğru kaynak olarak koruduğundan bu dosyalar, AI tarayıcıları ve llms.txt benzeri kalıplar için de temiz kaynak içeriktir. Bu site, Zod ile doğrulanan frontmatter kullanan Content Collections üzerine kurulmuştur.

astro:assets: Görselleri doğru kullanmak (bir tuzakla birlikte)

<Image /> bileşeni görselleri otomatik olarak WebP’ye dönüştürür, “avoid Cumulative Layout Shift (CLS)” amacıyla boyutları çıkarır, varsayılan olarak loading="lazy" ayarlar ve alt gerektirir — eksik bir alt, derleme hatasıdır. <Picture />, bunu AVIF/WebP/fallback <source> öğeleriyle genişletir.

Tuzak şudur: Otomatik loading="lazy", LCP görseliniz (genellikle hero) için yanlıştır. En önemli görselinizi tembel yüklemek onu geciktirir. İlk görünüm alanındaki görsellerde loading="eager" ve fetchpriority="high" ile varsayılanı geçersiz kılın. Uzak görseller açıkça belirtilmiş width ve height değerleri gerektirir.

Server Islands: Tarayıcılar gerçekte ne görür?

Server Islands (Astro 4.12+), rakip rehberlerin en sık yanlış anlattığı özelliktir. server:defer kullanıldığında bir bileşen, ana sayfadan bağımsız olarak sunucuda oluşturulur. Statik kabuk hemen sunulur; Astro’nun dokümanlarına göre, “Your page will be rendered immediately with any specified fallback content as a placeholder. Then, the component’s own contents are fetched on the client and displayed when available.”

İki noktayı tam olarak açıklamak gerekir. Birincisi, Server Islands bir adapter gerektirir — tamamen statik bir derlemenin kendiliğinden ürettiği bir şey değil, isteğe bağlı bir özelliktir. İkincisi, sıra şöyledir: İlk belge, fallback içerik olarak yapılandırdığınız şeyle birlikte gönderilir ve island’ın gerçek içeriği, sayfa yüklendikten sonra kendi endpoint’i üzerinden alınan ayrı ve bağımsız bir istektir. Bu, ilk belgenin içerdikleri için kesin alt sınırdır — dağıtılmış URL’lerinizi doğrudan test etmeden her belirli tarayıcının daha sonra ne yaptığı konusunda bunun ötesinde genelleme yapmam.

SEO açısından sonuç somuttur: Bir tarayıcının ilk istekte okuduğu statik HTML, ertelenmiş island içeriğini değil fallback içeriğinizi barındırır. Bu, Server Islands’ın kullanım amacı olan kişiselleştirilmiş ve oturuma özgü içerikler (oturum açma durumu, sepet sayısı, öneriler) için idealdir; bunlar zaten önbelleğe alınmamalı veya dizine eklenmemelidir. Birincil, dizine eklenebilir içerik içinse yanlıştır. Sıralanması gereken her şeyi ana Astro şablonuna koyun ve Server Islands’ı çevresindeki dinamik parçalar için kullanın.

Çıktı modları: static ve server ile route bazında geçersiz kılma

Astro’nun varsayılan çıktı modu static’tir — sayfalar ve endpoint’ler derleme zamanında HTML olarak önceden oluşturulur. astro.config.mjs içinde output: 'server' ayarladığınızda varsayılan, isteğe bağlı oluşturmaya geçer: Sayfalar her istekte bir adapter aracılığıyla oluşturulur; bu, kimlik doğrulama, gerçek zamanlı veri veya Server Islands’ın kapsamadığı kişiselleştirme için kullanışlıdır. Her iki durumda da varsayılanı route bazında geçersiz kılabilirsiniz: Statik varsayılanlı bir projede export const prerender = false, route’u isteğe bağlı oluşturmaya geçirir; sunucu varsayılanlı bir projede export const prerender = true, route’u yeniden derleme zamanında önceden oluşturmaya geçirir. Dolayısıyla “sitem statik” veya “sitem SSR” ifadesi nadiren her route için doğrudur — yalnızca üst düzey yapılandırmayı değil, route bazındaki ayarı kontrol edin. Evidence for this claim Astro uses static output and prerenders routes at build time by default. Scope: Astro default output mode; routes can opt out of prerendering. Confidence: high · Verified: 2026-07-14 Astro: On-demand rendering

Salt SEO açısından önceden oluşturulmuş ve isteğe bağlı HTML eşdeğerdir — route’un tam markup ile 200 döndürdüğünü gerçekten doğruladıktan sonra ikisi de tarayıcının ilk isteğine eksiksiz HTML sunar. İsteğe bağlı route’lar HTML’lerini stream edebilir; yavaş veri veya ağ koşulları sonraki parçaları geciktirebilir. Bu nedenle stream edilen bir yanıt, içeriğin her parçasının ulaştığını otomatik olarak kanıtlamaz — kontrol edin, varsaymayın. İki mod arasındaki gerçek fark operasyoneldir: Önceden oluşturulmuş içerik bir sonraki derlemeye (veya ayrıca yapılandırılmış bir çalışma zamanı yenilemesine) kadar sabittir ve doğrudan CDN edge üzerinden sunulur; isteğe bağlı içerik her zaman günceldir ancak üretimde adapter ve çalışma zamanınızın sağlıklı olmasına bağlıdır. Bunu bir SEO kararı olarak görmeyin — veri güncelliği ve operasyonlara göre seçim yapın, ardından yerel geliştirmede çalışanlardan çıkarım yapmak yerine dağıtılmış route’ları, durum kodlarını, yönlendirmeleri ve yanıt header’larını doğrulayın.

View Transitions: SPA hissine rağmen SEO açısından güvenli

Astro’nun <ClientRouter /> bileşeni (önceki adıyla <ViewTransitions />), tarayıcının View Transitions API’sini ve History API’yi kullanarak SPA benzeri yumuşak gezinme sağlar. Temel gerçek şudur: history.pushState ile gezinir ve Google’ın istemci tarafı gezinme için önerdiği yöntem tam olarak budur — Google, fragment tabanlı (#hash) URL’leri “can’t reliably resolve.” diye belirtir. En önemlisi, View Transitions tarayıcı taraflı bir geliştirmedir. Googlebot tarama yaptığında her URL’yi ister ve normal, eksiksiz bir HTML sayfası alır — alttaki MPA değişmeden kalır. Geçişler yalnızca bir insanın tarayıcıda gördüklerini etkiler.

Dolayısıyla hayır, View Transitions Astro sitenizi bir SPA’ya dönüştürmez ve SEO’yu bozmaz. Dikkate değer bir eksiklik: Astro’nun View Transitions dokümanlarında SEO bölümü yoktur; “SEO’yu bozar” mitinin sürmesinin nedeni muhtemelen budur. Kendi sitenizde doğrulamak için birkaç URL’yi doğrudan alın ve her birinin eksiksiz HTML döndürdüğünü doğrulayın — inanca dayanmayın, kendi dağıtımınızı kontrol edin.

Yaygın Astro SEO hataları

1. Astro’nun SEO’yu sizin için hallettiğini varsaymak. Astro HTML’yi halleder. Meta, canonical, site haritası ve schema sizin sorumluluğunuzdadır.
2. Yapılandırmada site: değerini unutmak — site haritanız sessizce oluşturulmaz.
3. Site haritasını robots.txt dosyasına eklememek — Astro bunu yapmaz.
4. LCP görselini tembel yüklemek — hero için eager + fetchpriority kullanarak varsayılanı geçersiz kılın.
5. Dizine eklenebilir içeriği bir Server Island’a koymak — tarayıcılar içeriği değil fallback’i görür ve Server Islands en başta bir adapter gerektirir.
6. Kusursuz bir Lighthouse puanı peşinde koşup orada durmak. Hız bir sıralama sinyalidir, tek sıralama sinyali değildir. Hızlı ve boş bir sayfa sıralanmaz — içerik, bağlantılar ve E-E-A-T asıl yükü taşımaya devam eder.
7. Dizine eklenebilir içeriği yalnızca bir client:only bileşenine koymak. Diğer client:* direktiflerinden farklı olarak client:only, sunucu taraflı oluşturmayı tamamen atlar — tarayıcı bileşeni hydrate edene kadar o bileşene ait HTML yoktur.
8. “Astro statik/hızlıdır” ifadesini sonuç garantisi olarak görmek. Statik veya isteğe bağlı HTML, island’lar ve adapter’lar mekanizmalardır — kendi başlarına taranabilirliği, dizine eklenmeyi, sıralamaları veya Core Web Vitals sonuçlarını garanti etmezler. Mimari diyagramı değil, dağıtılmış route’u doğrulayın.

Bu, içerik kümesinin neresinde yer alıyor?

Astro, JavaScript SEO konusunun oluşturma hakkında ortaya koyduğu sorulara yönelik belirli ve alışılmadık ölçüde SEO dostu bir yanıttır; ayrıca headless CMS kurulumları için popüler bir frontend’dir. Performans tarafı, web performansı kümesindeki Core Web Vitals ile doğrudan bağlantılıdır; “içeriğim gerçekten HTML’nin içinde mi?” test disiplini ise tarama ve dizine ekleme kümelerindekiyle aynıdır.

Astro SEO anti-pattern’leri

Astro sitelerinde gerçekten gördüğüm somut hatalar — varsayımsal örnekler değil. Her biri tanı koymaya değil önlemeye yöneliktir: Yayımlanmadan önce yakalayın.

Astro’yu kutudan çıktığı hâliyle “SEO için optimize edilmiş” saymak

Astro size hızlı ve temiz statik HTML sunar; bu gerçekten büyük bir avantajdır — ancak meta etiketleri, canonical’lar, site haritası veya yapılandırılmış veriyle aynı şey değildir. Neden yanlış: Ekipler “Astro SEO’yu hallediyor” diyerek <title> çeşitliliği, canonical veya site haritası olmayan sayfalar yayımlar, ardından neden hiçbir şeyin beklendiği gibi dizine eklenmediğini merak eder. Bunun yerine ne yapılmalı: İlk günden BaseLayout.astro içinde title/description/canonical props değerlerini bağlayın, @astrojs/sitemap ekleyin ve bunları varsayılanlar değil, zorunlu derleme adımları olarak ele alın.

astro.config.mjs içinde site: değerini unutmak

Bu, “site haritam neden boş?” sorusunun en yaygın nedenidir. Neden yanlış: @astrojs/sitemap, mutlak <loc> girdileri oluşturabilmek için mutlak bir site URL’sine ihtiyaç duyar — site: ayarlanmadığında entegrasyon sessizce hiçbir şey üretmez (hata veya uyarı vermez). Bunun yerine ne yapılmalı: Site haritası entegrasyonunu kurmadan önce astro.config.mjs içinde site: değerini ayarlayın ve sonraki derlemeden sonra sitemap-index.xml dosyasının gerçekten URL içerdiğini kontrol edin.

Site haritasını robots.txt dışında bırakmak

@astrojs/sitemap kurmak, robots.txt dosyasına bir Sitemap: satırı eklemez — bu, insanların otomatik olduğunu varsaydığı ayrı ve manuel bir adımdır. Neden yanlış: Site haritasını Search Console’a gönderirseniz arama motorları onu yine bulabilir; ancak diğer botların (ve Bing/IndexNow ile ilişkili tarayıcıların) kullandığı pasif keşif yolunu kaybedersiniz. Bunun yerine ne yapılmalı: public/ içindeki robots.txt dosyanıza Sitemap: https://yoursite.com/sitemap-index.xml ekleyin ve dağıtımdan sonra URL’nin çözümlendiğini doğrulayın.

Hero görselinde varsayılan loading="lazy" değerini bırakmak

Astro’nun <Image /> bileşeni varsayılan olarak tembel yükleme yapar. Bu, ilk görünüm alanının altındaki görseller için doğru; genellikle LCP öğeniz olan tek görsel içinse yanlış seçimdir. Neden yanlış: Hero görselini tembel yüklemek, tarayıcının görsel isteğini başlatmasını bile geciktirir ve Largest Contentful Paint puanınıza doğrudan zarar verir. Bunun yerine ne yapılmalı: Hero/ilk görünüm alanındaki görselde açıkça loading="eager" ve fetchpriority="high" kullanarak varsayılanı geçersiz kılın; diğer tüm görselleri varsayılan tembel yüklemede bırakın.

Dizine eklenebilir içeriği bir Server Island’ın içine koymak

server:defer; sepet sayısı, oturum açma durumu ve öneriler gibi kişiselleştirilmiş, oturuma özgü içerikler için geliştirilmiştir — sıralanmasını istediğiniz şeyler için değil. Neden yanlış: Bir tarayıcının okuduğu statik HTML, sayfa yüklendikten sonra istemci tarafında getirilenleri değil, island için belirtilen fallback içeriği barındırır. Bu nedenle oraya yerleştirilen birincil içerik ilk taramada arama motorları tarafından görülemez. Bunun yerine ne yapılmalı: Sıralanacak içeriği ana Astro şablonunda tutun; Server Islands’ı yalnızca zaten dizine eklenmemesi gereken dinamik ve kişiselleştirilmiş parçalar için ayırın.

Yüksek bir Lighthouse puanını bitiş çizgisi sanmak

Astro siteleri neredeyse varsayılan olarak güçlü Core Web Vitals sonuçları verir ve burada durmak cazip gelebilir. Neden yanlış: Hız, birçok sıralama girdisinden yalnızca biridir — hızlı, boş veya zayıf bir sayfa; daha iyi içeriği, bağlantıları ve konu derinliği olan daha yavaş bir sayfayı yine de geçemez. Bunun yerine ne yapılmalı: Performansı Astro ile ücretsiz gelen temel bir gereklilik olarak görün; asıl optimizasyon çabanızı içerik kalitesine, iç bağlantılara ve Astro’nun sizin için yapmadığı yapılandırılmış veri/meta çalışmalarına harcayın.

”Varsayılan olarak statik” ifadesinin her route için geçerli olduğunu varsaymak

Astro’nun statik çıktı modu varsayılandır; ancak evrensel bir özellik değil, yalnızca bir varsayılandır — output: 'server' bunu değiştirir ve prerender her iki yönde de route bazında ayarlanabilir. Neden yanlış: Ekipler üst düzey yapılandırmaya bakarak sitelerinin tamamını “static” veya “SSR” diye tanımlar, tek tek route’ları hiç kontrol etmez ve bir route üretimde farklı davrandığında şaşırır. Bunun yerine ne yapılmalı: Hakkında çıkarımda bulunduğunuz her şey için route bazındaki prerender ayarını kontrol edin; yapılandırma dosyası yerine dağıtılmış URL’deki gerçek yanıtı (durum kodu, eksiksiz markup, yönlendirme davranışı) doğrulayın.

İçeriği yalnızca bir client:only bileşeninin içine koymak

client:only, client:load/client:idle/client:visible ile aynı değildir — sunucu taraflı oluşturmayı tamamen atlar. Neden yanlış: client:only kullanan bir bileşen sunucuda hiçbir HTML üretmez. Dolayısıyla yalnızca buraya yerleştirilen dizine eklenebilir içerik, ham yanıtı okuyan bir tarayıcı tarafından görülemez; ayrıca SEO maliyetinin farkına varmadan “basitlik” adına client:only kullanmak kolaydır. Bunun yerine ne yapılmalı: Birincil içeriği sunucu tarafında oluşturulan bir bileşende veya sayfa şablonunda oluşturun; client:only seçeneğini içinde dizine eklenebilir hiçbir şey bulunmayan, yalnızca etkileşim amaçlı widget’lar için ayırın.

AI özeti

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

• Astro’nun varsayılan çıktı modu derleme zamanında statik HTML oluşturur — bu varsayılanı kullanan bir route için ham HTML, tamamlanmış sayfanın kendisidir; dolayısıyla Google’ın oluşturma kuyruğu (“ikinci dalga”) sorunu geçerli değildir. Bu evrensel bir özellik değil, varsayılandır: output: 'server' bunu değiştirir ve prerender her iki yönde de route bazında geçersiz kılabilir.
• Islands mimarisi yalnızca client:* ile işaretlenen bileşenleri hydrate eder; bu direktiflerden biri bulunmayan bileşen, kendi hydration JS’i olmadan HTML gönderir (ancak Astro sayfanın başka yerlerine sayfa script’leri, diğer island’lar ve router JS’i ekleyebilir). client:only istisnadır — sunucu taraflı oluşturmayı tamamen atlar; dolayısıyla dizine eklenebilir içerik yalnızca orada bulunmamalıdır. Bu, resumability değil seçici hydration’dır. client:visible, ilk görünüm alanının altındaki JS’in LCP’yi engellemesini önler.
• Astro SEO açısından hiçbir şeyi otomatik oluşturmaz — meta etiketleri, canonical’lar, site haritası, yapılandırılmış veri ve robots.txt, bilinçli derleme adımlarının tümüdür. “Astro otomatik olarak SEO için optimize edilmiştir” bir mittir.
• @astrojs/sitemap statik olarak oluşturulan route’ları keşfeder — ancak yapılandırmada site: ayarlamalı (aksi hâlde sessizce hiçbir şey yapmaz), site haritası satırını robots.txt dosyasına kendiniz eklemeli ve yalnızca çalışma zamanında var olan URL’leri customPages aracılığıyla açıkça eklemelisiniz.
• Content Collections + Zod, title/description alanlarını zorunlu kılarak bunlardan biri eksik olduğunda derlemeyi başarısız hâle getirebilir — bir SEO güvenlik ağıdır.
• astro:assets <Image>, görselleri WebP’ye dönüştürür, boyutları belirler (CLS’yi önler), varsayılan olarak tembel yükler ve alt gerektirir. LCP görselinde loading="eager" + fetchpriority="high" kullanarak varsayılanı geçersiz kılın.
• Server Islands (server:defer) bir adapter gerektirir; ilk belgede statik kabuğu + fallback’i anında sunar, ardından island’ı bağımsız olarak getirir. İlk belgeyi okuyan tarayıcılar island’ı değil fallback’i görür — dizine eklenebilir içeriği asla oraya koymayın.
• Statik ve isteğe bağlı (sunucu) çıktılar doğrulandıktan sonra SEO açısından eşdeğerdir — ikisi de ilk istekte tarayıcılara eksiksiz HTML sunar; ancak isteğe bağlı route’lar stream edilebilir. Bu nedenle yanıtın gerçekten eksiksiz ulaştığını doğrulayın; modu SEO’ya göre değil, veri güncelliği ve operasyonlara göre seçin.
• View Transitions (<ClientRouter />), history.pushState kullanır ve SEO açısından güvenlidir; Google alttaki MPA sayfalarını normal biçimde tarar. Bunlar SPA dönüşümü değil, tarayıcı taraflı bir geliştirmedir.
• Yukarıdakilerin hiçbiri sonuç garantisi değildir — statik/sunucu HTML’si, island’lar ve adapter’lar mekanizmadır; taranabilirliğin, dizine eklenmenin, sıralamaların veya Core Web Vitals sonuçlarının kanıtı değildir. Dağıtılmış route’u doğrulayın.
• Astro, kendi 2023 karşılaştırmasında güçlü Core Web Vitals sonuçları yayımladı — Astro sitelerinin %50’den fazlası Google’ın CWV değerlendirmesini geçti ve o dönemin sektör taban çizgisinin oldukça üzerinde kaldı; bunu canlı bir garanti değil, tarihli bir veri noktası olarak değerlendirin.

Resmî dokümantasyon

Astro ve arama motorlarının birincil kaynak dokümanları.

Astro

• Islands Architecture — Astro’nun istemci tarafı JS’i nasıl kaldırdığı ve yalnızca etkileşimli bileşenleri nasıl hydrate ettiği.
• Template Directives Reference — client:load/idle/visible/only ve server:defer; client:only seçeneğinin atladıkları dâhil.
• Image Optimization (astro:assets) — <Image>/<Picture> bileşenleri, WebP, boyutlar ve CLS.
• @astrojs/sitemap — otomatik site haritası oluşturma, filter, serialize ve i18n.
• Server Islands — server:defer, adapter gereksinimi, fallback içerik ve ertelenmiş istemci tarafı getirme.
• On-Demand Rendering — static/server çıktı modları, route bazında prerender ve HTML streaming.
• Routing Reference — sayfaların ve endpoint’lerin varsayılan olarak nasıl önceden oluşturulduğu.
• Astro Runtime API Reference — Response/yönlendirme işleme ve varsayılan durum kodları.
• Content Collections — Zod şema doğrulamasıyla tür güvenli içerik.
• View Transitions — <ClientRouter /> ve History API gezinmesi.

Google

• Understand JavaScript SEO Basics — oluşturma kuyruğu, taranabilir bağlantılar, History API ve “not all bots run JavaScript” uyarısı.
• In-Depth Guide to How Google Search Works — tarama → oluşturma → dizine ekleme ve SSG’nin oluşturma adımını kaldırdığı nokta.

Bing / Microsoft

• IndexNow / indexnow.org — statik bir Astro dağıtımıyla iyi çalışan push protokolü (Bing ve Yandex’in yeni sayfalardan hemen haberdar olması için yayınlama adımınıza bağlayın).

Kaynaktan alıntılar

Astro dokümanlarından, Google’dan ve adı belirtilen uygulayıcılardan kayda geçmiş açıklamalar. Her arama motoru ve doküman bağlantısı, kaynak sayfadaki alıntılanan bölüme doğrudan giden bir deep link’tir.

Google — Astro’nun aştığı oluşturma kuyruğu

• “Googlebot queues all pages with a 200 HTTP status code for rendering unless a robots meta tag tells Google not to index the page. The page may stay on this queue for a few seconds, but it can take longer than that.” Alıntıya git
• “not all bots can run JavaScript” — HTML öncelikli çıktının Googlebot dışındaki botlara da neden yardımcı olduğu. Alıntıya git

Astro dokümanları — islands, görseller, site haritaları, Server Islands

• “just HTML & CSS, stripping out all client-side JavaScript automatically.” — islands mimarisi hakkında. Alıntıya git
• “infers image dimensions to avoid Cumulative Layout Shift (CLS).” — Image bileşeni hakkında. Alıntıya git
• “Your page will be rendered immediately with any specified fallback content as a placeholder. Then, the component’s own contents are fetched on the client and displayed when available.” — Server Islands hakkında. Alıntıya git

Jason Miller (Preact’in yaratıcısı, “islands architecture” terimini ortaya atan kişi)

• Seçici hydration, “rendering HTML pages on the server, and inject[ing] placeholders or slots around highly dynamic regions.” yöntemiyle çalışır. — Astro Docs: Islands Architecture içinde alıntılanmıştır

Joost de Valk (Yoast SEO’nun kurucusu)

• “From an SEO perspective, static HTML on a CDN is a better starting point than most CMSes will ever give you.” — Joost.blog: Astro SEO Complete Guide

Astro SEO kontrol listesi

Bir Astro sitesinin yalnızca iyi bir temel üzerinde durmakla kalmayıp arama için gerçekten hazırlandığını doğrulama turu:

• astro.config.mjs içinde site: ayarlanmış (bu olmadan site haritası sessizce oluşturulmaz).
• @astrojs/sitemap kurulmuş ve site haritası referansı robots.txt dosyasına manuel olarak eklenmiş.
• public/ içinde bir robots.txt var ve dizine eklenmesini istediğiniz hiçbir şeyi engellemiyor.
• Her sayfa benzersiz bir title ve description belirliyor (tercihen ortak bir BaseLayout.astro aracılığıyla).
• Her sayfada kendisine referans veren bir canonical var ve og:url ile eşleşiyor.
• Content Collections, title/description alanlarını zorunlu kılan bir Zod şeması kullanıyor (eksik olduklarında derleme başarısız olur).
• Görseller <Image /> / <Picture /> kullanıyor; tümünde alt var (eksik olması zaten derleme hatasıdır).
• LCP/hero görseli, loading="eager" ve fetchpriority="high" ile varsayılan tembel yüklemeyi geçersiz kılıyor.
• Bir Server Island (server:defer) içinde dizine eklenebilir içerik yok — tarayıcılar fallback’i görür ve Server Islands’ın çalışması için adapter gerekir.
• Dizine eklenebilir içerik yalnızca bir client:only bileşeninde bulunmuyor — bu direktif sunucu taraflı oluşturmayı atlar; tarayıcı hydrate edene kadar HTML yoktur.
• output: 'server' veya route bazında prerender = false kullanan her route için, yalnızca çalışma zamanında var olan URL’lerin site haritasına açıkça (customPages) eklendiği doğrulanmış — otomatik site haritası keşfi statik olarak oluşturulan route’ları hedefler.
• Yapılandırılmış veri (JSON-LD), sunucu tarafında oluşturulan <head> içindedir.
• <ClientRouter /> etkinse her URL’nin doğrudan istekte hâlâ eksiksiz HTML döndürdüğü örneklerle kontrol edilmiştir.
• İsteğe bağlı/sunucu route’ları: Canlı üretim URL’sini doğrudan alın ve durum kodunu, yönlendirme davranışını ve eksiksiz yanıt HTML’sini doğrulayın — adapter/çalışma zamanı davranışı farklı olabileceğinden yerel geliştirmeden çıkarım yapmayın.

Zihinsel modeller

1. Ham HTML, tamamlanmış sayfadır — ilgili route’un varsayılanı için. Astro’nun statik çıktı modu, önceden oluşturulmuş bir route için beklenecek oluşturma dalgası olmadığı anlamına gelir — Googlebot’un aldığı şey dizine eklenir. Bu, site genelinde bir garanti değil, route bazında varsayılandır (output: 'server' ve route bazındaki prerender bunu değiştirebilir); dolayısıyla yalnızca üst düzey yapılandırmayı değil, route’u kontrol edin. Geçerli olduğunda View Source gerçeğin kendisidir (CSR SPA’nın tam tersi) — ancak bunu gerçek kabul etmeden önce geçerli olduğunu doğrulayın.

2. Temel, bitmiş ürün değildir ve sonuç garantisi de değildir. Astro size temiz HTML ve güçlü performans mekanizmalarını ücretsiz sunar. Arama motorlarına anlam bildiren her şey — meta, canonical, site haritası, schema — sizin eklediğiniz bilinçli bir adımdır. “İyi mimari” ≠ “tamamlandı” ve bunların hiçbiri taranabilirliğin, dizine eklenmenin veya sıralamaların kanıtı değildir — bunlar dağıtılmış sitede ayrıca doğrulanmalıdır.

3. Islands eklemelidir — client:only hariç. client:load/client:idle/client:visible için etkileşim HTML’nin üzerine eklenir, asla altında yer almaz: Bu direktifler taranabilir tabandaki içeriği kaldırmadan tek bir bileşene JS ekler. client:only bu kalıbı bozar — sunucu taraflı oluşturmayı tamamen atlar; dolayısıyla eklemeli değildir ve önlem almadığınız sürece statik HTML’de gerçek bir boşluk yaratır. Ayrıca island hydration seçicidir, resumability değildir — ikisini birbirine karıştırmayın.

4. Tarayıcıların gördüğü şey statik kabuktur. Server Islands için tarayıcı, ertelenmiş içeriği değil statik kabuktaki fallback’i okur. Karar kuralı: Dizine eklenebilir içerik ana şablona; kişiselleştirilmiş/dinamik içerik island’a gider.

5. Tarayıcı geliştirmesi ≠ yapısal değişiklik. View Transitions tarayıcı deneyimini (history.pushState aracılığıyla yumuşak gezinme) değiştirir, tarama deneyimini değiştirmez (her URL hâlâ eksiksiz bir HTML sayfasıdır). Alttaki MPA’yı olduğu gibi bırakan geliştirmeler SEO açısından güvenlidir.

6. Derleme zamanında doğrulayın. Content Collections + Zod, “başlık eklemeyi unutma” talimatını “başlık olmadan derleme yayımlanmaz” kuralına dönüştürür. SEO gereksinimlerini tür sistemine taşıdığınızda bunlar unutabileceğiniz şeyler olmaktan çıkar.

Astro SEO — kısa başvuru

Neler otomatik, neler sizin sorumluluğunuzda?

Çıktı modları

Islands direktifleri

• client:load — hemen hydrate et.
• client:idle — tarayıcı boştayken hydrate et.
• client:visible — görünür alana kaydırıldığında hydrate et (ilk görünüm alanının altı için en iyi seçenek; LCP’yi korur).
• client:only — sunucu taraflı oluşturmayı tamamen atlar. Tarayıcı hydrate edene kadar bu bileşen için HTML yoktur; diğerleri gibi eklemeli değildir.

Hızlı kurallar

• site: eksik → site haritası yok (sessizce).
• Server Island’da dizine eklenebilir içerik → tarayıcı fallback’i görür; Server Islands bir adapter gerektirir.
• Yalnızca client:only içinde dizine eklenebilir içerik → ona ait hiçbir HTML yoktur.
• Site haritası statik route’ları kapsar → yalnızca çalışma zamanındaki URL’leri customPages aracılığıyla ekleyin.
• View Transitions history.pushState kullanır → SEO açısından güvenlidir, altında MPA vardır.
• Statik/sunucu çıktısı ve island’lar mekanizmadır, garanti değildir — sonuç iddiasında bulunmadan önce dağıtılmış route’u, durum kodunu ve eksiksiz HTML’yi doğrulayın.
• Hızlı ve boş bir sayfa yine de sıralanmaz — hız bir sinyaldir, tek sinyal değildir.

Astro’nun oluşturduğu HTML’yi denetleyin

Bunu astro build sonrasında çalıştırın. Kaynak bileşen ağacını değil, tarayıcıların aldığı derleme çıktısını kontrol eder:

find dist -name '*.html' -type f | while IFS= read -r file; do
  canonicals=$(grep -Eio '<link[^>]+rel=["'"']canonical["'"'][^>]*>' "$file" | wc -l | tr -d ' ')
  titles=$(grep -Eio '<title>[^<]*</title>' "$file" | wc -l | tr -d ' ')
  if [ "$canonicals" -ne 1 ] || [ "$titles" -ne 1 ]; then
    printf '%s\ttitles=%s\tcanonicals=%s\n' "$file" "$titles" "$canonicals"
  fi
done

Boş bir sonuç, oluşturulan her HTML dosyasında tam olarak bir title ve canonical bulunduğu anlamına gelir; bunların değerlerinin doğru olup olmadığını doğrulamaz, bu nedenle örnekleri ayrıca inceleyin. Bu yalnızca derleme çıktısını kontrol eder — statik dosya olarak mevcut olmayan isteğe bağlı (output: 'server') route’lar veya Server Islands hakkında hiçbir şey söylemez.

Üretimdeki canlı route’ları örneklerle kontrol edin

İsteğe bağlı oluşturulan hiçbir şey — output server route’ları, route bazında prerender false veya Server Islands — için yukarıdaki derleme çıktısı kontrolü geçerli değildir. Bunun yerine dağıtılmış gerçek yanıtı kontrol edin:

# Replace with your real URLs
for url in "https://example.com/" "https://example.com/some-server-route/"; do
  echo "== $url =="
  curl -sS -D - -o /dev/null "$url" | grep -Ei '^(HTTP|location|cache-control):'
done

Beklediğiniz durum kodunu arayın (canlı bir sayfa için 200, yönlendiriliyorsa gerçek bir yönlendirme kodu — kontrol etmeden 302 veya 301 olduğunu varsaymayın) ve Server Island içeren bir sayfayı kontrol ediyorsanız curl -sS "$url" komutunun fallback kabuk değil, eksiksiz markup döndürdüğünü doğrulayın. Bunu astro dev yerine üretimde yapın — adapter ve çalışma zamanı davranışı yerelden farklı olabilir.

Astro sitesi için araçlar

• @astrojs/sitemap — resmî site haritası entegrasyonu (astro add sitemap). Yapılandırmadaki site: değerini unutmayın.
• astro-seo (npm) — title, description, Open Graph, Twitter kartları ve canonical’ı tek etikette birleştiren isteğe bağlı topluluk bileşeni.
• astro-seo-schema (npm) — Astro için türlendirilmiş JSON-LD yapılandırılmış veri yardımcısı.
• astro:assets <Image> / <Picture> — yerleşik görsel optimizasyonu (WebP/AVIF, boyutlar, tembel yükleme, alt zorunluluğu).
• URL Inspection (Google Search Console) — içeriğinizin taranmış HTML’de bulunduğunu doğrulayın (Astro ile zaten View Source içinde olmalıdır — hızlı bir tutarlılık kontrolü).
• JS oluşturan bir tarayıcı — site genelinde ham ve oluşturulmuş çıktı eşitliğini doğrulamak için Ahrefs Site Audit veya Screaming Frog kullanın (önceden oluşturulan route’larda eşleşmeleri gerekir — varsaymayın, doğrulayın ve isteğe bağlı veya Server Island route’larını ayrıca kontrol edin).
• IndexNow — Bing ve Yandex’in yeni statik sayfalardan hemen haberdar olması için dağıtım/yayınlama adımınızla eşleştirin.

Kendinizi sınayın: Astro SEO

Astro mimarisinin SEO’yu nasıl etkilediğine ilişkin beş kısa soru. Her biri için bir yanıt seçin, ardından kontrol edin.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• JavaScript SEO: A Definitive Guide — Astro’nun HTML öncelikli çıktısının neden bu kadar avantajlı olduğunu açıklayan oluşturma temelleri.
• The Beginner’s Guide to Technical SEO — framework seçiminin genel görünümdeki yeri.

Konuşmalarım

• How Search Works (SlideShare) — Astro’nun SSG varsayılanının kısalttığı tarama, oluşturma, dizine ekleme ve sıralama hattına ilişkin anlatımım. (Sürekli geçerli uyarı: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Sektörden kaynaklar

• Astro Docs: Islands Architecture — Astro’nun istemci tarafı JS’i nasıl kaldırdığına ilişkin temel açıklama.
• Astro Docs: @astrojs/sitemap — resmî kurulum, site: gereksinimi ve filter/serialize/i18n seçenekleri.
• Astro Docs: Server Islands — server:defer, fallback içerik ve tarayıcıların görmediği istemci tarafı getirme davranışı.
• Joost de Valk: Astro SEO Complete Guide — Yoast’ın kurucusundan en güvenilir uygulayıcı rehberi; modern AI’a hazır kalıplar ve IndexNow konusunda güçlüdür.
• Google Search Central: Understand JavaScript SEO Basics — Astro’nun View Transitions özelliğinin izlediği oluşturma kuyruğu, taranabilir bağlantılar ve History API rehberliği.
• Astro: 2023 Web Framework Performance Report — Astro’yu diğer framework’lerle karşılaştıran Core Web Vitals verileri.
• Search Engine Journal: Core Web Vitals, WordPress and Astro — Astro ve WordPress performans karşılaştırmasının bağımsız incelemesi.

Alıntılanmaya değer istatistikler

Aşağıdaki tüm rakamlar Astro’nun 2023 Web Framework Performance Report’undan (ve SEJ’in incelemesinden) alınmıştır; bunları canlı rakamlar değil, 2023 dönemine ait karşılaştırma ölçütleri olarak değerlendirin.

• Astro sitelerinin %50’den fazlası Google’ın Core Web Vitals Assessment testini geçiyor — yaklaşık %40,5 olan sektör ortalamasının üzerinde; Astro ve SvelteKit, bu taban çizgisini geçen tek büyük framework’lerdi (Next.js yaklaşık %25, Nuxt yaklaşık %20). Kaynak
• Astro için INP geçme oranı %68,8 — ana thread’i serbest tutan MPA mimarisine (JS ile yürütülen gezinme olmamasına) bağlanıyor. Kaynak
• Medyan sayfa ağırlığı 1,65 MB — veri kümesindeki en hafif değer. Kaynak
• LCP: Astro yaklaşık 0,44 s, WordPress yaklaşık 0,81 s — rapordaki karşılaştırmada yaklaşık %46 daha hızlı. İnceleme

Değişiklik günlüğü