Mengapa Website Statis Lebih Baik untuk Visibilitas AI

Aku mau cerita sesuatu yang mungkin ga populer di kalangan web developer dan digital agency.

Website statis, yang HTML-nya bersih, ga pake JavaScript framework berat, ga bergantung pada page builder, secara sistematis lebih disukai oleh AI crawler dibanding WordPress dengan Elementor, Divi, atau page builder apapun yang sekarang dominan di pasar.

Ini bukan pendapat. Ini observasi dari seseorang yang sudah membangun website-nya sendiri dari nol, tanpa WordPress, tanpa framework JavaScript, tanpa SSG yang njelimet. Hanya PHP includes di shared hosting Rumahweb dengan LiteSpeed. Dan hasilnya? AI agents bisa membaca situs aku dengan sangat jelas.

Sebelum kamu bilang "ya iyalah, kamu developer." Bukan. Aku praktisi yang kebetulan paham arsitektur web karena menjalankan 3 perusahaan dan butuh infrastruktur digital yang bener. Beda.

Konteks: kenapa ini penting sekarang

AI search bukan masa depan. Ini sudah terjadi. ChatGPT, Perplexity, Gemini, Claude, semua sudah melakukan crawling dan menyintesis informasi dari web. Kalo kamu belum baca soal perbedaan fundamental antara SEO tradisional dan Generative Engine Optimization, aku sudah bahas detail di GEO vs. SEO.

Yang perlu kamu tau: AI agents ga bikin ranking. Mereka bikin jawaban. Dan untuk bisa menyebut nama kamu, atau bisnis kamu, atau rekomendasi kamu dalam jawaban itu, mereka harus bisa membaca website kamu dengan cepat, jelas, dan tanpa ambiguitas.

Nah, di sinilah arsitektur website jadi kritis. Bukan desainnya. Bukan template-nya. Arsitekturnya.

Apa yang AI crawler butuhkan dari website

AI crawler, baik itu GPTBot (OpenAI), Google-Extended, Anthropic-AI, atau PerplexityBot, pada dasarnya butuh tiga hal:

Ketiga hal ini kedengarannya sederhana. Dan memang sederhana. Tapi justru di situlah masalahnya. WordPress dengan page builder membuat ketiga hal ini jadi rumit secara tidak perlu.

Masalah fundamental WordPress + page builder

Aku ga anti WordPress. WordPress itu CMS yang powerful. Tapi ketika kamu pasang Elementor, Divi, WPBakery, atau page builder lainnya di atas WordPress, kamu menambahkan lapisan kompleksitas yang secara langsung mengurangi kemampuan AI untuk membaca situs kamu.

Kenapa? Ini alasannya:

1. DOM bloat

Page builder menghasilkan nested <div> yang berlapis-lapis. Satu section yang secara visual cuma teks dan gambar, di balik layar bisa jadi 15-20 level nesting. AI crawler harus menggali melalui semua lapisan ini untuk menemukan konten yang sebenarnya. Itu pemborosan.

Sebagai perbandingan, di hibranwar.com, setiap halaman essay punya struktur sederhana: <div class="prose"> yang langsung berisi <p>, <h2>, <h3>, <table>. Ga ada nesting yang ga perlu. AI crawler langsung sampai ke konten.

2. JavaScript dependency

Banyak page builder membutuhkan JavaScript untuk merender layout. Tanpa JS execution, halaman terlihat kosong atau broken. AI crawler, terutama yang berbasis LLM, sebagian besar tidak mengeksekusi JavaScript. Mereka membaca raw HTML.

Kalo HTML kamu bergantung pada JS untuk menampilkan konten, AI crawler melihat halaman kosong. Literally. Kosong.

3. CSS dan JS payload

WordPress site dengan Elementor rata-rata memuat 400-500KB JavaScript dan CSS yang ga diperlukan. Bukan karena halaman itu butuh semua itu. Tapi karena page builder memuat entire framework-nya di setiap halaman, whether you use it or not.

Di hibranwar.com? Total CSS: satu file, style.css. Total JS payload: practically zero kecuali ada Chart.js atau Mermaid diagram di halaman tertentu. Dan itupun di-load secara conditional.

4. Schema markup yang kotor

Ini yang jarang dibahas. WordPress SEO plugins (Yoast, RankMath, etc.) memang generate schema otomatis. Tapi schema yang dihasilkan sering kali generik, redundan, dan kadang konflik satu sama lain. Dua plugin bisa menghasilkan dua Person schema yang berbeda di halaman yang sama.

Aku sudah bahas secara mendalam kenapa schema markup itu bukan teknis, tapi strategis. Kalo schema kamu dihasilkan secara otomatis oleh plugin, kamu kehilangan kontrol atas narasi yang kamu sampaikan ke mesin.

5. Crawl budget

Setiap AI crawler punya batasan berapa banyak resource yang mereka habiskan untuk satu domain. Kalo satu halaman kamu membutuhkan 4 detik untuk load dan menghasilkan 2800 DOM nodes, crawler ga akan sabar menjelajahi seluruh situs kamu. Mereka ambil beberapa halaman, lalu pergi.

