WordPress 500 Error

ওয়ার্ডপ্রেস ওয়েবসাইটে ৫০০ এরর কেন হয়? কারণ ও সমাধান

দ্বারা

হঠাৎ website খুলে “500 Internal Server Error”, সাদা page বা অস্পষ্ট “critical error” দেখা গেলে মনে হতে পারে সব data নষ্ট হয়ে গেছে। আসলে WordPress 500 Error একটি সাধারণ server-side response: request সামলাতে গিয়ে server এমন সমস্যায় পড়েছে যার নির্দিষ্ট ব্যাখ্যা browser-কে দেয়নি। কারণ হতে পারে faulty plugin, theme code, corrupted rewrite rule, PHP memory exhaustion, incompatible version, wrong permission কিংবা hosting configuration। একই message-এর আড়ালে ভিন্ন কারণ থাকায় অনুমান করে অনেক setting বদলানো ঠিক নয়।

এই গাইড একটি নিরাপদ troubleshooting order দেয়—কখন backup নিতে হবে, status ও scope কীভাবে বুঝবেন, error log কোথায় দেখবেন, plugin/theme isolate করবেন, .htaccess পরীক্ষা করবেন এবং কখন host support দরকার। প্রতিটি ধাপের পরে site test ও change note করলে root cause দ্রুত ধরা যায়। কোনো fix করার আগে current files ও database-এর copy রাখুন; live store বা membership site হলে maintenance ও transaction impact বিবেচনা করুন।

এখানে 500, 502, 503 ও 504-কে একই সমস্যা ধরা হয়নি। এগুলো দেখতে কাছাকাছি হলেও layer ভিন্ন হতে পারে। এই article মূলত WordPress-এ 500 response বা fatal error নিয়ে। Server command, file edit বা database change সম্পর্কে স্বচ্ছন্দ না হলে control panel-এর backup ও log সংগ্রহ করে hosting support বা অভিজ্ঞ developer-কে দিন। Password, secret key বা customer data public forum-এ প্রকাশ করবেন না।

দ্রুত উত্তর: WordPress 500 Error ঠিক করার সেরা উপায় হলো আগে verified backup, তারপর error-এর সময় ও scope নথিভুক্ত করে server/PHP log দেখা। সাম্প্রতিক change rollback, সব plugin সাময়িক deactivate, default theme test, .htaccess regenerate, PHP compatibility ও memory পরীক্ষা—এই ক্রমে এগোন। একবারে একটি পরিবর্তন করুন এবং root cause না বুঝে memory, permission বা core file নির্বিচারে বদলাবেন না।

Table of Contents

এই গাইডে যা জানবেন

WordPress 500 Error কী এবং প্রথমে কী বুঝবেন?

HTTP 500 বোঝায় server request পূরণ করতে পারেনি, কিন্তু response-এ নির্দিষ্ট কারণ জানায়নি। Browser cache clear বা device বদলালেও server-side failure ঠিক হয় না, যদিও cached error page বিভ্রান্ত করতে পারে। প্রথমে URL, সঠিক সময়, action এবং screenshot লিখুন। Homepage, একটি post, wp-admin, login, REST endpoint বা শুধু checkout—কোথায় error হচ্ছে দেখলে scope সংকুচিত হয়।

একই সময়ে সবাই error দেখছে কি না অন্য network বা uptime check দিয়ে যাচাই করুন। শুধু নিজের login অবস্থায় হলে user-specific plugin, cookie বা dashboard action জড়িত হতে পারে। কেবল একটি page-এ হলে template, shortcode বা সেই content-এর query; পুরো site-এ হলে bootstrap, plugin, theme, PHP অথবা server configuration সম্ভাব্য। Save/Upload করার সময় হলে request size, timeout বা security rule দেখুন।

