Cara Melakukan Pemeriksaan Kesehatan WordPress untuk Pemecahan Masalah (Panduan 2025)

Pemeriksaan kesehatan WordPress adalah proses diagnostik sistematis yang mengevaluasi versi PHP situs Anda, integritas database, plugin aktif, kompatibilitas tema, lingkungan server, dan postur keamanan — semuanya dari dalam dasbor admin WordPress atau melalui alat khusus. Menjalankan pemeriksaan ini secara rutin mencegah kegagalan berantai, mengidentifikasi hambatan kinerja sebelum memengaruhi peringkat, dan mengungkap kerentanan keamanan sebelum menjadi pelanggaran.

Alat Site Health bawaan (diperkenalkan di WordPress 5.2) menyediakan laporan status otomatis dan panel informasi debug mentah yang digunakan oleh pengembang berpengalaman sebagai langkah pertama dalam alur kerja pemecahan masalah apa pun. Dikombinasikan dengan plugin Health Check & Troubleshooting, Anda dapat mereplikasi masalah produksi dalam sesi terisolasi tanpa menyentuh situs langsung — kemampuan yang menghilangkan risiko terbesar dalam debugging WordPress: merusak sesuatu bagi pengunjung nyata saat Anda menyelidiki.

Mengapa Pemeriksaan Kesehatan WordPress Lebih Penting dari yang Diakui Kebanyakan Panduan

Sebagian besar tutorial memperlakukan Site Health sebagai daftar periksa yang hanya perlu ditandai sekali. Dalam praktiknya, ini adalah sinyal operasional yang berkelanjutan. Core Web Vitals Google secara langsung memberikan penalti pada situs yang lambat atau tidak stabil. Satu plugin yang sudah usang dengan CVE yang diketahui dapat mengakibatkan kompromi situs penuh dalam beberapa jam setelah pengungkapan publik. Ketidakcocokan versi PHP antara server Anda dan persyaratan minimum plugin secara diam-diam menurunkan kinerja jauh sebelum menimbulkan kesalahan fatal.

Berjalan di lingkungan VPS Hosting yang dikonfigurasi dengan baik memberi Anda kendali langsung atas versi PHP, caching tingkat server, dan penguatan keamanan — kendali yang tidak dapat disediakan oleh lingkungan bersama. Alur kerja pemeriksaan kesehatan yang dijelaskan di bawah ini mengasumsikan Anda memiliki akses SSH atau panel kontrol yang mampu memodifikasi pengaturan tingkat server, yang merupakan dasar yang tepat untuk setiap penerapan WordPress produksi.

Langkah 1: Akses Alat Site Health WordPress Bawaan

Navigasikan ke Tools > Site Health di dalam dasbor admin WordPress Anda. WordPress akan segera mulai menjalankan pemeriksaan otomatis dan mengisi tab Status dengan hasil yang dikategorikan berdasarkan tingkat keparahan.

Tidak diperlukan plugin untuk langkah ini. Site Health adalah fungsionalitas inti, dan hasilnya dihasilkan di sisi server, artinya mencerminkan lingkungan runtime aktual — bukan yang disimulasikan.

Apa yang sebenarnya diperiksa oleh Site Health di balik layar:

• Versi PHP, batas memori, dan waktu eksekusi maksimum
• Versi WordPress aktif versus rilis stabil terbaru
• Apakah REST API dapat diakses dan mengembalikan respons yang valid
• Status eksekusi cron job terjadwal (wp-cron)
• Penegakan HTTPS dan validitas sertifikat SSL
• Keberadaan file debug.log di lokasi yang dapat diakses publik
• Kemampuan permintaan loopback (diperlukan untuk pembaruan latar belakang dan instalasi plugin)
• Versi server database dan apakah memenuhi persyaratan minimum WordPress
• Izin file dan direktori untuk jalur sensitif

Langkah 2: Interpretasikan Laporan Status Site Health dengan Benar

Halaman status mengkategorikan temuan ke dalam tiga tingkatan. Memahami apa yang sebenarnya dimaksud oleh setiap tingkatan — dan apa yang tidak dimaksudkan — mencegah baik rasa puas diri maupun kepanikan yang tidak perlu.

Masalah kritis yang memerlukan perhatian segera:

• Versi PHP yang sudah usang — PHP 7.4 mencapai akhir masa pakainya pada November 2022. Menjalankannya berarti tidak ada patch keamanan. WordPress 6.x secara resmi merekomendasikan PHP 8.1 atau 8.2.
• Plugin tidak aktif yang masih terinstal — Plugin tidak aktif masih dapat dibaca oleh sistem file dan dapat mengandung kode yang dapat dieksploitasi. Hapus, jangan sekadar menonaktifkan.
• REST API diblokir — Banyak plugin modern, editor blok (Gutenberg), dan WooCommerce bergantung pada ketersediaan REST API. REST API yang diblokir menghasilkan kegagalan diam yang terkenal sulit dilacak.
• Kegagalan permintaan loopback — Jika WordPress tidak dapat membuat permintaan HTTP loopback ke dirinya sendiri, pembaruan latar belakang otomatis dan tugas terjadwal akan gagal secara diam-diam.
• WP_DEBUG diaktifkan di situs langsung — Mode debug menulis data konfigurasi sensitif dan jejak tumpukan ke debug.log. Jika file tersebut berada di wp-content/ tanpa pembatasan akses tingkat server, file tersebut dapat dibaca secara publik.

Kasus tepi yang sering terlewatkan: Site Health melaporkan status “Good” untuk caching objek jika *ada* cache objek yang terdeteksi — termasuk yang berbasis file. Caching objek berbasis file pada situs dengan lalu lintas tinggi sebenarnya dapat meningkatkan beban I/O daripada menguranginya. Solusi yang tepat adalah backend Redis atau Memcached, yang memerlukan konfigurasi tingkat server di luar kemampuan Site Health untuk menyediakannya.

Langkah 3: Ekstrak dan Gunakan Panel Informasi Debug

Klik tab Info di halaman Site Health. Panel ini bisa dibilang lebih berharga untuk pemecahan masalah daripada tab Status karena mengekspos data lingkungan mentah.

Bagian utama dan apa yang perlu dicari:

• WordPress — Mengonfirmasi tema aktif, apakah multisite diaktifkan, dan apakah WP_DEBUG aktif.
• Directories and Sizes — Mengungkapkan apakah wp-content/uploads/ telah tumbuh ke ukuran yang membebani I/O disk atau proses pencadangan.
• Active Plugins — Mencantumkan setiap plugin aktif dengan versinya. Periksa silang dengan WordPress Vulnerability Database (wpscan.com) untuk CVE yang diketahui.
• Server — Menampilkan versi PHP, batas memori PHP, ukuran unggahan maksimum, waktu eksekusi maksimum, dan apakah mod_rewrite atau penulisan ulang URL yang setara aktif.
• Database — Mengonfirmasi versi MySQL atau MariaDB dan set karakter database. utf8mb4 diperlukan untuk dukungan emoji dan multibahasa penuh; utf8 (3-byte) akan memotong karakter tertentu secara diam-diam.
• Must Use Plugins — Sering diabaikan. Plugin MU dimuat sebelum semua plugin lain dan tidak dapat dinonaktifkan dari UI admin. Jika penyedia hosting telah menyuntikkan plugin MU (umum dengan hosting terkelola), plugin tersebut muncul di sini.

Penggunaan praktis tombol “Copy site info to clipboard”:

Saat membuka tiket dukungan atau memposting ke forum pengembang, tempelkan output ini secara langsung. Ini menghilangkan bolak-balik pertanyaan lingkungan dasar dan memungkinkan insinyur berpengalaman untuk segera menemukan anomali konfigurasi — misalnya, memory_limit sebesar 40M saat WooCommerce memerlukan minimum 128M, atau max_execution_time sebesar 30 detik saat proses impor besar memerlukan 300.

Langkah 4: Gunakan Plugin Health Check & Troubleshooting untuk Debugging Mode Aman

Plugin Health Check & Troubleshooting (tersedia gratis dari repositori plugin WordPress) mengaktifkan mode aman yang terisolasi sesi. Ini adalah metode yang tepat untuk mendiagnosis konflik plugin dan tema di situs produksi langsung.

Cara kerja isolasi sesi secara teknis:

Plugin menetapkan cookie browser yang dibaca WordPress pada setiap permintaan. Ketika cookie ada, WordPress hanya memuat tema default dan menonaktifkan semua plugin non-esensial — tetapi *hanya untuk sesi browser yang membawa cookie tersebut*. Semua pengunjung lain mengalami situs persis seperti sebelumnya. Ini bukan lingkungan staging; ini adalah filter runtime yang diterapkan pada tingkat bootstrap WordPress.

Instalasi dan aktivasi:

# If you have WP-CLI available on your server (recommended)
wp plugin install health-check --activate

Atau navigasikan ke Plugins > Add New, cari “Health Check & Troubleshooting”, dan klik Install Now, lalu Activate.

Menjalankan sesi pemecahan masalah:

1. Pergi ke Tools > Site Health dan klik tab Troubleshooting.
2. Klik Enable Troubleshooting Mode. Sesi Anda sekarang berjalan dengan semua plugin dinonaktifkan dan tema default aktif (Twenty Twenty-Four mulai WordPress 6.5+).
3. Reproduksi masalah. Jika sudah hilang, plugin atau tema yang bertanggung jawab.
4. Aktifkan kembali plugin satu per satu menggunakan daftar plugin tab Troubleshooting. Setelah mengaktifkan setiap plugin, muat ulang halaman yang terpengaruh dan uji.
5. Setelah masalah muncul kembali, plugin terakhir yang Anda aktifkan adalah sumber konflik.
6. Klik Disable Troubleshooting Mode untuk memulihkan lingkungan produksi penuh.

Kasus tepi dan jebakan:

• Jika masalah tetap ada bahkan dalam mode aman (tidak ada plugin, tema default), masalahnya ada di tingkat server atau inti WordPress — bukan konflik plugin. Periksa php_error.log dan log debug WordPress berikutnya.
• Plugin MU tidak dinonaktifkan oleh mode aman. Jika Anda mencurigai plugin MU, Anda harus mengganti namanya secara manual di wp-content/mu-plugins/ melalui SFTP atau SSH.
• Cookie pemecahan masalah bersifat spesifik untuk browser. Jika Anda menguji di perangkat seluler, Anda perlu mengaktifkan mode pemecahan masalah di sesi browser tersebut secara terpisah.

Langkah 5: Diagnosis dan Selesaikan Konflik Plugin dan Tema

Konflik plugin terbagi dalam dua kategori yang memerlukan strategi resolusi berbeda:

Tipe 1: Konflik PHP langsung — Dua plugin mencoba mendefinisikan fungsi atau kelas yang sama. Ini menghasilkan kesalahan fatal secara langsung. Log kesalahan akan berisi Cannot redeclare function atau Cannot redeclare class.

Tipe 2: Konflik perilaku diam — Dua plugin sama-sama mengaitkan ke aksi atau filter WordPress yang sama dan menghasilkan output yang tidak terduga atau kerusakan data tanpa menimbulkan kesalahan. Ini jauh lebih sulit untuk didiagnosis dan memerlukan isolasi satu per satu yang metodis.

Alur kerja resolusi:

# Check the WordPress debug log for fatal errors
tail -n 100 /path/to/wp-content/debug.log

# Enable WP_DEBUG temporarily via wp-config.php if debug.log is empty
# Add these lines to wp-config.php before the "stop editing" comment:
# define('WP_DEBUG', true);
# define('WP_DEBUG_LOG', true);
# define('WP_DEBUG_DISPLAY', false);

Ketika sebuah plugin adalah sumber konflik yang dikonfirmasi:

1. Periksa changelog plugin untuk pembaruan terbaru yang mengatasi konflik.
2. Cari di forum dukungan plugin di wordpress.org untuk laporan konflik yang sama.
3. Jika tidak ada perbaikan yang tersedia, identifikasi plugin alternatif dengan fungsionalitas yang setara.
4. Jika plugin sangat penting untuk bisnis, hubungi penulis plugin dengan kesalahan spesifik dari log debug Anda — sertakan versi PHP, versi WordPress, dan nama serta versi plugin yang berkonflik.

Langkah 6: Perbarui Versi PHP dan Server Database

Ini adalah tindakan pemeliharaan dengan dampak tertinggi untuk kinerja dan keamanan. PHP 8.1 dan 8.2 memberikan peningkatan throughput yang terukur dibandingkan PHP 7.4 — tolok ukur secara konsisten menunjukkan eksekusi 20–30% lebih cepat untuk beban kerja WordPress tipikal karena kompilasi JIT dan perilaku OPcache yang ditingkatkan.