Kalo satu halaman kamu load dalam 0.8 detik dengan 320 DOM nodes? Crawler bisa menjelajahi puluhan halaman dalam waktu yang sama.

Perbandingan langsung: Static PHP vs WordPress Page Builder

Ini data dari pengujian langsung. Satu sisi: hibranwar.com (static PHP, shared hosting Rumahweb, LiteSpeed). Sisi lain: rata-rata WordPress site dengan Elementor di shared hosting yang setara.

Ya, WordPress menang di kemudahan editing dan plugin ecosystem. Itu ga bisa disangkal. Tapi kalo tujuan kamu adalah visibilitas AI, setiap metrik yang relevan untuk AI crawling menunjuk ke arah yang sama: static.

Visualisasi performa

Arsitektur hibranwar.com: studi kasus nyata

Aku ga cuma ngomong teori. Ini arsitektur yang aku pakai di hibranwar.com. Bukan karena aku suka bikin susah diri sendiri. Tapi karena setelah mencoba WordPress, SSG (Eleventy), dan beberapa opsi lain, aku sampai pada kesimpulan yang sama: untuk tujuan aku (AI visibility, entity infrastructure, credibility), yang paling efektif adalah yang paling sederhana.

Stack-nya:

• Server: Shared hosting Rumahweb, LiteSpeed
• Bahasa: PHP (includes pattern, bukan framework)
• CSS: Satu file style.css, design system lengkap
• JS: Nol by default. Chart.js dan Mermaid di-load conditional per halaman
• Schema: Manual JSON-LD per halaman, full kontrol
• Database: SQLite untuk index konten, pagination, search
• Content: Static PHP files dengan $post array metadata

Total biaya hosting per tahun? Sekitar 200-300 ribu rupiah. Ga perlu VPS. Ga perlu Docker. Ga perlu CI/CD pipeline. Upload file via cPanel, selesai.

Kenapa PHP includes, bukan SSG?

Aku pernah pakai Eleventy. Build system-nya oke. Tapi untuk situs yang intinya adalah konten dan entity infrastructure, SSG menambahkan layer yang ga perlu. Build step, dependency management, Node.js versioning. Semuanya adalah friction yang ga memberikan value tambah untuk AI crawlability.

PHP includes memberikan aku hal yang sama: header dan footer yang shared, template yang konsisten, tanpa build step. Edit file, upload, selesai. LiteSpeed serve PHP bahkan lebih cepat dari static HTML di beberapa kasus karena OPcache.

Kenapa bukan framework JS?

React, Next.js, Nuxt, Gatsby, semua menghasilkan output yang secara teknis bisa di-crawl. Tapi mereka menambahkan JavaScript overhead yang ga perlu kalo konten kamu pada dasarnya adalah teks, gambar, dan structured data.

Hydration cost di React-based sites bisa menambahkan 1-2 detik delay sebelum konten fully interactive. AI crawler ga peduli dengan interactivity. Mereka peduli dengan parseable content. Kenapa menambahkan overhead untuk sesuatu yang ga memberikan value ke target audience utama kamu (mesin)?

Bagaimana AI crawler membaca HTML

Ini yang jarang orang pahami. AI crawler ga "melihat" website kamu seperti kamu melihatnya di browser. Mereka membaca raw HTML. Dan ada perbedaan besar antara ini:

HTML dari static site:

<article class="prose">
  <h2>Judul Section</h2>
  <p>Konten langsung di sini.</p>
</article>

Dan ini:

HTML dari Elementor:

<div class="elementor-section elementor-section-boxed">
  <div class="elementor-container elementor-column-gap-default">
    <div class="elementor-column elementor-col-100">
      <div class="elementor-widget-wrap elementor-element-populated">
        <div class="elementor-element elementor-widget elementor-widget-heading">
          <div class="elementor-widget-container">
            <h2 class="elementor-heading-title">Judul Section</h2>
          </div>
        </div>
        <div class="elementor-element elementor-widget elementor-widget-text-editor">
          <div class="elementor-widget-container">
            <p>Konten yang terkubur di sini.</p>
          </div>
        </div>
      </div>
    </div>
  </div>
</div>

Konten yang sama. Tapi signal-to-noise ratio-nya beda jauh. AI crawler harus menggali 7 layer div untuk sampai ke satu paragraf. Kalikan itu dengan seluruh halaman. Kalikan lagi dengan seluruh situs. Itu beban parsing yang signifikan.

Semantic HTML, yang pakai <article>, <section>, <nav>, <header>, <main>, memberikan AI context langsung tentang apa fungsi setiap bagian. Page builder mengubur semua semantic meaning di balik class names yang hanya bermakna untuk visual rendering.

Schema: kontrol penuh vs autopilot

Di hibranwar.com, setiap halaman punya JSON-LD schema yang aku tulis sendiri. Person schema, Organization schema, Article schema, semuanya konsisten dan saling terhubung melalui sameAs references.