500-এর পাশাপাশি exact timestamp ও request path সবচেয়ে মূল্যবান evidence। “গতকাল থেকে site down” বললে হাজার log line খুঁজতে হয়; “রাত ৮:১৭-এ plugin update চাপার পরে /checkout-এ 500” বললে diagnosis দ্রুত হয়। Error-এর আগে কে কী change করেছেন team-এর কাছে জিজ্ঞাসা করুন। Hosting maintenance, PHP version change বা resource limit alert আছে কি না status page ও control panel-এ দেখুন।

Troubleshooting-এর আগে backup ও নিরাপদ কাজের পরিবেশ

Error হলেও বর্তমান site-এর files ও database copy নিন। এটি clean restore point নাও হতে পারে, কিন্তু log, upload বা সাম্প্রতিক order সংরক্ষণ করবে। Host-এর last known good backup-এর timestamp ও retention জেনে নিন। Restore করার আগে current transaction ও নতুন content হারাবে কি না হিসাব করুন। Blind restore root cause ঢেকে দিতে পারে এবং একই vulnerable plugin থাকলে error ফিরে আসতে পারে।

সম্ভব হলে production clone staging-এ নিয়ে পরীক্ষা করুন। Staging-এ search indexing বন্ধ, outgoing email আটকানো এবং payment gateway sandbox করা উচিত। Site পুরো down হলে emergency change production-এ লাগতে পারে; তখন প্রতিটি file rename ও setting একটি change log-এ লিখুন। একবারে একটি action, তারপর একই URL test—এভাবে cause/effect বোঝা যায় এবং rollback সহজ হয়।

File Manager বা SFTP ব্যবহার করলে original file download করে রাখুন। Secret-সহ wp-config.php public support ticket-এ দেবেন না। Database password বদলালে dependent service update করুন। Terminal command copy-paste করার আগে path ও উদ্দেশ্য বুঝুন; root privilege-এ অচেনা script চালাবেন না। 777 permission বা security plugin সম্পূর্ণ মুছে দেওয়া দ্রুত fix মনে হলেও নতুন vulnerability তৈরি করতে পারে।

Error log ও WordPress debug log থেকে আসল কারণ খুঁজুন

Hosting control panel-এ Errors, Logs, PHP Logs বা Raw Access নামে section থাকতে পারে। Error হওয়ার exact সময়ের আশপাশে “PHP Fatal error”, “Allowed memory size exhausted”, “Uncaught TypeError”, “Permission denied” বা নির্দিষ্ট plugin path খুঁজুন। একটি log line-এ file path ও line number থাকলে সংশ্লিষ্ট component চিহ্নিত হয়; কিন্তু সেই line সব সময় মূল cause নয়—তার আগের stack/contextও দেখুন।

WordPress debugging সাময়িকভাবে চালু করলে wp-content/debug.log-এ তথ্য লেখা যেতে পারে। Live site-এ error visitor-এর সামনে দেখাবেন না; display বন্ধ রেখে log capture করুন। Log file-এ path, email, token বা request data থাকতে পারে, তাই public URL থেকে সুরক্ষিত রাখুন এবং diagnosis শেষে debug mode বন্ধ ও file safely remove/archive করুন। বারবার warning লিখে disk পূর্ণ হচ্ছে কি না দেখুন।

Log না থাকলে host support-কে URL, timestamp, timezone, visitor IP (প্রয়োজন হলে), recent change এবং request ID দিন। “site কাজ করে না”র বদলে reproducible steps দিলে তারা web server, PHP-FPM, firewall ও resource graph মিলিয়ে দেখতে পারে। Browser developer console মূলত client-side সমস্যা দেখায়; 500 diagnosis-এ Network tab response সহায়ক হলেও server error log বেশি নির্ভরযোগ্য।

সাম্প্রতিক পরিবর্তন rollback করে দ্রুত পরীক্ষা

Error শুরু হওয়ার ঠিক আগে plugin/theme/core update, PHP change, code snippet, cache rule, migration, restore বা security setting হয়েছে কি না দেখুন। যদি একটি নির্দিষ্ট change-এর পর সঙ্গে সঙ্গে failure হয়, full site restore না করে সেই change rollback প্রথম পরীক্ষা হতে পারে। তবে vulnerable পুরোনো version দীর্ঘদিন চালাবেন না; compatibility fix বা supported alternative পরিকল্পনা করুন।

