Tulisan ini bertujuan untuk memberikan petunjuk bagi pemilik situs untuk mengetahui bagaimana cara memindahkan situsnya dari HTTP ke HTTPS dari sudut pandang SEO, dengan membahas alasan perlunya pindah dari HTTP ke HTTPS, strategi dalam memilih sertifikat SSL dan berapa banyak website dipindahkan, menentukan sinyal on-page teknis paling umum yang dibutuhkan untuk diupdate ke HTTPS agar tidak terjadi konflik di mesin pencari, bagaimana mengkonfigurasi Google Search Console sewaktu melakukan perpindahan ke HTTPS, bagaimana memonitor akibat dari perpindahan di Google Search Console dan file server log, dan meningkatkan performa sinyal dengan HSTS dan HTTP/2.
Pengertian HTTPS dan Alasan Menggunakannnya
Jika anda memiliki sebuah situs atau sedang mengunjungi sebuah situs secara online, anda harus memperhatikan apakah situs itu HTTP atau HTTPS. HTTPS, kependekan dari Hypertext Transfer Protocol over TLS, adalah sebuah protokol yang memungkinkan komunikasi antara jaringan komputer berlangsung secara aman, seperti browser pada komputer lokal atau layanan server sewaktu sebuah konten diakses. Semua website di dunia maya menggunakan HTTP atau HTTPS.
Banyak keuntungannya kalau menggunakan HTTPS, tetapi dari kebanyakan itu ada beberapa yang penting bagi pengguna, diantaranya adalah:
- Keamanan, HTTPS bisa menangkal serangan pihak ketiga.
- Kerahasiaan, pihak lain tidak dapat mengakses data yang ada di sebuah situs.
- Kecepatan situs
Bagi pemilik situs, HTTPS juga mempunyai beberapa keuntungan, diantaranya:
- Keamanan, situs akan aman bertransaksi sehingga tingkat kepercayaan bertambah.
- Data referal di Analitik tetap terjaga.
- Berpotensi meningkatkan ranking di hasil pencarian Google Pencari.
- Situs dengan HTTP akan dianggap tidak aman, sementara HTTPS akan dianggap aman oleh mesin pencari.
- Kecepatan situs
Namun demikian, menggunakan HTTPS mempunyai masalahnya sendiri. Itulah sebabnya baru separuh dari situs di
dunia ini telah menggunakan protokol aman ini, tetapi jumlahnya terus berkembang. Adapun permasalahan menggunakan HTTPS ini diantaranya:
- Biaya tambahan, karena sertifikat SSL komersil mempunyai biaya sendiri, dan juga biaya tambahan untuk infrastruktur server.
- Kesulitan teknis, sewaktu menerapkan sertifikat SSL di sebuah server tidaklah mudah untuk mempertahankan ranking di mesin pencari, apalagi jika situsnya sudah besar.
- Sewaktu menukar dari HTTP ke HTTPS, situs tersebut akan dibaca oleh mesin pencari sedang melakukan perpindahan. Akibatnya situs dengan HTTPS ini akan diranking rendah hingga seluruh isi situs tersebut selesai di rayapi dan diproses.
- Terdapat konflik dengan design asli dari WWW, dimana tambahan “S” pada protokol HTTPS akan merusak hiperlink.
- Berpindah ke HTTPS merupakan strategi jangka panjang. Jika sudah komit untuk pindah ke HTTPS, artinya tidak ada cerita untuk kembali pindah ke HTTP.
Bagaimana pun juga, keuntungan jangka panjang menggunakan HTTPS lebih besar dibandingkan tidak menggunakannya. Sekarang ini semakin banyak yang mempedulikan terhadap keamanan dan HTTPS menyediakan tambahan keamanan bagi pengguna dan juga akan membangun kepercayaan antara mereka dengan situs yang dikunjungi. Disamping itu, penting juga disadari bahwa Google lebih menyukai situs yang dipercaya dan tersertifikasi. Makanya, sekarang Google akan memberi nilai tambah di hasil pencarinya kalau sebuah situs sudah pindah dari HTTP ke HTTPS. Itulah alasannya kenapa sebuah website harus pindah dari HTTP ke HTTPS dari sudut pandang SEO.
Mempersiapkan Sertifikat SSL
Sebelum dilanjutkan ke aspek SEO ketika pindah dari HTTP ke HTTPS, terlebih dahulu anda harus pastikan setup dari server telah diterapkan dengan benar dan tidak ada masalah ketika konten tersebut dipindahkan.
Membeli Sertifikat Komersial SSL
Anda bisa saja menggunakan sertifikat SSL gratisan, tetapi satu hal yang tidak dipunyai oleh sertifikat gratisan itu dibandingkan dengan sertifikat SSL berbayar adalah validasi atas otoritas sertifikat SSL tersebut. Harga sertifikat SSL sekarang ini harganya sudah cukup murah. Bahkan telah menjadi bagian dari harga penyewaan hosting (Niagahoster merupakan salah satu penyedia hosting yang menawarkan sertifikat SSL gratis untuk semua layanannya).
Ada beberapa tipe dari sertifikat SSL berdasarkan proses validasinya. Pada prinsipnya, apapun bentuknya tidak ada masalah.
Enkripsi
Beberapa pilihan tersedia ketika membuat sertifikat SSL (komersial atau tidak). Dianjurkan untuk memilih sertifikat SHA2 (seperti SHA256) karena sertifikat jenis ini lebih aman dibandingkan sertifikat SHA1. Sertifikat SHA1 ini telah dianggap usang oleh sebagian besar mesin pencari. Di akhir tahun 2016, website yang menggunakan sertifikat SHA1 akan disampaikan tidak aman oleh mesin pencari, ini artinya sama saja tidak menggunakan HTTPS sama sekali.
Implementasi Pada Server
Untuk mengimplementasikan sertifikat SSL pada infrastruktur server, tanyakanlah pada penyedia layanan hosting, tim IT atau developer situs. Jika menggunakan Server Name Indication, periksa ulang data analitik pada website tersebut jika pada browser tertentu, yang tidak mendukung SNI, masih ada kunjungan dari sana ke website.
Setelah server di set dengan sertifikat SSL bagi nama domain pada port 443, setup dan seluruh server harus diperiksa dan divalidasi. Sertifikat SSL dapat divalidasi menggunakan
https://www.sslshopper.com/ssl-checker.html, dan untuk memeriksanya apakah sudah benar atau belum silakan pergunakan
https://www.ssllabs.com/ssltest/index.html. Dengan melakukan pemeriksaan ini, jika ada terjadi kesalahan, bisa langsung diketahui dan diperbaiki sebelum anda lanjut ke langkah selanjutnya.
Catatan: Untuk menghindari kesalahan ketika mengupdate sebuah website sewaktu memindahkan situs dari HTTP ke HTTPS, sangat direkomendasikan sekali untuk membuat home direktori terpisah pada server yang sama atau server lain dan alihkan trafik HTTPS ke direktori ini.
Perlu diingatkan kembali untuk memastikan bahwa anda telah meregister sertifikat SSL ini untuk jangka waktu cukup lama (sebaiknya 5 tahun) sehingga anda tidak akan direpotkan untuk memperpanjangnya tiap tahun.
Mempersiapkan Proses Pindah Dari HTTP ke HTTPS
Sebelum melangkah ke tahap berikutnya, diasumsikan bahwa situs anda:
- Tidak ada dilakukan perubahan terhadap konten (kecuali tautan anotasi)
- Tidak ada dilakukan perubahan terhadap template (kecuali tautan anotasi).
- Tidak ada dilakukan perubahan struktur URL (kecuali bagi perubahan pada protokol).
- Versi HTTPS pada nama domain telah aktif pada port 443, dan telah divalidasi seperti disampaikan di atas. Biasanya root nama domain pada HTTPS direktorinya menjadi kosong.
Menentukan Strategi Perpindahan Konten
Langkah selanjutnya adalah memilih strategi untuk memindahkan situs dari HTTP ke HTTPS. Untuk memindahkan website kecil (URL nya kurang dari 10 ribu buah) atau situs besar (URL nya lebih dari satu juta URL) ke HTTPS cara memindahkannya akan jauh berbeda. Sebagai contoh:
- Memindahkan seluruh domain ke HTTPS, termasuk seluruh subdomainnya dalam sekali jalan.
- Memindahkan satu atau beberapa subdomain dan/atau subdirektori ke HTTPS, sebelum memindahkan secara keseluruhan.
- Memindahkan konten dan mengoperasikan dua situs duplikat pada HTTP dan HTTPS sebelum menyelesaikan perpindahan.
Sebagai bagian dari strategi perpindahan, pertanyaan berikut perlu anda jawab. Berapa lama versi HTTP tadi masih bisa diakses?
Faktor-faktor yang perlu diperhatikan bisa akan berbeda tergantung dari ukuran website, ketersediaan dukungan teknis dan struktur organisasi website tersebut.
Pentingnya Bujet Perayapan
Agar mesin pencari memproses perubahan protokol, bot mesin pencari harus merayapi ulang bagian penting dari URL HTTP dan seluruh URL HTTPS baru dari website. Jadi, sebuah website mempunyai 1.000.000 URL. Ini artinya bot mesin pencari harus merayapi ulang sekitar 2.000.000 URL agar bisa melakukan 301 redirect dan mengkalkulasi ulang ranking terhadap URL yang telah menjadi HTTPS tadi, berdasarkan URL dari domain yang HTTP. Jika sebuah bot mesin pencari merayapi sekitar 30.000 unik URL tiap harinya, artinya dia membutuhkan 67 hari untuk merayapi ulang
seluruh URL. Selama proses perayapan ulang ini, website mungkin mengalami penurunan ranking di mesin pencari.
Memanfaatkan Server Log Files
Untuk memastikan bujet bot mesin pencari tidak terbuang percuma, langkah pertama anda harus memeriksa kembali Server Log Files dan temuka URL mana yang telah dirayapi oleh bot mesin pencari di dua tahun terakhir (atau rentang waktu lebih lama, jika memungkinkan). Langkah ini juga akan membantu untuk mengetahui seberapa sering URL di web tersebut dirayapi (gunanya untuk menentukan prioritas perayapan), tetapi dalam kasus kita kali ini, seluruh URL adalah prioritas utama. Selanjutnya, tulisan ini akan memfokuskan diri pada perayapan data dari Googlebot.
Cara Mengekspor URL dari server log menggunakan Screaming Frog Log Analyser
Sebelum mulai, perlu bagi anda untuk menanyakan layanan penyedia hosting terhadap log file ini. Jika tidak ada tersedia log file untuk dua tahun terakhir (dianggap situs anda tidak situs baru), silakan mulai. Tanpa log file, susunannya akan hilang pada data vital dan data SEO, dan data anlitik bisnis akan terabaikan.
Simpan URL yang terekstrak pada file berbeda (satu URL per baris), misal nama filenya : logs_extracted_url.csv.
Mengekstrak URL Sitemap
Diasumsikan bahwa website anda telah memiliki satu atau dua buah XML Sitemap, dan sitemap ini terdiri dari seluruh halaman canonical unik yang telah terindeks di website, Google Search Console akan menyampaikan berapa banyak URL di XML sitemap tadi telah disubmit ke Google. Download dan ekstrak seluruh URL unik tadi dari XML Sitemaps.
Simpan URL yang telah terekstrak tadi pada file tersendiri (satu URL per baris), sebagai sitemap_extracted_urls.csv.
Berapa Banyak Website Dipindahkan ke HTTPS?
Untuk mengkalkulasikan jumlah URL yang harus dipindahkan, anda butuh data-data berikut:
- Daftar URL unik dirayapi oleh Googlebot diekstrak dari Server Log Files
- Jumlah rata-rata berapa banyak URL dirayapi oleh Googlebot tiap hari, berdasarkan jumlah dari statistik perayapan di Google Search Console dan pada Server Log Files.
- Daftar URL yang telah diekstrak dari XML Sitemap
Jika jumlah rata-rata URL dirayapi oleh Googlebot per harinya (berdasarkan Server Log Files) adalah diantara 5% hingga 100% dibandingkan dari total URL yang diekstrak dari XML Sitemaps, biasanya akan tidak ada masalah untuk memindahkan seluruh domain sekaligus ke HTTPS. Kemungkinannya adalah seluruh domain akan dirayapi ulang oleh bot mesin pencari sekitar tiga hingga empat minggu, tergantung dari struktur tautan internal dan beberapa faktor lainnya. Anggaplah ini sebagai skenario 1:, yaitu Memindahkan Website Sekaligus
Jika rata-rata jumlah URL dirayapi oleh Googlebot perharinya hanya antara 1% hingga 5% dibandingkan dengan total URL yang telah diekstrak dari XML sitemap, akan lebih aman untuk memindahkan satu atau beberapa subdomain saja terlebih dahulu dan/atau subdirektorinya ke HTTPS. Dalam kasus ini, kemungkinannya adalah akan lebih lama bagi Googlebot untuk merayapi ulang
seluruh URL di domain tersebut, dan akibatnya akan lebih lama agar bisa tampil seperti semula di hasil mesin pencari. Anggaplah skenario ini 2: Pindah Sebagian.
Perindahan ini dilakukan beberapa kali tergantung besarnya situs hingga seluruh domain selesai dipindahkan semuanya ke HTTPS.
Dan jika websitenya sangat besar, maka kita harus memilih pilihan berikut ini. Pilihan ini butuh mengoperasikan kedua versi website yaitu HTTP dan HTTPS. Ketika menunggu untuk URL web dirayapi secara signifikan, kanonikal digunakan untuk memindahkan konten. Agar bisa terlaksana dengan baik, pemilik situs masih tergantung pada sinyal canonikal situs agar dipercaya oleh mesin pencari. Anggaplah skenario ini disebut skenario 3: Pindah melalui kanonikal.
Ketika jumlah URL dirayapi oleh googlebot dirasa telah mencukupi, skenario 1 atau 2 bisa diterapkan untuk menyelesaikan perpindahan dari HTTP ke HTTPS.
Merayapi Situs HTTP
Selanjutnya, menggunakan sebuah perayap, seperti Screaming Frog SEO Spider, Deep Crawl, Botify atau OnPage.org untuk merayapi seluruh website atau bagian tertentu di dalam situs pada protokol HTTP dan mengekstrak seluruh URL yang bisa dirayapi oleh mesin pencari, dimana masing-masing URL tersebut saling terhubung. Ini termasuk seluruh aset internal website, seperti robots.txt, Javascript, gambar, jenis huruf, dan file CSS. Data ini akan dibutuhkan hingga akhir pindah dari HTTP ke HTTPS. Perlu anda pastikan bahwa seluruh data tersebut telah pindah dengan baik dan benar.
Simpan URL terekstrak ini dalam file tersendiri (satu URL per baris) dengan nama : crawl_extracted_urls.csv.
Penting: Jika website itu terlalu besar, seperti URL nya lebih dari 10 juta buah, skenario pindah sebagian atau pindah melalui kanonikal dianjurkan karena cara ini adalah cara paling aman. Cobalah membagi situs itu dalam beberapa bagian, berdasarkan subdomain dan/atau subdirektori, dan rayapi bagian tersebut satu persatu dari pada merayapinya secara keseluruhan.
Memblok Bot Mesin Pencari
Dalam kasus perpindahan website dengan cara sekaligus atau berpindah sebagian, serta tergantung dari ukuran website, dan seberapa cepat langkah-langkahnya dilaksanakan dan diselesaikan, juga perlu dipertimbangkan untuk memblok bot mesin pencari agar tidak merayapi website HTTPS ketika diset agar tidak ada terdeteksi masalah konflik di mesin pencari. Ini bisa dilakukan dengan menggunakan robots.txt pada versi HTTPS, dan seluruh atau sebagian versi HTTPS akan diblokir agar tidak dirayapi oleh bot mesin pencari. Pergunakan kode snippet dibawah ini pada robots.txt pada versi web HTTPS untuk memblok seluruh bot agar tidak merayapi seluruh web.
User-Agent: *
Disallow: /
Catatan: Langkah ini tergantung dari besar situs dan seberapa cepat sebuah web bisa dipindahkan. Jika web itu dapat dipindahkan dalam beberapa hari saja, anda tidak perlu melakukan langkah ini. Metode ini bisa juga digunakan untuk memeriksa seluruh aspek agar perpindahan dapat dilakukan secara aman, sebelum membiarkan bot mesin pencari mengetahui dan merayapinya.
Ada dua buah tantangan ketika memindahkan situs dari HTTP ke HTTPS, yaitu:
- Membeli dan menginstal sertifikat. Proses pembelian dan menginstal sertifikat ini sangat menantang bagi orang yang kurang mengetahui teknik dan caranya atau tidak berpengalaman mengenai menset hostingnya. Untungnya, sekarang ini telah banyak layanan hosting yang telah memberikan layanan perpindahan situs dari HTTP ke HTTPS, bahkan ada yang gratis.
- Tantangan kedua adalah susahnya memastikan bahwa seluruh aset website telah dipindahkan secara aman (seperti gambar, plugin, javascript, dan segala sesuatu agar situs itu bisa jalan dengan baik di versi HTTPS). Bagi situs kecil, memastikan seluruh aset situs tidaklah terlalu sulit. Tetapi lain ceritanya kalau situsnya sudah besar, bisa menghabiskan waktu berminggu, bahkan dapat dalam hitungan bulan.
Mengkopi dan Mengupdate Konten
Salinlah konten dari versi HTTP ke lokasi dimana server sudah menjadi versi HTTPS, termasuk XML sitemap dan file-file lainnya. Biasanya anda cukup mengkopikan konten tersebut dari satu direktori ke direktori lainnya di dalam satu server.
Setelah semuanya dilaksanakan, versi HTTPS masih butuh diupdate. Saran perubahan di bawah ini hanya akan bisa dilakukan pada versi HTTPS dan tidak pada versi HTTP, kecuali ada pengecualian.
Canonical
Lakukan update seluruh canonical ke URL absolut HTTPS pada versi HTTPS.
<link href="http://www.example.com/deep/url" rel="canonical" />
menjadi
<link href="https://www.example.com/deep/url" rel="canonical" />
Hindari menggunakan URL relatif pada canonical. Jika tidak terdapat canonical di dalam situs, rubahlah canonical tadi sebelum melakukan update. Selain itu, pastikan juga untuk mengupdate canonical pada versi mobile website ke versi HTTPS.
Pagination
Jika pagination digunakan pada situs, update URL absolut HTTPS pada versi HTTPS berikut ini:
<link href="http://www.example.com/deep/url?page=1" rel="prev" />
<link href="http://www.example.com/deep/url?page=3" rel="next" />
menjadi
<link href="https://www.example.com/deep/url?page=1" rel="prev" />
<link href="https://www.example.com/deep/url?page=3" rel="next" />
Alternate Annotation
Ada beberapa anotasi alternatif yang bisa dilakukan pada sebuah website, dan seluruh anotasi tadi perlu pula di update, yaitu:
Hreflang
Jika sebuah website menggunakan anotasi Hreflang pada seluruh XML sitemaps, tag berikut perlu juga di perbaiki ke URL absolute HTTPS pada versi HTTPS.
<link rel="alternate" hreflang="x-default" href="http://www.example.com/" />
<link rel="alternate" hreflang="es" href="http://www.example.com/es/" />
<link rel="alternate" hreflang="fr" href="http://www.example.com/fr/" />
menjadi
<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />
<link rel="alternate" hreflang="es" href="https://www.example.com/es/" />
<link rel="alternate" hreflang="fr" href="https://www.example.com/fr/" />
Mobile
Jika situs anda mempunyai versi mobile yang terpisah, anotasi juga perlu dirubah, yaitu:
<link rel="alternate" media="only screen and (max-width: 640px)" href="http://m.example.com/page-1">
menjadi
<link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.example.com/page-1">
Feeds
Anotasi alternatif Atom atau RSS atau JSON feed perlu juga di update di website.
<link href="http://www.example.com/feed/rss/" rel="alternate" type="application/rss+xml" />
<link href="http://www.example.com/feed/atom/" rel="alternate" type="application/atom+xml" />
<link href="http://www.example.com/json.as" rel="alternate" type="application/activitystream+json" />
menjadi
<link href="https://www.example.com/feed/rss/" rel="alternate" type="application/rss+xml" />
<link href="https://www.example.com/feed/atom/" rel="alternate" type="application/atom+xml" />
<link href="https://www.example.com/json.as" rel="alternate" type="application/activitystream+json" />
Internal Links
Jika di website itu hanya menggunakan relatif internal link, termasuk pada Javascript dan file CSS, anda bisa mengabaikan step ini.
Internal link sangat penting bagi pengguna dan mesin pencari, dan sebagian besar website juga bergantung kepada aset ini, seperti Javascript, CSS, Web Fonts, Video dan file gambar, termasuk juga favicon. Seluruh tautan internal dan referensi internal dapat ditemukan melalui sumber HTML dan bisa juga terdapat tautan internal di dalam aset tersebut, seperti referensi file gambar pada file CSS atau internal URL pada file Javascript.
Sebagai contoh, tipe tautan internal di bawah ini perlu diupdate
juga,
yaitu:
- Tautan ke URL internal lainnya di dalam HTML source code.
- Tautan ke file gambar internal di dalam HTML source code.
- Tautan ke file video internal di dalam HTML source code.
- Tautan ke Fonts Web internal di dalam HTML source code.
- Tautan ke file Javascripts internal di dalam HTML source code
- Tautan ke URL internal di dalam HTML source code.
- Tautan ke file gambar internal di dalam file Javascript.
- Tautan ke file internal CSS di dalam file Javascript.
- Tautan ke file internal CSS di dalam HTML source code.
- Tautan ke internal file CSS di dalam HTML source code
- Tautan ke file gambar internal di dalam file CSS.
- Tautan ke internal Fonts Web di dalam file CSS.
- Dan tautan lainnya.
Untuk melakukan update ini, berikut beberapa pilihan yang bisa dilakukan, yaitu:
Pilihan 1
Menukarnya hanya dengan menggunakan URL relatif, sebagai contoh:
<a href="http://www.example.com/">home</a>
Menjadi
<a href="/">home</a>
Pilihan ini mungkin akan terjadi konflik antara tautan internal di aset, terutama ketika pada file CSS dan/atau file Javascript. Disamping itu juga, hal ini akan berguna untuk menentukan URL base tag di bagian atas HEAD dari HTML source code dengan pilihan berikut:
<base href="https://www.example.com" />
Pilihan 2
Merubah protokol absolut URL internal dari HTTP ke HTTPS, seperti:
<a href="http://www.example.com/">home</a>
Menjadi
<a href="https://www.example.com/">home</a>
Pilihan 3
Membuang protokol absolut URL internal, seperti:
<a href="http://www.example.com/">home</a>
Menjadi
<a href="//www.example.com/">home</a>
Pilihan ini akan membuat tautan tidak tergantung pada protokol dari URL yang dikunjungi.
Bagi mesin pencari dan pengguna, tidak akan menjadi masalah pilihan mana yang akan digunakan, karena bot dan browser telah cukup pintar untuk menentukan URL absolut yang akan dipakai. Tetapi, berdasarkan pengalaman, pilihan kedua merupakan pilihan paling aman.
WordPress
Kalau anda menggunakan WordPress, untuk pindah dari HTTP ke HTTPS bisa menggunakan plugin https://en-gb.wordpress.org/plugins/better-search-replace/. Dengan plugin ini bisa langsung mengupdate tautan internal di dalam database. Disamping itu, jangan pula lupa untuk mengupdate file tema dan General Setting.
Internal Redirects
Jika ada tautan internal menuju ke internal dan diredirect ke URL internal lainnya, sangat direkomendasikan untuk mengurangi rantai redirect dan tetap meningkatkan struktur tautan internal dengan menautkannya langsung ke canonical URL yang telah berada pada website HTTPS, daripada melakukan internal redirect.
Tambahan lagi, struktur internal linking harus diupdate agar mengurangi rantai redirect.
Mengupdate Setingan CDN
Seringkali, tautan digunakan untuk merender sebuah URL, seperti Javascript, gambar dan file CSS, dimana akan di load dari sebuah CDN (Content Distribution Network) yang mungkin dibawah kontrol pemilik situs. Tautan yang menuju ke asset yang diload dari CDN harus di load kembali dari HTTPS. Pada kasus ini, bisa juga membuang protokolnya dari URL absolut, sebagai contoh:
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.1.0/jquery.min.js"></script>
Menjadi
<script src="//ajax.googleapis.com/ajax/libs/jquery/3.1.0/jquery.min.js"></script>
Ini artinya bahwa CDN harus di enable kan ke server aset melalui HTTPS. Jika CDN tidak dipetakan ke subdomain dari website, dan biasanya, di bawah kontrol pemilik dari website, lantas sertifikat SSL yang sama butuh di upload juga ke CDN dan digunakan bagi semua permintaan (tergantung pada tipe sertifikat SSL).
Jika file sumber aset awal diakses dalam versi HTTPS, dan biasanya tertaut ke versi CDN pada HTTPS, sangat penting untuk mengkanolisasi versi CDN ke HTTPS kembali ke file sumber aset pada versi HTTPS menggunakan HTTP Header. Sebagai contoh, aset pada CDN tertaut dari versi HTTPS.
<img src="//cdn.example.com/image1.png" />
Harus kembali ke referensi tautan dengan sebuah kanonikal ke file sumber aset di versi HTTPS di respon HTTP Header:
Link: <https://www.example.com/image1.png/>; rel="canonical"
Ini akan menyampaikan ke mesin pencari bahwa file sumber aset pada versi HTTPS merupakan versi asli dan mengurangi masalah potensi duplikasi dengan file aset CDN.
Ketika mengupdate pengaturan CDN, untuk terhindar dari konflik yang tidak diperlukan pada website, anda harus memastikan untuk membuang data cache pada CDN.
XML Sitemap
Diasumsikan bahwa terdapat XML Sitemap sewaktu website belum dipindahkan dari HTTP ke HTTPS (jika belum ada, pastikan terlebih dahulu untuk membuatnya atau mengekspornya berdasarkan perayapan awal bot mesin pencari). XML Sitemaps ini harus dapat diakses pada versi HTTP. Membiarkan XML sitemap pada versi HTTP akan memungkinkan bahwa Google Search Console untuk melacak status indeks (berdasarkan Sitemaps), dimana tautan itu nantinya akan berguna agar URL lama itu bisa dirayapi dan di indeks ulang pada versi HTTPS nantinya.
Pastikan tidak ada redirect atau non-existing atau URL yang tidak terindeks ada pada XML Sitemap pada versi HTTP, yang ada hanya halaman canonical yang terindeks. Disamping itu, pengajuan versus jumlah terindeks tidak bisa diandalkan.
Mengupdate XML Sitemap
Selanjutnya, kopikan XML Sitemap pada versi HTTP dan simpan ke sebuah file. Pada XML sitemap baru, rubah protokol di tiap URL, ditandai dengan pemisah. Sebagai contoh:
<url>
<loc>http://www.example.com/</loc>
<xhtml:link rel="alternate" hreflang="x-default" href="http://www.example.com/" />
<xhtml:link rel="alternate" hreflang="es" href="http://www.example.com/es/" />
<xhtml:link rel="alternate" hreflang="fr" href="http://www.example.com/fr/" />
<xhtml:link rel="alternate" media="only screen and (max-width: 640px)" href="http://m.example.com/" />
<image:image>
<image:loc>http://www.example.com/image.jpg</image:loc>
</image:image>
<video:video>
<video:content_loc>http://www.example.com/video123.flv</video:content_loc>
</video:video>
</url>
Menjadi
<url>
<loc>https://www.example.com/</loc>
<xhtml:link rel="alternate" hreflang="x-default" href="https://www.example.com/" />
<xhtml:link rel="alternate" hreflang="es" href="https://www.example.com/es/" />
<xhtml:link rel="alternate" hreflang="fr" href="https://www.example.com/fr/" />
<xhtml:link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.example.com/" />
<image:image>
<image:loc>https://www.example.com/image.jpg</image:loc>
</image:image>
<video:video>
<video:content_loc>https://www.example.com/video123.flv</video:content_loc>
</video:video>
</url>
Pada contoh di atas diasumsikan bahwa seluruh konten dipindahkan ke versi HTTPS. Jika tidak, maka cukup URL yang relevan saja.
Jika memungkinkan, buatlah XML sitemap bagi tiap subdomain atau subbagian dari website, baik dalam versi HTTP maupun versi HTTPS, dan update versi HTTPS berdasarkan kebutuhan. Jika website tersebut cukup besar, buatlah file XML Sitemap Indeks ke dalam masing-masing grup XML Sitemap. Dengan melakukan hal ini, nanti akan membantu anda untuk melacak jumlah file terindeks pada kedua versi.
Resource Hints
Jika website menggunakan Resource Hints, seperti dns-prefetch, preload, preconnect, prerender, prefetch, dan sebagainya, lantas kesemuanya ini pun perlu di update, seperti:
<link rel="preconnect" href="http://cdn.example.com" pr="0.42">
Menjadi
<link rel="preconnect" href="https://cdn.example.com" pr="0.42">
Atau
<link rel="preconnect" href="//cdn.example.com" pr="0.42">
Periksa lagi Resource Hint ini di HTTP Header, pada Head HTML, dan pada kode Javascript.
CSS dan Javascript
Kebanyakan website sangat tergantung pada asetnya, seperti CSS dan Javascript untuk saling berinteraksi. Kebanyakan kita sering melupakan hal ini ketika memindahkan konten baik itu dengan mengimpor atau membuka aset lain, seperti gambar, file CSS atau file Javascript pada server yang sama atau beda server.
@import 'http://fonts.googleapis.com/css?family=Open+Sans';
Menjadi
@import 'https://fonts.googleapis.com/css?family=Open+Sans';
Periksalah seluruh file CSS dan Javascript ini yang berbentuk “http://” dan periksalah apakah file ini bisa digantikan dengan bentuk “https://”. Jika sebuah aset itu loading menggunakan “//” pada awal URL nya, aset ini bisa tersedia dalam bentuk HTTP ataupun HTTPS, dan browser akan secara otomatis meminta versi mana dari website itu di buka (setelah semuanya selesai, dia akan tetap berada pada versi HTTPS). Tidak seluruh aset tersedia dalam bentuk HTTPS, terutama yang berasal dari pihak ketiga. Pada kasus ini, periksa lagi pada pihak ketiga, apakah dia mempunyai URL dalam bentuk HTTPS atau bersedia mengkopi asetnya ke server yang sama pada website dan mengimpornya dari sana ke codebase dan atau cari cara lainnya agar semuanya bisa berjalan lancar.
HTTP Header
HTTP Header ini sangat berguna untuk berkomunikasi sebagai sinyal SEO untuk mesin pencari. Seringkali tautan anotasi diletakkan pada kode PHP atau pada file .htaccess di server berbasis Apache. Sebagai contoh, pada .htaccess, bentuk di bawah ini bisa diaplikasikan.
<Files testPDF.pdf >
Header add Link 'http://www.example.com/ >; rel="canonical"'
</Files>
Selalu pastikan untuk memeriksa HTTP Header pada tiap tautannya dan ketika anda temukan, update mereka satu persatu, seperti:
Link: <http://www.example.com/es/>; rel="alternate"; hreflang="es"
Link: <http://www.example.com/>; rel="canonical"
Link: <http://example.com>; rel=dns-prefetch
Menjadi
Link: <https://www.example.com/es/>; rel="alternate"; hreflang="es"
Link: <https://www.example.com/>; rel="canonical"
Link: <https://example.com>; rel=dns-prefetch
Atau
Link: <//www.example.com/es/>; rel="alternate"; hreflang="es"
Link: <//www.example.com/>; rel="canonical"
Link: <//example.com>; rel=dns-prefetch
Data Terstruktur
Mesin pencari sangat menyukai data terstruktur. Dengan menggunakan data terstruktur, mesin pencari akan lebih mudah mengerti konten yang ada di dalamnya dan akan meningkatkan keterlihatan website di mesin pencari. Schema.org merupakan data terstruktur utama saat sekarang ini. Untungnya, konten Schema.org telah didukung oleh kedua versi, baik itu versi HTTP maupun HTTPS, sehingga bisa digunakan pada code base.
Perbarui tiap URL absolute pada data terstruktur yang digunakan pada website dan seluruh referensi Schema.org ke versi HTTPS. Sebagai contoh:
{
"@context": "http://schema.org",
"@type": "WebSite",
"name": "Your WebSite Name",
"alternateName": "An alternative name for your WebSite",
"url": "http://www.your-site.com"
}
Menjadi
{
"@context": "https://schema.org",
"@type": "WebSite",
"name": "Your WebSite Name",
"alternateName": "An alternative name for your WebSite",
"url": "https://www.example.com"
}
Sangat memungkinkan untuk menggunakan “//” untuk URL di contoh ini, tetapi tidak bagi context reference. Sebagai contoh, bentuk dibawah ini juga bisa digunakan.
{
"@context": "https://schema.org",
"@type": "WebSite",
"name": "Your WebSite Name",
"alternateName": "An alternative name for your WebSite",
"url": "//www.example.com"
}
Tetapi ini tidak valid berdasarkan Google Structured Data Testing Tool.
{
"@context": "//schema.org",
"@type": "WebSite",
"name": "Your WebSite Name",
"alternateName": "An alternative name for your WebSite",
"url": "//www.example.com"
}
Periksa lagi JSON-LD, Microdata, RDFa atau bentuk data terstruktur lainnya pada code base, dan ketika ditemukan, rubah protokolnya pada seluruh URL menjadi HTTPS.
RSS/Atom feed
Ihwal lainnya yang sering terlewati adalah RSS dan/atau Atom feed dari website. Walaupun penggunaan RSS/Atom telah memudar seiring dengan telah dimatikannya Google Reader, tetapi masih banyak juga yang menggunakan feed alternatif lainnya dan program lain yang menggunakan sindikasi ini.
Periksalah jika situs mempunyai feed, dan ketika ditemukan, verifikasi pada versi HTTPS jika anotasi HREF (yaitu tautan ke artikel) ke konten dan ada tautan di dalam artikel telah di perbaiki ke HTTPS. Jika tidak, tergantung dari platform feed itu saja lagi. Sebaiknya diskusikan dengan tim teknis atau sewalah ahlinya untuk melakukan ini jika anda ragu melakukannya sendiri. Karena melakukan perpindahan RSS/Atom feed ini tidak hanya sekedar menukar ‘//” ini saja, tetapi ada perlakuan khusus.
Mengakselerasi Laman Mobile
Jika website itu AMP nya aktif, referensi tautan ke URL AMP di kode sumber harus di perbaiki ke versi absolut HTTPS. Sebagai contoh:
<link rel="amphtml" href="http://www.example.com/amp/">
Menjadi
<link rel="amphtml" href="https://www.example.com/amp/">
Tambahan lagi, beberapa tautan internal, tautan refensi, canonical, asset link, dan sebagainya yang terdapat pada source code laman AMP butuh diperbaiki agar relevan dengan versi HTTPS.
Kuki
Kuki juga harus menjadi perhatian. Dengan melakukan ini dapat mengekspos data di kuki, seperti data autentifikasi. Periksalah setingan server sehingga kuki anda telah aman. Sebagai contoh, dengan PHP check periksalah file php.ini sebagai mana seperti dibawah:
session.cookie_secure = True
Dengan ASP.NET menset baris berikut ini pada file web.config
<httpCookies requireSSL="true" />
Verifikasi setingan dengan mengakses sebuah halaman yang menset kuki baru dan periksa HTTP Header agar seperti dibawah ini:
Set-Cookie: mycookie=abc; path=/secure/; Expires=12/12/2018; secure; httpOnly;
Proses Pindah ke HTTPS
Setelah seluruh langkah di atas dilakukan, artinya konten telah dipersiapkan dan diupdate ke versi HTTPS, sekarang waktunya untuk memindahkannya.
Rayapi Versi HTTPS
Sebelum memindahkan situs dari HTTP ke HTTPS dan mempubliskannya di internet, ada beberapa hal yang perlu menjadi perhatian, diantaranya:
- Semua CSS, gambar, Javascript, Font, Flash, Video, Audio, Iframes telah bisa tampil secara aman, baik dalam versi HTTP maupun HTTPS.
- Periksa jika ada redirect ke versi HTTP.
- Tautan internal, canonical, Hreflang, dan atau data terstruktur, dan sebagainya, telah menunjuk ke versi HTTP.
- Periksa juga Error 40x atau 50x pada Server Log Files di versi HTTPS.
Setelah diperiksa dan ternyata tidak ada terdapat kesalahan, sekarang saatnya lanjut ke langkah berikutnya.
Catatan: Cegah bot untuk merayapi versi HTTP, dan biarkan dia merayapi versi HTTPS.
Tantangan terbesarnya ketika melakukan transisi dari HTTP ke HTTPS adalah isi konten terkadang tertukar. Pastikan ketika HTTPS sudah aktif, seluruh konten di tiap halaman sudah berada pada posisinya masing-masing, termasuk gambar, video, komentar, tombol media sosial, dan embed.
Mengupdate XML Sitemap Kembali
Mengekstrak seluruh URL dari perayapan versi HTTPS dan bandingkan daftar ini dengan URL yang terdapat pada XML sitemap. Temukan URL mana yang telah terindeks oleh Google pada versi HTTPS dan tidak memiliki entri pada XML Sitemap.
Redirect
Setelah seluruh konten telah dipindahkan dan diperbaiki, sekarang melakukan redirect agar seluruh trafik HTTP akan dapat relevan dengan versi HTTPS. Cara mudah menggunakan Apache adalah dengan menggunakan file .htaccess pada versi HTTP.
RewriteEngine On
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]
Perintah di atas akan meredirek seluruh bentuk atau pola di versi HTTP ke versi HTTPS. Dengan menerapkannya, akan membuat robots.txt dan XML Sitemap pada versi HTTP akan tidak dapat diakses dan seluruhnya akan di redirek ke versi HTTPS. Untuk mencegah hal ini terjadi, aturan pembebasan harus ditambahkan. Sebagai contoh, pada file .htaccess di Apache pada versi HTTP akan berbentuk:
RewriteEngine On
RewriteRule (robots.txt|sitemap.xml)$ - [L]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]
Perintah di atas akan meredirect semua permintaan pada versi HTTP ke versi HTTPS, kecuali pengecualian yang diminta oleh file robots.txt dan file sitemap.xml.
Pindah dengan Canonical
Ketika melakukan perindahan konten melalui canonical, tunggu penerapan aturan redirect hingga cukup terindeks dan tersedia seluruh konten penting di versi HTTPS. Sewaktu Googlebot telah melihat sebagian besar atau seluruh konten telah dalam bentuk HTTPS, perintah redirect bisa di aktifkan untuk memaksa Googlebot dan pengguna menuju ke versi HTTPS.
Mengurangi Rantai Redirect
Ketika menerapkan aturan redirect baru, periksa kembali aturan redirect lama dan perbaiki langsung pada tujuan akhir HTTPS. Hindari rantai redirect seperti: HTTP A meredirect ke HTTP B, yang pada gilirannya meredirect ke HTTPS C.
Perlu juga diingat beberapa sistem dapat menambahkan atau membuang garis miring dengan meredirectnya ke variasi lain pada protokol yang sama, menghasilkan tambahan redirect lagi. Sebagai contoh:
http://www.examples.com/dir meredirect ke http://www.examples.com/dir/, lantas meredirect lagi ke https://www.examples.com/dir, dimana https://www.examples.com/dir/ merupakan tujuan akhirnya.
Agar lebih efisien dan gampangnya meredirect URL dibawah ini:
http://www.examples.com/dir
http://www.examples.com/dir/
https://www.examples.com/dir
Langsung saja ke :
https://www.examples.com/dir/
Ketika membuat perintah redirect baru, periksa apakah ada gunanya membuat pilihan garis miring pada regular expression untuk aturan redirect. Sebagai contoh:
RewriteEngine On
RewriteRule ^(dir[\/]?)$ https://www.example.com/dir/ [R=301,L]
Jika dibutuhkan, silakan gunakan http://htaccess.mwl.be/ untuk memeriksa apakah aturan redirect sudah diterapkan secara benar atau belum.
Dengan atau tanpa WWW
Ketika membuat aturan redirect baru, pilihlah sebuah hostname utama dan aturan perintah redirect dari versi non-primary ke versi primary dari HTTPS. Sebagai contoh, ketika hostname WWW merupakan versi utama dari HTTPS, maka redirect juga seluruh domain URL ke primary WWW dalam versi HTTPS.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example.com [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]
Setelah semua aturan redirect pada versi HTTPS telah aktif, silakan lanjut ke langkah berikutnya.
Merayapi Versi HTTP Kembali
Kali ini, temukan URL dari Server Log Files, XML Sitemap dan perayapan pada versi HTTP. Nama filenya adalah logs_extracted_urls.csv, sitemap_extracted_url.csv, crawl_extracted_urls.csv (file yang telah disimpan di awal).
Gunakanlah fasilitas perayapan seperti Screaming Frog SEO Spider untuk merayapi semua URL dan pastikan seluruh redirect telah bekerja seperti diharapkan, dan semua URL pada versi HTTP telah diredirect ke versi HTTPS dengan benar.
Jika telah tidak ada kesalahan, silakan lanjut ke tahap berikut
Mengganti robots.txt
Pada tahap ini, robots.txt pada versi HTTPS perlu diganti. Kopi file robots.txt dari versi HTTP ke versi HTTPS dan perbaiki referensi sitemap ke file Sitemap yang baru. Contoh:
User-Agent: *
Disallow:
Sitemap: https://www.example.com/sitemap.xml
Mengkonfigurasi Google Search Console
Sekarang, seluruh konten telah pindah ke versi HTTPS, redirect dari versi HTTP ke versi HTTPS telah tidak ada masalah dan XML Sitemap dan robots.txt telah diupdate, sekarang saatnya kita memeriksa Google Search Console, dan memberitahu mesin pencari bahwa telah ada perubahan yang terjadi pada situs tersebut.
Menambahkan Variasi Situs
Sedikitnya ada empat variasi nama domain yang harus dihadirkan pada Google Search Console, yaitu:
http://example.com
http://www.example.com
https://example.com
https://www.example.com
Verifikasi dan tambahkan satu domain yang sudah tidak ada di Google Search Console.
Jika sebuah website memiliki beberapa subdomain atau subdirektori yang secara terpisah ditambahkan pada Google Search Console, lantas semuanya ini perlu juga ditambahkan ke Google Search Console baik itu dalam versi HTTP maupun versi HTTPS. Sebagai contoh:
http://m.example.com
https://m.example.com
Membuat Set
Sejak bulan May 2016, Google Search Console telah mendukung grouping data bagi satu atau beberapa properti sebagai satu kesatuan. Grouping data ini sangat berguna ketika sebuah website pindah ke versi HTTPS. Untuk itu, tambahkanlah sebuah set berisi seluruh properi HTTP dan HTTPS pada Google Search Console. Sebagai contoh, tambahkan properti berikut dalam satu kesatuan:
http://example.com/
https://example.com/
http://www.example.com/
https://www.example.com/
Ketika menggunakan subdomain dan/atau subdirektori untuk situs yang mempunyai target khusus berdasarkan geografis, tambahkan tambahan set untuk semua target geografis yang sesuai dengan versi HTTP dan versi HTTPS. Sebagai contoh tambahkan set berikut:
Set 1:
http://www.example.com/nl/
https://www.example.com/nl/
Set 2:
http://de.example.com/
https://de.example.com/
Periksa Fetch dan Render
Untuk memastikan semuanya telah bekerja dengan baik di Googlebot, pergunakan alat Fetch dan Render pada Google Search Console untuk fetch dan render.
- Masuk ke homepage versi HTTP dan verifikasi redirect sesuai dengan aturan. Jika semuanya telah benar, klik tombol “Submit to Index”.
- Setelah homepage versi HTTPS, verifikasi yang dirender dengan benar. Setelah semuanya benar, klik tombol “submit to index” dan pilih “Crawl this URL and its direct link”.
Sebagai tambahan, pengajuan untuk diindeks ini juga akan diketahui oleh Googlebot di versi HTTPS dan artinya anda meminta Googlebot untuk mulai merayapinya.
Memverifikasi Tindakan Manual
Periksalah apakah ada tindakan manual di Google Search Console agar perpindahan situs tidak bermasalah dikemudian hari pada versi HTTP.
Jika terdapat pemberitahuan tindakan manual, mintalah seorang profesional untuk menyelesaikan masalah ini agar bisa terlepas dari hukuman Google secepat mungkin. Namun jika tidak ada peringatan mengenai tindakan manual ini, silakan maju ke langkah berikut.
Setelan Domain Yang Disukai
Untuk memastikan bahwa setelan domain telah diatur sedemikian rupa, masuk ke properti utama versi HTTPS di Google Search Console dan klik gambar gerigi berada di sebelah kanan atas, dan klik Site Settings. Verifikasi bahwa domain telah diset dengan benar. Disarankan untuk mensetnya sebagai : Display URLs as example.com
Kapasitas Perayapan
Biasanya, para ahli SEO tidak mau merubah setingan ini pada Google SearchConsole. Biarkan Google mengoptimisasi sebagaimana dia mau sebagaimana direkomendasikan oleh Google. Untuk memeriksa kapasitas perayapan ini sama caranya dengan cara masuk ke setelan domain di atas.
Geotargetting
Jika anda menyasar salah satu negara sebagai pasar tujuan, maka website perlu di atur agar bisa tampil lebih baik rankingnya pada negara tersebut. Silakan atur situs versi HTTPS anda pada Google Search Console sama dengan pengaturan geotargetting versi HTTP.
Membuang URL
Untuk mencegah agar URL versi HTTP diindeks ulang dan ada pada hasil mesin pencari Google, silakan gunakan URL Removal tool pada Google Search Console.
Catatan: Efek dari URL removal tool bersifat sementara. Jika URL itu ingin dihapus permanen agar tidak diindeks oleh Google, buang URL tersebut di versi HTTPS dan tambahkan sebuah meta noindex pada URL tersebut agar tidak diindeks oleh Google.
Disavow File
Untuk menghindari masalah backlink (misalnya dihukum oleh Google Penguin atau tidak manual) terhadap versi HTTPS, silakan pergunakan https://www.google.com/webmasters/tools/disavow-links untuk menyangkal tautan ke situs anda.
Kesalahan Perayapan
Untuk menghindari masalah kesalahan perayapan karena server, silakan periksa di https://www.google.com/webmasters/tools/crawl-errors pada Google Search Console di properti versi HTTP. Periksalah apakah ada Soft 404 dilaporkan oleh Google. Jika ada, segeralah memperbaikinya karena Googlebot tidak menyukai kode kesalahan ini karena ada indikasi duplikasi antara versi HTTP dengan versi HTTPS.
Mensubmit XML Sitemaps
Di awal telah dijelaskan, bahwa XML Sitemap telah dibuat, diperbaiki dan ditempatkan pada root subdomain yang relevan dan/atau subdirektori dan/atau pada primary hostname, di versi HTTP maupun versi HTTPS. XML Sitemap ini hanya berisi URL yang dapat diindeks dan dirayapi saja, yang diekstrak dari XML sitemap versi HTTP, Server Log Files dan dari perayapan versi HTTP dan HTTPS. Misalnya:
http://www.example.com/sitemap.xml
http://de.example.com/sitemap.xml
http://www.example.com/nl/sitemap.xml
dan
https://www.example.com/sitemap.xml
https://de.example.com/sitemap.xml
https://www.example.com/nl/sitemap.xml
Ketika melakukan perpindahan ke HTTPS, biasanya akan terjadi kesalahan jika tidak dilakukan secara hati-hati. Biasanya akan terjadi juga fluktuasi ranking selama proses ini sedang berlangsung, tetapi dengan menggunakan langkah-langkah di atas dapat mengurangi dampak yang lebih buruk terhadap situs.
Memfinalisasi Perpindahan situs dari HTTP ke HTTPS
Pada tahap ini artinya anda telah menyelesaikan seluruh proses perpindahan situs dari HTTP ke HTTPS dan Googlebot telah mengetahui pula bahwa telah terjadi perpindahan ini. Tergantung dari ukuran website dan bujet perayapan, Googlebot membutuhkan waktu beberapa minggu hingga beberapa bulan untuk merayapi dan mengganti ke versi HTTPS.
Selanjutnya anda melangkah ke tahap akhir, yaitu memonitor bagaimana perkembangan perpindahan dari HTTP ke HTTPS di mesin pencari Google dan apakah masih ada masalah muncul. Berikut yang harus menjadi perhatian pada tahap finalisasi ini.
Memonitor Server Logs
Jika ada bagian yang tidak bekerja sebagaimana mestinya, segeralah perbaiki untuk memastikan tidak ada pemberitahuan kesalahan dari Google. Periksalah jikalau ada kesalahan 50x dan 404, baik di versi HTTP maupun versi HTTPS. Walau terkadang peringatan error 404 tidak sepenuhnya akurat, tetapi tidak ada salahnya jika memeriksa jika memang ada yang perlu diperbaiki.
84.25.65.243 - - [10/Oct/2016:13:55:36 -0700] "GET /favicon.icof HTTP/1.1" 200 326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"
2.5.45.7 - - [10/Oct/2016:13:55:45 -0700] "GET / HTTP/2" 200 2956 "-" "Mozilla/5.0 (iPad; U; CPU OS 3_2_1 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Mobile/7B405"
64.233.191.102 - - [10/Oct/2016:13:55:49 -0700] "GET /home HTTP/1.1" 200 43455 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Jika memungkinkan, pergunakan juga sistem untuk memeriksa halaman mana yang telah diindeks oleh Googlebot, seberapa cepat dan bagaimana status perayapan Googlebot. Data ini bisa diambil dari Server Log Files, bisa juga digunakan Elk Stack untuk server lokal atau log analyzer pihak ketiga, seperti Botify, Screaming Frog Log Analyser, atau Splunk.
Memonitor Google Search Console
Untuk memonitor jumlah halaman yang telah terindeks pada versi HTTPS, lihatlah seluruh XML Sitemap yang telah dimasukkan. Disamping itu juga periksa Crawl Stats overview pada kedua versi website untuk melihat kecepatan perayapan dan memastikan seluruh infrastruktur telah merespon Gooblebot dengan cepat. Jika dirasa masih kurang, silakan upgrade server ke yang lebih tinggi. Untuk itu silakan hubungi layanan penyedia hosting.
Periksa juga AMP, Rich Card dan data terstruktur pada versi HTTPS di Google Search Console untuk melihat apakah ada masalah pengindekan muncul, seperti error dan kecepatan menemukan data. Pokoknya, seluruh yang ada di Google Search Console harus anda periksa.
Perbaiki Link Incoming
Langkah berikutnya adalah memeriksa apakah tautan yang menuju ke versi HTTP telah diperbaiki ke versi HTTPS. Demikian juga jika ada tautan yang dibagikan melalui media sosial seperti Facebook, Twitter, dan media sosial lainnya. Semuanya harus diperbaiki agar menuju ke versi terbaru yaitu versi HTTPS.
Kesimpulan
Memindahkan sebuah situs dari HTTP ke HTTPS merupakan tantangan tersendiri, apalagi jika situs itu telah terlanjur besar. Untuk itu anda perlu perencanaan yang cukup matang jika tidak ingin situs anda terjun bebas di hasil pencarian Google. Namun demikian, walaupun anda memindahkannya tanpa perencanaan dan serampangan, nantinya situs anda akan naik secara perlahan di hasil pencarian Google, apalagi sekarang telah lebih dipercaya karena telah menggunakan sertifikat SSL. Bisa jadi setelah menggunakan sertifikat ini situs anda akan lebih baik rankingnya di Google. Yang penting sabar dan do’a.
Ada baiknya jika Anda sebagai pemilik situs harus AWARE terhadap situs Anda. Mungkin traffic situs Anda sedang turun saat ini ? bisa saja hal itu terjadi karena web Anda terblacklist oleh beberapa antivirus seperti McAfee dan TrendMicro.