Matriks kompatibilitas versi PHP untuk WordPress:

Memperbarui PHP melalui cPanel (untuk lingkungan VPS dengan cPanel):

1. Masuk ke WHM (akses root) atau cPanel (tingkat pengguna, jika MultiPHP Manager diaktifkan).
2. Navigasikan ke MultiPHP Manager di bawah bagian Software.
3. Pilih domain Anda dan pilih versi PHP target dari dropdown.
4. Klik Apply.

Memperbarui PHP melalui baris perintah (Ubuntu/Debian):

# Add the Ondrej PHP PPA (Ubuntu)
sudo add-apt-repository ppa:ondrej/php
sudo apt update

# Install PHP 8.2 with common WordPress extensions
sudo apt install php8.2 php8.2-mysql php8.2-curl php8.2-gd php8.2-mbstring 
  php8.2-xml php8.2-zip php8.2-intl php8.2-bcmath php8.2-imagick

# Switch the CLI default (if using WP-CLI)
sudo update-alternatives --set php /usr/bin/php8.2

Langkah pra-peningkatan yang kritis: Sebelum mengubah versi PHP di produksi, uji tema dan setiap plugin aktif Anda terhadap versi baru. Gunakan WP-CLI di lingkungan staging:

wp core check-update
wp plugin list --update=available --format=table
wp theme list --update=available --format=table

Pertimbangan versi database:

WordPress memerlukan MySQL 5.7+ atau MariaDB 10.3+. MariaDB 10.6 dan 10.11 (LTS) adalah versi yang direkomendasikan saat ini. Menjalankan versi server database yang lebih lama memperkenalkan paparan keamanan dan peningkatan pengoptimal kueri yang hilang yang memengaruhi situs dengan tabel posting besar atau volume pesanan WooCommerce.

-- Check current database version from within WordPress or phpMyAdmin
SELECT VERSION();

-- Check table storage engines (InnoDB is required for full-text search and transactions)
SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_wordpress_database';

Jika ada tabel yang menampilkan MyISAM sebagai mesin, konversikan ke InnoDB untuk pemulihan crash yang lebih baik dan kinerja penulisan bersamaan:

ALTER TABLE wp_options ENGINE=InnoDB;

Langkah 7: Ukur dan Optimalkan Kinerja Situs

Site Health tidak mengukur kinerja front-end — itu memerlukan alat eksternal. Gunakan Google PageSpeed Insights (mengukur Core Web Vitals dalam kondisi dunia nyata), GTmetrix (analisis waterfall), dan WebPageTest (multi-lokasi, konfigurasi lanjutan) sebagai alat pelengkap.

Optimasi kinerja berdasarkan lapisan:

Lapisan server:

• Aktifkan OPcache untuk caching bytecode PHP. Pada VPS yang dikonfigurasi dengan benar, ini saja mengurangi waktu eksekusi PHP sebesar 40–60%.

; Add to php.ini or a custom .ini file
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.jit_buffer_size=100M
opcache.jit=1255

• Gunakan Redis untuk caching objek persisten. Instal paket redis-server dan plugin WordPress Redis Object Cache, lalu tambahkan ke wp-config.php:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE', true);

Lapisan aplikasi:

• Optimasi gambar — Gunakan format WebP dengan fallback JPEG/PNG. Plugin Imagify atau ShortPixel menangani konversi massal dan pengiriman WebP otomatis melalui aturan penulisan ulang .htaccess.
• Lazy loading — WordPress 5.5+ menambahkan loading="lazy" ke gambar secara otomatis, tetapi verifikasi bahwa itu tidak ditimpa oleh tema Anda.
• Optimasi database — Jalankan OPTIMIZE TABLE pada tabel dengan perputaran tinggi (wp_options, wp_postmeta) setiap bulan. Plugin WP-Optimize mengotomatiskan ini.

# Optimize all WordPress tables via WP-CLI
wp db optimize

• Plugin caching — W3 Total Cache dengan backend Redis atau WP Rocket (premium) adalah dua opsi paling mumpuni. Hindari menjalankan dua plugin caching secara bersamaan — keduanya akan berkonflik.

Integrasi CDN:

CDN memindahkan pengiriman aset statis dan mengurangi TTFB untuk pengunjung yang tersebar secara geografis. Tingkat gratis Cloudflare menyediakan fungsionalitas CDN yang memadai untuk sebagian besar situs. Untuk situs yang banyak menggunakan media, BunnyCDN menawarkan kinerja lebih baik per dolar. Konfigurasikan CDN Anda untuk meng-cache aset statis secara agresif tetapi kecualikan admin WordPress (/wp-admin/) dan endpoint dinamis apa pun.

Langkah 8: Perkuat Keamanan dan Tetapkan Rutinitas Pemantauan Kerentanan

Keamanan bukan konfigurasi satu kali — ini adalah praktik operasional yang berkelanjutan. Alat Site Health mengungkap beberapa masalah keamanan, tetapi tidak melakukan pemindaian kerentanan.

Pendekatan keamanan berlapis:

Di tingkat server (memerlukan akses VPS atau server khusus):

# Disable XML-RPC if not required (common attack vector for brute force amplification)
# Add to .htaccess
# <Files xmlrpc.php>
#   Order Deny,Allow
#   Deny from all
# </Files>

# Restrict wp-config.php access
chmod 600 /path/to/wp-config.php

# Verify file permissions across the WordPress installation
find /path/to/wordpress/ -type f -name "*.php" -perm /022
# Any PHP file writable by group or world is a security risk

Di tingkat aplikasi:

• Wordfence Security — Menyediakan Web Application Firewall (WAF), pemindai malware, dan umpan intelijen ancaman real-time. Tingkat gratis sudah cukup untuk sebagian besar situs; tingkat premium menambahkan pembaruan aturan firewall real-time.
• Batasi upaya login — Plugin Limit Login Attempts Reloaded atau perlindungan brute force bawaan Wordfence. Atur penguncian setelah 3–5 upaya gagal.
• Autentikasi dua faktor — Terapkan 2FA untuk semua akun administrator menggunakan plugin WP 2FA atau Google Authenticator.
• Penegakan SSL/HTTPS — Setiap situs WordPress harus berjalan melalui HTTPS. Dapatkan dan instal sertifikat SSL; jika Anda membutuhkannya, SSL Certificates dari penyedia hosting Anda adalah jalur yang paling mudah. Tambahkan berikut ini ke wp-config.php untuk memaksa HTTPS di tingkat aplikasi:

define('FORCE_SSL_ADMIN', true);

Dan di .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Pemantauan kerentanan otomatis:

Berlangganan peringatan email WPScan Vulnerability Database untuk plugin yang Anda gunakan. Alat WPScan CLI dapat diintegrasikan ke dalam cron job untuk memberi tahu Anda ketika CVE baru diterbitkan untuk plugin yang terinstal:

# Install WPScan (requires Ruby)
gem install wpscan

# Run a vulnerability scan against your site
wpscan --url https://yourdomain.com --api-token YOUR_API_TOKEN 
  --enumerate vp,vt,u --plugins-detection aggressive

Pencadangan database sebagai kontrol keamanan:

Cadangan yang bersih dan terbaru adalah mekanisme pemulihan paling andal setelah kompromi. Otomatiskan pencadangan harian ke lokasi di luar server (penyimpanan objek yang kompatibel dengan S3, SFTP jarak jauh). Plugin UpdraftPlus menangani ini dengan andal. Verifikasi prosedur pemulihan setiap kuartal — cadangan yang belum pernah Anda uji bukanlah cadangan.

Pemeriksaan Kesehatan WordPress: Matriks Keputusan dan Poin Utama

Gunakan matriks ini untuk menentukan tindakan yang tepat berdasarkan apa yang dilaporkan Site Health:

Daftar periksa operasional untuk kesehatan WordPress yang berkelanjutan:

• Jalankan tinjauan status Site Health setiap bulan; perlakukan temuan Kritis sebagai insiden.
• Pertahankan PHP pada versi yang didukung (minimum 8.1; 8.2 atau 8.3 lebih disukai).
• Hapus plugin dan tema yang tidak aktif — jangan sekadar menonaktifkannya.
• Aktifkan caching objek Redis pada situs mana pun dengan lebih dari 500 pengunjung harian.
• Otomatiskan pencadangan database harian di luar server dengan pengujian pemulihan yang diverifikasi.
• Berlangganan peringatan kerentanan untuk setiap plugin dan tema dalam tumpukan Anda.
• Terapkan HTTPS di seluruh situs dan atur FORCE_SSL_ADMIN di wp-config.php.
• Gunakan WP-CLI untuk pembaruan massal dan operasi database — lebih cepat dan dapat di-skrip.
• Pada Dedicated Server atau VPS, konfigurasikan cron job sisi server alih-alih mengandalkan wp-cron — wp-cron hanya aktif ketika pengunjung mengakses situs, membuatnya tidak andal pada situs dengan lalu lintas rendah.