Deployment থাকলে known-good release-এ code rollback করুন, কিন্তু database migration backward-compatible কি না বুঝুন। Page builder save-এর পরে error হলে revision বা staging copy সাহায্য করতে পারে। DNS change 500-এর সরাসরি কারণ নয়, তবে visitor নতুন misconfigured server-এ গেলে error দেখা দিতে পারে; domain কোন IP-তে যাচ্ছে যাচাই করুন। Cache purge করে correct origin response দেখুন।

Change history না থাকলে automatic update email, file modification time, hosting event log এবং administrator activity log দেখুন। Compromise সন্দেহ হলে শুধু file timestamp বিশ্বাস করবেন না; malware time বদলাতে পারে। Security scan, core checksum এবং account access review করুন। দ্রুত online হওয়া জরুরি হলেও evidence না মুছে current copy রাখুন।

Plugin conflict শনাক্ত করার নিরাপদ পদ্ধতি

WordPress admin খোলা গেলে সব plugin bulk deactivate করে error URL test করুন। Error চলে গেলে plugin একে একে activate করে প্রতিবার test করুন। Traffic-heavy live site-এ plugin বন্ধ করলে checkout, cache, security বা form ক্ষতিগ্রস্ত হতে পারে; staging বা maintenance window ব্যবহার করুন। Must-use plugin আলাদা directory-তে থাকতে পারে এবং সাধারণ plugin screen থেকে deactivate হয় না—log path দেখে সেটিও বিবেচনা করুন।

Admin না খুললে SFTP/File Manager-এ wp-content/plugins folder-এর নাম সাময়িক বদলে WordPress-কে plugins unavailable করতে পারেন। Original নাম নোট করুন এবং direct delete করবেন না। Site ফিরলে folder নাম আগের মতো করে individual plugin folder rename করে culprit isolate করুন। Object cache/drop-in file যেমন advanced-cache.php বা object-cache.php সাধারণ list-এর বাইরে আচরণ করতে পারে; provider documentation ছাড়া সেগুলো সরাবেন না।

Culprit পাওয়ার পরে log ও version নিয়ে developer/vendor support দেখুন। Latest compatible release, PHP requirement এবং known issue পরীক্ষা করুন। Nulled বা abandoned plugin বদলে maintained alternative নিন। Error লুকাতে plugin-এর source file সরাসরি edit করলে পরের update-এ পরিবর্তন হারাবে এবং security risk থাকবে। Temporary workaround নথিভুক্ত করে permanent fix-এর deadline দিন।

Theme বা custom code থেকে 500 Error হলে কী করবেন

Plugin বাদ দেওয়ার পর active theme পরীক্ষা করুন। Dashboard থেকে একটি current default WordPress theme activate করে একই URL দেখুন। Default theme আগে installed না থাকলে source যাচাই করে install করুন; live design বদলাবে বলে staging-এ test ভালো। Admin inaccessible হলে active theme folder rename করলে fallback theme available থাকলে WordPress সেটি নিতে পারে। আগে theme name ও customization backup করুন।

Child theme-এর functions.php, custom snippet, template override বা recently added hook fatal error তৈরি করতে পারে। Error log-এর file/line ধরে code review করুন। শুধু offending snippet comment করার আগে syntax ও dependency বুঝুন। Theme file editor-এ live edit risky; SFTP এবং version control ব্যবহার করলে rollback সহজ। PHP opening/closing tag, missing semicolon, duplicate function বা incompatible type সাধারণ কারণ হতে পারে।

Theme switch-এ error চলে গেলে মূল theme-এর latest compatible version test করুন। Parent ও child theme উভয়ের version মিলিয়ে নিন। License শেষ হলেও unofficial package ব্যবহার করবেন না। Builder-generated cache ও compiled CSS regenerate লাগতে পারে, কিন্তু cause isolate করার আগে cache operation বারবার চালাবেন না। Vendor-কে sanitized log, WordPress/PHP version ও reproduce step দিন।

