AMP'den Responsive Web Tasarıma Güvenli Geçiş

AMP’den responsive web tasarıma geçiş; AMP URL’lerinin canonical responsive URL’lere yönlendirilmesini, rel=”amphtml” bağlantı etiketlerinin kaldırılmasını ve Largest Contentful Paint (LCP) gibi performans metriklerinin doğrulanmasını içerir. Site sahipleri bu geçişi, mobil cihazlarda organik arama sıralamalarını ve sayfa hızı performansını korurken kod bakımını basitleştirmek için gerçekleştirirler.

Yayıncılar neden responsive web tasarım lehine AMP’den ayrılıyor?

Hızlandırılmış Mobil Sayfalar (AMP), katı HTML kısıtlamaları uygulayarak ve sayfaları Google AMP Önbelleklerinde önbelleğe alarak mobil cihazlarda neredeyse anında yükleme süreleri sunmak için tanıtılmıştı. Zaman içinde modern Web API’leri ve mobil tarayıcılar önemli ölçüde ilerledi. CSS Grid, flexbox ve modern görsel formatlarıyla oluşturulmuş responsive düzenler, artık iki ayrı kod tabanını korumak zorunda kalmadan kısıtlı AMP çerçevelerinin oluşturma hızını eşitleyebilir veya aşabilir.

Standart masaüstü sayfaları ve mobil AMP sayfaları için paralel şablonları sürdürmek operasyonel ek yük oluşturur. Her iki biçimde de tasarım sistemlerini, izleme etiketlerini ve etkileşimli bileşenleri güncellemek yinelenen geliştirme çabası gerektirir. Ek olarak, AMP içindeki özel JavaScript sınırlamaları genellikle e-ticaret özelliklerini, abonelik ödeme duvarlarını ve dinamik kullanıcı arayüzlerini kısıtlar.

Google, arama indekslemesinde ve değerlendirmesinde responsive web sayfalarına ve AMP sayfalarına eşit davranır. Responsive bir sayfa standart performans kriterlerini karşıladığı ve yüksek kullanılabilirlik sağladığı sürece, arama algoritmaları AMP çerçevesini emekliye ayırma için herhangi bir ceza uygulamadan onu indeksler ve sıralar.

Google Arama, AMP sayfalarını diğer web sayfaları gibi indeksler ve sayfayı oluşturmak için kullanılan teknolojiye bakılmaksızın tüm sayfalara aynı standartı uygular.

Google Search Central

AMP’yi kapatmadan önce sitenizi nasıl hazırlamalısınız?

Başarılı bir kaldırma süreci, kırık bağlantıların, indeksleme hatalarının veya zengin sonuç özelliklerinin kaybolmasını önlemek için kapsamlı bir hazırlık gerektirir. Sunucu yapılandırmalarını değiştirmeden önce, aktif AMP URL’lerinizin tüm envanterini denetleyin. İçerik Yönetim Sistemleri genellikle standart kalıcı bağlantılara /amp/ veya ?amp=1 ekleri ekleyerek tanımlanması gereken eşleştirilmiş URL kalıpları oluşturur.

Her iki biçimdeki yapılandırılmış veri işaretlemenizi gözden geçirin. Article, NewsArticle, Product veya BreadcrumbList gibi yapılandırılmış veri şemaları, hem AMP sayfasında hem de canonical hedef sayfada aynı şekilde mevcut olmalıdır. Hedef sayfada eksik şema işaretlemesi, arama SERP’lerinde zengin sonuç iyileştirmelerinin kaybolmasına neden olabilir.

• Sunucu erişim günlüklerini ve tarama araçlarını kullanarak yayınlanan tüm AMP URL’lerini denetleyin.
• Responsive hedef sayfaların aynı yapılandırılmış veri şemasını içerdiğini doğrulayın.
• Responsive şablonlarınız için temel Core Web Vitals performans kıyaslamaları oluşturun.
• Responsive mobil düzenlerin Google mobil kullanılabilirlik kontrollerini geçtiğinden emin olun.

Adım adım süreç: AMP’den responsive’e nasıl geçilir?

Geçiş süreci, sırayla yürütülen üç ana operasyonel aşamadan oluşur: bağlantı etiketinin kaldırılması, sunucu yönlendirmesinin uygulanması ve indeksleme temizliği.

İlk olarak, canonical responsive sayfalarınızın HTML başlığından rel=”amphtml” etiketini kaldırın. Bu etiket, arama tarayıcılarını bir AMP alternatifinin varlığı konusunda bilgilendirir. Bu etiketin çıkarılması, arama motorlarına artık içeriğiniz için yeni AMP varyantları aramamaları veya keşfetmemeleri gerektiğini bildirir.

İkincisi, web sunucunuzda veya uç sunucu ağınızda kalıcı HTTP 301 yönlendirmeleri yapılandırın. Bir AMP URL’sine yapılan her istek (örneğin, example.com/article/amp/), doğrudan ilgili ana responsive URL’ye (example.com/article/) işaret eden 301 durumuyla hemen yanıt vermelidir. Geçici 302 yönlendirmelerinden kaçının, çünkü 301 başlıkları arama tarayıcılarına indeksleme sinyallerini kalıcı hedef olan yeni konuma aktarmalarını açıkça söyler.