# Replace wp-cron with a real cron job (add to crontab)
# First, disable wp-cron in wp-config.php:
# define('DISABLE_WP_CRON', true);

# Then add to crontab (crontab -e):
*/15 * * * * php /path/to/wordpress/wp-cron.php > /dev/null 2>&1
# Or with WP-CLI (preferred):
*/15 * * * * wp --path=/path/to/wordpress cron event run --due-now > /dev/null 2>&1

Jika Anda mengevaluasi lingkungan hosting untuk penerapan WordPress, VPS Control Panels menyediakan akses tingkat server yang diperlukan untuk mengimplementasikan setiap optimasi dan langkah penguatan yang dijelaskan dalam panduan ini — manajemen versi PHP, konfigurasi Redis, cron sisi server, dan aturan firewall semuanya memerlukan akses root atau sudo yang tidak dapat disediakan oleh lingkungan bersama.

FAQ

Apa perbedaan antara tab Status Site Health dan tab Info?

Tab Status menjalankan pemeriksaan otomatis dan mengkategorikan temuan berdasarkan tingkat keparahan (Good, Recommended, Critical). Tab Info menampilkan data lingkungan mentah — konfigurasi PHP, plugin aktif dengan versi, detail database, dan ukuran direktori — tanpa penilaian lulus/gagal. Tab Info terutama digunakan untuk diagnosis manual dan berbagi dengan insinyur dukungan.

Apakah mengaktifkan Troubleshooting Mode memengaruhi pengunjung langsung?

Tidak. Troubleshooting Mode menggunakan cookie browser untuk menerapkan lingkungan mode aman secara eksklusif ke sesi Anda. Pengunjung tanpa cookie mengalami situs secara normal. Satu-satunya pengecualian adalah jika kesalahan fatal dalam plugin merusak proses server itu sendiri — dalam hal itu, semua pengunjung terpengaruh terlepas dari status aktivasi plugin dalam sesi Anda.

Versi PHP mana yang harus saya gunakan untuk WordPress di tahun 2025?

PHP 8.2 adalah versi yang direkomendasikan untuk situs WordPress produksi di tahun 2025. Versi ini dipelihara secara aktif dengan patch keamanan, menawarkan peningkatan kinerja yang terukur dibandingkan 8.0 dan 8.1, dan didukung oleh semua plugin WordPress utama. PHP 8.3 stabil dan cocok untuk penerapan baru, tetapi verifikasi kompatibilitas plugin sebelum meningkatkan situs yang sudah ada.

Mengapa Site Health melaporkan “Good” padahal situs saya jelas-jelas lambat?

Site Health memeriksa konfigurasi dan postur keamanan — tidak mengukur metrik kinerja front-end seperti Largest Contentful Paint (LCP) atau Time to First Byte (TTFB). Sebuah situs dapat lulus semua pemeriksaan Site Health dan tetap mendapat skor buruk pada Core Web Vitals karena gambar yang tidak dioptimalkan, tidak ada lapisan caching, database yang lambat, atau server yang jauh secara geografis. Gunakan Google PageSpeed Insights atau WebPageTest untuk pengukuran kinerja.

Bagaimana cara memperbaiki kegagalan permintaan loopback di WordPress Site Health?

Kegagalan loopback berarti WordPress tidak dapat membuat permintaan HTTP ke URL-nya sendiri dari server. Penyebab umum meliputi: firewall yang memblokir koneksi keluar dari proses server web, entri file hosts yang salah mengarahkan domain, kesalahan sertifikat SSL pada permintaan loopback, atau plugin keamanan yang memblokir permintaan. Mulailah dengan menonaktifkan sementara plugin keamanan Anda dan menjalankan kembali Site Health. Jika itu menyelesaikannya, masukkan IP server sendiri ke dalam daftar putih di pengaturan firewall plugin keamanan.