Apache বা LiteSpeed environment-এ corrupted কিংবা unsupported .htaccess directive 500 তৈরি করতে পারে। WordPress official troubleshooting-এর পরিচিত ধাপ হলো root-এর file download করে .htaccess_old নামে rename করা, তারপর site test। File hidden হওয়ায় File Manager-এ “show hidden files” চালু করতে হতে পারে। Nginx server সাধারণত .htaccess পড়ে না; সেখানে এই ধাপ প্রযোজ্য নয় এবং server block host/developer পরিচালনা করবেন।

Rename-এ site ফিরলে WordPress dashboard-এর Settings → Permalinks-এ structure না বদলিয়ে Save করলে নতুন rewrite rule তৈরি হতে পারে। কিন্তু custom redirect, security header, cache বা application rule পুরোনো file-এ ছিল—সেগুলো অন্ধভাবে বাদ দেবেন না। Clean WordPress block ও custom rule আলাদা করে review করুন। Rule একে একে যোগ করে test করুন এবং redirect loop/404 হচ্ছে কি না দেখুন।

Plugin অনেক সময় .htaccess লিখতে চায়; wrong ownership বা read-only permission update failure সৃষ্টি করতে পারে। Web server-এর recommended permission provider থেকে নিন। 777 দিয়ে write খুলে দেওয়া সমাধান নয়। File-এ অচেনা obfuscated code বা redirect দেখলে compromise সন্দেহ করুন; copy রেখে security investigation ও credential rotation করুন।

PHP memory, version, extension ও execution limit পরীক্ষা

Log-এ “Allowed memory size exhausted” থাকলে কোন request অতিরিক্ত memory নিচ্ছে প্রথমে দেখুন। Limit সামান্য বাড়ালে diagnosis বা temporary recovery হতে পারে, কিন্তু leak, oversized query বা heavy plugin থাকলে শুধু memory বাড়ানো স্থায়ী fix নয়। WordPress, PHP, server এবং hosting plan—বিভিন্ন স্তরের limit-এর মধ্যে কার্যকর সীমা নির্ধারিত হয়। Provider maximum-এর বেশি setting লিখলে কাজ নাও করতে পারে।

PHP version বদলের পরে error হলে theme/plugin compatibility check করুন। Unsupported পুরোনো PHP-তে ফিরে যাওয়া security risk, তাই staging-এ component update বা replacement করুন। Missing extension, disabled function, wrong handler এবং PHP-FPM configuration-ও failure ঘটাতে পারে। Site Health তথ্য ও host panel-এর module list compare করুন, তবে secret value share করবেন না।

Import, backup বা image processing-এর সময় 500 হলে upload size, post size, execution time, input variable, disk/inode এবং temporary directory দেখুন। Limit বাড়ানোর আগে request legitimate এবং resource plan যথেষ্ট কি না বুঝুন। Shared hosting-এ global setting বদলাতে নাও পারেন; support-এর সাহায্য লাগবে। Repeated timeout হলে কাজ batch করুন বা command-line/provider tool ব্যবহার করুন।

Corrupted core file, permission ও database সমস্যা

Incomplete core update বা malware WordPress core file বদলাতে পারে। Official package-এর একই supported version থেকে wp-admin ও wp-includes fresh copy re-upload একটি পরিচিত recovery ধাপ, কিন্তু wp-content এবং wp-config.php overwrite করবেন না। কাজের আগে full backup নিন এবং download source যাচাই করুন। Managed host-এ core repair feature থাকলে provider-supported পদ্ধতি বেশি নিরাপদ।

File permission/ownership ভুল হলে PHP file পড়তে বা লিখতে পারে না। সাধারণ recommendation environment অনুযায়ী ভিন্ন, তাই host-এর documented default ব্যবহার করুন। Recursive command ভুল path-এ চালালে অন্য account বা secret file exposed হতে পারে। 777 permission দিয়ে symptom লুকাবেন না। Migration-এর পর owner/group mismatch হলে support ঠিক করতে পারে। Disk quota বা inode পূর্ণ হলেও log, session বা cache write ব্যর্থ হয়ে 500 হতে পারে; usage graph দেখুন।