Di WordPress, kamu bergantung pada plugin. Yoast generate schema. RankMath generate schema. Kadang theme juga generate schema. Hasilnya? Tiga versi schema yang saling tumpang tindih di satu halaman. AI crawler melihat sinyal yang kontradiktif.

Seperti yang sudah aku tulis di essay tentang schema markup strategis, schema itu bukan checklist teknis. Itu narasi yang kamu sampaikan ke mesin. Kalo narasi kamu dihasilkan oleh plugin secara otomatis, kamu ga punya kontrol atas apa yang mesin "dengar" tentang kamu.

Argumen balik: "Tapi WordPress lebih mudah..."

Valid. 100%. Aku ga akan bilang semua orang harus bikin website dari PHP manual. Itu absurd.

Kalo kamu pemilik bisnis kecil yang butuh website buat menampilkan menu restoran, WordPress dengan theme yang ringan itu pilihan yang masuk akal. Kalo kamu blogger yang nulis seminggu sekali dan ga peduli AI visibility, WordPress itu fine.

Tapi kalo kamu:

• Mengincar visibilitas di AI search (ChatGPT, Perplexity, Gemini)
• Membangun entity infrastructure untuk personal branding atau bisnis
• Menarget enterprise clients yang melakukan due diligence secara digital
• Ingin bergerak dari "punya website" ke "jadi verified digital entity"

Maka arsitektur website kamu itu bukan detail teknis. Itu keputusan strategis. Dan clean static HTML memberikan keunggulan struktural yang WordPress + page builder secara desain tidak bisa berikan.

Jalan tengah: WordPress tanpa page builder

Kalo kamu sudah terlanjur di WordPress dan ga mau migrasi total, ada jalan tengah yang reasonable.

1. Buang page builder. Pakai block editor bawaan (Gutenberg) yang menghasilkan HTML jauh lebih bersih
2. Minimalkan plugin. Setiap plugin menambah JS/CSS payload. Target: di bawah 10 plugin aktif
3. Custom schema. Matikan auto-schema dari Yoast/RankMath. Tulis JSON-LD manual di <head>
4. Caching agresif. WP Super Cache atau LiteSpeed Cache. Serve static HTML dari cache
5. Audit DOM. Buka DevTools, hitung DOM nodes. Target: di bawah 1000

Ini ga seoptimal static site murni, tapi jauh lebih baik dari WordPress + Elementor default.

Yang sering diabaikan: robots.txt dan crawl signals

Satu hal lagi yang static site buat lebih mudah: kontrol atas crawl signals. Di hibranwar.com, robots.txt aku simple dan explicit. Ga ada rule yang saling konflik. Ga ada plugin yang menambahkan directive tanpa sepengetahuan aku.

Di WordPress, aku pernah lihat robots.txt yang dimodifikasi oleh 3 plugin berbeda, menghasilkan directive yang kontradiktif. Satu plugin block GPTBot, yang lain allow. Mana yang berlaku? Tergantung urutan. Itu bukan arsitektur. Itu lotere.

Perspektif biaya

Mari kita bicara uang, karena pada akhirnya ini soal investasi.

• Shared hosting Rumahweb: ~Rp 200-300rb/tahun
• WordPress managed hosting (yang performanya decent): ~Rp 1-3jt/tahun
• Elementor Pro license: ~$60/tahun (~Rp 950rb)
• Premium theme: ~$50-100 (~Rp 800rb-1.6jt)
• SEO plugin premium: ~$100/tahun (~Rp 1.6jt)

Total WordPress + page builder: Rp 4-7 juta per tahun untuk stack yang secara objektif lebih lambat, lebih berat, dan lebih sulit di-crawl oleh AI.

Total static PHP: Rp 300 ribu per tahun untuk stack yang lebih cepat, lebih ringan, dan lebih friendly untuk AI crawler.

Tradeoff-nya jelas: kamu membayar premium untuk kemudahan editing, bukan untuk performa atau visibilitas.

Kesimpulan: arsitektur adalah keputusan visibilitas

Pilihan antara static dan WordPress bukan soal teknologi. Ini soal siapa audiens utama kamu.

Kalo audiens utama kamu adalah manusia yang mengunjungi website via Google Search tradisional, WordPress dengan desain yang bagus itu cukup. Mungkin lebih dari cukup.

Tapi kalo audiens utama kamu termasuk AI agents yang menentukan apakah nama kamu muncul di jawaban ChatGPT, apakah Perplexity menyebut bisnis kamu sebagai referensi, apakah Google membangun Knowledge Panel untuk kamu, maka arsitektur website kamu harus dioptimalkan untuk pembaca yang paling kritis: mesin.

Dan mesin menyukai HTML yang bersih, schema yang jelas, dan response time yang cepat. Persis apa yang website statis berikan secara default.

Aku bukan developer. Aku praktisi yang butuh infrastruktur digital yang bekerja untuk tujuan yang sangat spesifik: membangun verified digital entity di era AI. Kalo kamu punya tujuan yang sama, pertimbangkan arsitektur sebelum kamu pertimbangkan desain. Silakan tanya.