Tarama ve indeksleme için Google Arama, bir AMP sayfasının canonical bir sayfaya bağlantı vermesini gerektirir.

Google Search Central

Üçüncüsü, 301 yönlendirmelerini süresiz olarak veya en az bir tam yıl boyunca aktif tutun. Arama motorlarının, üçüncü taraf dizinlerinde ve harici web referanslarında depolanan mevcut AMP bağlantılarını yeniden taramak için zamana ihtiyacı vardır. Yönlendirmeleri erken kaldırmak, mobil kullanıcılar için 404 hata artışlarına yol açabilir.

AMP kaldırılırken Core Web Vitals LCP nasıl korunur?

AMP’den uzaklaşırken birincil operasyonel risk, mobil hız metriklerinde, özellikle de Largest Contentful Paint’te (LCP) düşüştürür. AMP, ana kahraman görsellere otomatik olarak öncelik vermiş ve kritik olmayan komut dosyalarını ertelemiştir. Standart responsive HTML’e geçerken geliştiriciler, bu yükleme optimizasyonlarını manuel olarak aktif bir şekilde uygulamalıdır.

Mobil cihazlarda önerilen 2.5 saniyelik kıyaslamanın altında LCP tutmak için kahraman varlıklarını açıkça optimize edin. Mobil cihazların uygun ölçekte indirilmiş dosyaları indirmesi için srcset ve sizes nitelikleri gibi responsive görsel sözdizimini kullanın. Tarayıcı ayrıştırıcısına hemen getirmesini söylemek için HTML’nizin içindeki ana öne çıkan görsele fetchpriority=”high” niteliğini ekleyin.

Oluşturmayı engelleyen gecikmeleri önlemek için CSS dosyalarını küçültün ve kritik görünüm alanı stilini satır içi yapın. Düzen yüklenirken görünmez metni önlemek için web fontlarının font-display: swap kullandığından emin olun. Bu yapısal ayarlamalar, responsive şablonların daha önce Google AMP önbellekleri tarafından sağlanan hızlı deneyimle eşleşmesini sağlar.

AMP sayfaları emekliye ayrılırken yapılan yaygın hatalar

Birçok site mi̇grasyonu, uygulama gözden kaçmaları nedeniyle sıralama dalgalanmalarından muzdariptir. Emekliye ayrılan AMP uç noktaları için HTTP 404 (Bulunamadı) veya 410 (Gitti) durum kodlarını döndürmekten kaçının. Hata kodları döndürmek, arama motorlarını, birikmiş bağlantı sinyallerini ana sayfalarınıza aktarmadan bu URL’leri bırakmaya zorlar.

• Canonical ve AMP uç noktaları arasında yönlendirme döngüleri yapılandırma.
• Kalıcı 301 yönlendirmeleri yerine geçici 302 durum kodları kullanma.
• AMP URL’lerini işaret eden menülerdeki, kenar çubuklarındaki veya altbilgilerdeki dahili bağlantıları güncellemeyi unutma.
• Responsive sayfaların hızlı mobil yükleme hızları sunduğunu doğrulamadan önce AMP sayfalarını kaldırma.

Alien Road AMP mi̇grasyonunu nasıl uygular

Alien Road’da, AMP’yi emekliye ayırmaya yönelik teknik uygulama sürecimiz otomatik haritalamaya, kesintisiz daıtıma ve sürekli performans takibine odaklanır. Tipik bir müşteri ilişkisinde, doğrudan sunucu günlük dosyalarından ve Google Search Console indeksleme raporlarından tüm indekslenmiş AMP URL’lerini çıkararak başlıyoruz.

Bulut sunucu kuralları veya CDN uç sunucuları içinde programatik 1’e 1 yönlendirme tabloları oluşturuyoruz. Değişiklikleri canlı ortama göndermeden önce ekibimiz, responsive URL’ler arasında şema eşitsizliğini önlemek için doğrulama araçlarını kullanarak yapılandırılmış veri bütünlüğünü denetler. Dağıtımdan sonra, temiz durum kodu dağılımını doğrulamak için 60 günlük bir pencerede dizin yeniden taramalarını izliyoruz.

Bu hafta mi̇grasyonunuza nereden başlamalısınız

Mevcut AMP kurulumunuzun envanterini çıkararak başlayın. Sitenizin AMP içeriği sunmak için CMS eklentilerine mi yoksa özel şablon oluşturmaya mı güvendiğini belirleyin. Geçiş sırasında izlemek için Google Search Console’dan en çok ziyaret edilen 100 mobil sayfanızı dışarı aktarın.

10 ila 20 düşük riskli sayfadan oluşan bir grupta küçük bir pilot mi̇grasyon çalıştırın. Bu test sayfalarındaki rel=”amphtml” etiketlerini kaldırın, 301 sunucu yönlendirmelerini dağıtın ve URL’leri Search Console’da yeniden gönderin. Tam site genelinde bir sunum başlatmadan önce tarama yanıtını ve sayfa performansı metriklerini yedi gün boyunca izleyin.