Database corruption বা unavailable server কখনো 500, কখনো database connection message দেয়। Database service status, credential, table health এবং slow query দেখুন। Repair command বা table operation-এর আগে export নিন। WooCommerce order table বা large database-এ generic optimize/repair tool production load বাড়াতে পারে; maintenance window ও specialist input নিন।

Hosting, firewall, CDN ও security layer-এর সমস্যা

Web Application Firewall কোনো legitimate request-কে attack ভেবে block করলে upload, page save বা checkout-এ 500/403 দেখা যেতে পারে। Rule পুরোপুরি বন্ধ না করে request ID ও exact action নিয়ে host/security vendor-কে false positive যাচাই করতে বলুন। Temporary allow exception narrow path/user/IP-এর জন্য এবং সীমিত সময়ে দিন। Security layer বন্ধ রেখে site online রাখলে বাস্তব attack-এর ঝুঁকি বাড়ে।

Reverse proxy, CDN, load balancer ও origin-এর মধ্যে timeout বা header mismatch 502/504-এর মতো response দিতে পারে। CDN pause করে origin সরাসরি test কেবল diagnosis-এর জন্য করুন এবং origin exposure/security বুঝে নিন। SSL mode mismatch redirect loop বা handshake failure তৈরি করতে পারে। DNS সঠিক origin দেখাচ্ছে, certificate valid এবং server host rule domain গ্রহণ করছে কি না পরীক্ষা করুন।

Shared host resource suspension, process limit বা noisy-neighbor issue owner নিজে fix করতে পারবেন না। Resource graph, error log ও provider status দেখুন। Traffic spike legitimate হলে cache ও plan scaling; bot attack হলে rate limiting/CDN; inefficient code হলে profiling দরকার। “আরও শক্তিশালী server” সব code problem সমাধান করে না। পরিকল্পিত optimization জানতে WordPress Website Speed বাড়ানোর ১৫টি উপায় দেখুন।

১০ ধাপের বাস্তব troubleshooting order

  1. Exact URL, সময়, action ও scope লিখুন।
  2. Current state এবং last-known-good backup নিরাপদ করুন।
  3. Hosting/PHP log-এ একই timestamp-এর fatal error দেখুন।
  4. সাম্প্রতিক change একটি করে rollback করুন।
  5. Staging বা maintenance window-তে plugins isolate করুন।
  6. Default theme দিয়ে test করুন।
  7. Server type অনুযায়ী .htaccess/rewrite পরীক্ষা করুন।
  8. PHP compatibility, memory, extension, disk ও inode দেখুন।
  9. Core integrity, permission ও database যাচাই করুন।
  10. Evidenceসহ host/vendor support-এ escalate করুন।

প্রতিটি ধাপে “আগে/পরে” ফল লিখুন। কোনো action-এ error বদলে 404 বা warning হলে সেটিও evidence। Random internet snippet, অচেনা SQL অথবা সব plugin delete করা এড়িয়ে চলুন। Fix পাওয়ার পরে temporary debug, raised limit বা disabled security control আগের নিরাপদ অবস্থায় ফিরিয়ে দিন। Cache purge করে logged-in ও logged-out user দুইভাবে test করুন।

Post-incident review-এ root cause, impact duration, lost transaction, detection gap এবং permanent action লিখুন। Automatic backup, uptime monitoring, update staging, least privilege এবং change log ভবিষ্যৎ outage কমায়। Hosting সীমা বারবার সমস্যা হলে plan/provider মূল্যায়ন করুন; বাংলাদেশে Web Hosting নির্বাচনের গাইড requirement বুঝতে সাহায্য করবে।

কাজ শুরুর আগে সংক্ষিপ্ত চেকলিস্ট

  • Error-এর exact URL, সময়, timezone, action ও affected scope নথিভুক্ত আছে।
  • কোনো file/database change-এর আগে current backup এবং rollback plan তৈরি হয়েছে।
  • PHP/server log secret বাদ দিয়ে নিরাপদে সংগ্রহ করা হয়েছে।
  • একবারে একটি পরিবর্তন করে একই test পুনরাবৃত্তি করা হচ্ছে।
  • Plugin/theme test staging বা controlled maintenance window-তে হচ্ছে।
  • Debug display public visitor-এর জন্য বন্ধ এবং log access সুরক্ষিত।
  • Fix শেষে security control, permission, cache ও critical business flow পুনরায় যাচাই হবে।

সম্পর্কিত আরও গাইড

Server resource ও support বারবার সমস্যা করলে উপযুক্ত Web Hosting নির্বাচনের নির্দেশনা দেখুন। Hosting panel থেকে log, backup ও PHP manage করা সহজ করতে WordPress-এর সেরা control panel তুলনা কাজে লাগবে।

সাধারণ প্রশ্ন ও উত্তর

WordPress 500 Error কি browser-এর সমস্যা?

সাধারণত এটি server-side response। Browser cache পুরোনো error দেখাতে পারে, কিন্তু মূল কারণ plugin, theme, PHP, rewrite, permission বা hosting layer-এ খুঁজতে হয়। অন্য network/device test scope বুঝতে সাহায্য করে।

সব plugin deactivate করলে content মুছে যাবে?

সাধারণত deactivate করলে plugin file বা database data সঙ্গে সঙ্গে মুছে যায় না, তবে feature, shortcode, checkout বা security সাময়িকভাবে বন্ধ হতে পারে। তাই backup ও staging/maintenance window ব্যবহার করুন; uninstall চাপবেন না।

PHP memory limit বাড়ালেই কি 500 Error ঠিক হবে?

শুধু memory exhaustion log থাকলে সীমা সাময়িক সহায়তা করতে পারে। Heavy query, leak বা faulty plugin থাকলে কারণ সমাধান না করে limit বাড়ানো resource খরচ ও পরবর্তী failure বাড়ায়।

.htaccess delete করা কি নিরাপদ?

সরাসরি delete না করে backup নিয়ে rename করুন এবং server Apache/LiteSpeed কি না বুঝুন। Site ফিরলে permalink save করে base rule তৈরি ও custom rule carefully review করুন। Nginx-এ .htaccess কার্যকর নয়।

Error log কোথায় পাব?

Hosting panel-এর Errors/PHP Logs, server log অথবা নিরাপদভাবে চালু করা WordPress debug.log-এ পাওয়া যায়। Location providerভেদে ভিন্ন; exact timestampসহ support-কে জিজ্ঞাসা করুন।

কখন hosting support-এর কাছে যাব?

Server log access নেই, resource/service failure, permission ownership, WAF false positive, database service বা PHP-FPM configuration সন্দেহ হলে দ্রুত support নিন। URL, সময় ও already-tested step দিন।

শেষ কথা

WordPress 500 Error ভয়ংকর দেখালেও অধিকাংশ ক্ষেত্রে evidence-ভিত্তিক ধাপে কারণ আলাদা করা যায়। আগে backup, তারপর scope ও log, পরে recent change, plugin, theme, rewrite, PHP এবং server layer—এই order অনুসরণ করুন। একবারে একটি পরিবর্তন ও স্পষ্ট rollback রাখলে “fix করতে গিয়ে আরও ভাঙা” এড়ানো যায়। Site ফিরলে temporary workaround সরিয়ে root cause patch, backup/monitoring উন্নত এবং ঘটনা document করুন।

WordPress, PHP, web server, security plugin ও hosting dashboard-এর menu এবং supported version সময়ের সঙ্গে বদলে যায়। আপনার installation ও provider-এর বর্তমান official documentation, compatibility requirement এবং support instruction মিলিয়ে প্রতিটি technical change করুন।

মন্তব্য করুন