{"id":2401,"date":"2025-11-24T15:23:11","date_gmt":"2025-11-24T12:23:11","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/wordpress-keeps-getting-hacked-cleanup-hardening-and-migration-on-shared-hosting\/"},"modified":"2025-11-24T15:23:11","modified_gmt":"2025-11-24T12:23:11","slug":"wordpress-keeps-getting-hacked-cleanup-hardening-and-migration-on-shared-hosting","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/wordpress-keeps-getting-hacked-cleanup-hardening-and-migration-on-shared-hosting\/","title":{"rendered":"WordPress Keeps Getting Hacked? Cleanup, Hardening and Migration on Shared Hosting"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>If your WordPress site keeps getting hacked on shared hosting, you are not alone. We see the same pattern again and again: a quick cleanup, the site looks fine for a week or two, and then another wave of spam pages, strange redirects or phishing content appears. The problem is rarely just \u201cone infected file\u201d. On shared hosting, a hacked WordPress is usually the result of a combination of weak passwords, outdated plugins, leftover test installs, and sometimes poor isolation between sites under the same user account. If you only fix the visible symptoms, the attackers come straight back.<\/p>\n<p>In this article, we\u2019ll walk through how we approach recurring WordPress hacks on shared hosting at dchost.com: how to contain the incident, clean it properly, harden WordPress without breaking your workflow, and decide when it is time to migrate to a cleaner environment or a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>. The goal is simple: instead of living in an endless cleanup loop, you end up with a predictable, maintainable setup that resists the automated attacks hitting the web every day.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_WordPress_Keeps_Getting_Hacked_on_Shared_Hosting\"><span class=\"toc_number toc_depth_1\">1<\/span> Why WordPress Keeps Getting Hacked on Shared Hosting<\/a><ul><li><a href=\"#Its_not_just_you_automated_attacks_never_stop\"><span class=\"toc_number toc_depth_2\">1.1<\/span> It\u2019s not (just) you: automated attacks never stop<\/a><\/li><li><a href=\"#Shared_hosting_specifics_many_sites_one_user_account\"><span class=\"toc_number toc_depth_2\">1.2<\/span> Shared hosting specifics: many sites, one user account<\/a><\/li><li><a href=\"#Incomplete_cleanups_leave_backdoors_behind\"><span class=\"toc_number toc_depth_2\">1.3<\/span> Incomplete cleanups leave backdoors behind<\/a><\/li><\/ul><\/li><li><a href=\"#Step_1_Contain_the_Incident_and_Protect_Your_Accounts\"><span class=\"toc_number toc_depth_1\">2<\/span> Step 1: Contain the Incident and Protect Your Accounts<\/a><ul><li><a href=\"#Switch_from_panic_to_a_checklist\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Switch from panic to a checklist<\/a><\/li><li><a href=\"#Immediate_actions_to_take\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Immediate actions to take<\/a><\/li><li><a href=\"#Take_and_secure_your_backups_before_touching_anything\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Take (and secure) your backups before touching anything<\/a><\/li><li><a href=\"#Check_if_multiple_sites_are_affected\"><span class=\"toc_number toc_depth_2\">2.4<\/span> Check if multiple sites are affected<\/a><\/li><\/ul><\/li><li><a href=\"#Step_2_Deep_Cleanup_Removing_Malware_Properly\"><span class=\"toc_number toc_depth_1\">3<\/span> Step 2: Deep Cleanup \u2013 Removing Malware Properly<\/a><ul><li><a href=\"#Decide_repair_in_place_or_rebuild_from_a_clean_install\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Decide: repair in place, or rebuild from a clean install?<\/a><\/li><li><a href=\"#1_Replace_core_WordPress_files\"><span class=\"toc_number toc_depth_2\">3.2<\/span> 1. Replace core WordPress files<\/a><\/li><li><a href=\"#2_Clean_or_reinstall_plugins_and_themes\"><span class=\"toc_number toc_depth_2\">3.3<\/span> 2. Clean or reinstall plugins and themes<\/a><\/li><li><a href=\"#3_Scan_and_clean_the_wp-content_directory\"><span class=\"toc_number toc_depth_2\">3.4<\/span> 3. Scan and clean the wp-content directory<\/a><\/li><li><a href=\"#4_Clean_the_database_hidden_scripts_and_spam_content\"><span class=\"toc_number toc_depth_2\">3.5<\/span> 4. Clean the database (hidden scripts and spam content)<\/a><\/li><li><a href=\"#5_Remove_malicious_cron_jobs_and_backdoors\"><span class=\"toc_number toc_depth_2\">3.6<\/span> 5. Remove malicious cron jobs and backdoors<\/a><\/li><\/ul><\/li><li><a href=\"#Step_3_Hardening_WordPress_on_Shared_Hosting\"><span class=\"toc_number toc_depth_1\">4<\/span> Step 3: Hardening WordPress on Shared Hosting<\/a><ul><li><a href=\"#Secure_configuration_in_wp-configphp\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Secure configuration in wp-config.php<\/a><\/li><li><a href=\"#File_permissions_and_ownership\"><span class=\"toc_number toc_depth_2\">4.2<\/span> File permissions and ownership<\/a><\/li><li><a href=\"#Protecting_wp-loginphp_and_XML-RPC\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Protecting wp-login.php and XML-RPC<\/a><\/li><li><a href=\"#Use_a_well-configured_security_plugin_without_slowing_the_site\"><span class=\"toc_number toc_depth_2\">4.4<\/span> Use a well-configured security plugin (without slowing the site)<\/a><\/li><li><a href=\"#HTTP_security_headers_and_SSL\"><span class=\"toc_number toc_depth_2\">4.5<\/span> HTTP security headers and SSL<\/a><\/li><li><a href=\"#Follow_a_structured_hardening_checklist\"><span class=\"toc_number toc_depth_2\">4.6<\/span> Follow a structured hardening checklist<\/a><\/li><\/ul><\/li><li><a href=\"#Step_4_Shared_Hosting_Realities_When_the_Problem_Is_Bigger_Than_One_Site\"><span class=\"toc_number toc_depth_1\">5<\/span> Step 4: Shared Hosting Realities \u2013 When the Problem Is Bigger Than One Site<\/a><ul><li><a href=\"#Multiple_WordPress_installs_under_one_user\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Multiple WordPress installs under one user<\/a><\/li><li><a href=\"#Check_your_hosting_panels_security_features\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Check your hosting panel\u2019s security features<\/a><\/li><li><a href=\"#DNS_domain_and_email_implications\"><span class=\"toc_number toc_depth_2\">5.3<\/span> DNS, domain and email implications<\/a><\/li><\/ul><\/li><li><a href=\"#Step_5_When_and_How_to_Migrate_for_Better_Security\"><span class=\"toc_number toc_depth_1\">6<\/span> Step 5: When (and How) to Migrate for Better Security<\/a><ul><li><a href=\"#Signs_that_your_current_shared_hosting_setup_is_holding_you_back\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Signs that your current shared hosting setup is holding you back<\/a><\/li><li><a href=\"#Migrating_between_shared_hosting_providers_or_plans\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Migrating between shared hosting providers or plans<\/a><\/li><li><a href=\"#When_to_move_from_shared_hosting_to_a_VPS\"><span class=\"toc_number toc_depth_2\">6.3<\/span> When to move from shared hosting to a VPS<\/a><\/li><li><a href=\"#Use_staging_for_safe_updates_and_testing\"><span class=\"toc_number toc_depth_2\">6.4<\/span> Use staging for safe updates and testing<\/a><\/li><\/ul><\/li><li><a href=\"#Step_6_Long-Term_Hygiene_Staying_Clean_After_the_Hack\"><span class=\"toc_number toc_depth_1\">7<\/span> Step 6: Long-Term Hygiene \u2013 Staying Clean After the Hack<\/a><ul><li><a href=\"#Build_an_update_habit\"><span class=\"toc_number toc_depth_2\">7.1<\/span> Build an update habit<\/a><\/li><li><a href=\"#Minimalism_fewer_plugins_fewer_problems\"><span class=\"toc_number toc_depth_2\">7.2<\/span> Minimalism: fewer plugins, fewer problems<\/a><\/li><li><a href=\"#Monitor_logs_and_anomalies\"><span class=\"toc_number toc_depth_2\">7.3<\/span> Monitor logs and anomalies<\/a><\/li><li><a href=\"#Use_a_CDNWAF_layer_if_appropriate\"><span class=\"toc_number toc_depth_2\">7.4<\/span> Use a CDN\/WAF layer if appropriate<\/a><\/li><li><a href=\"#Review_hosting_and_domain_settings_annually\"><span class=\"toc_number toc_depth_2\">7.5<\/span> Review hosting and domain settings annually<\/a><\/li><\/ul><\/li><li><a href=\"#Conclusion_From_Endless_Cleanups_to_a_Calm_Secure_Routine\"><span class=\"toc_number toc_depth_1\">8<\/span> Conclusion: From Endless Cleanups to a Calm, Secure Routine<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_WordPress_Keeps_Getting_Hacked_on_Shared_Hosting\">Why WordPress Keeps Getting Hacked on Shared Hosting<\/span><\/h2>\n<h3><span id=\"Its_not_just_you_automated_attacks_never_stop\">It\u2019s not (just) you: automated attacks never stop<\/span><\/h3>\n<p>Most WordPress hacks are not personal. Automated bots constantly scan the internet for known vulnerabilities. Once they find a weak plugin, an exposed admin panel or a file upload bug, they drop malware and move on. If you\u2019re on shared hosting with a popular CMS like WordPress, you\u2019re automatically in their target list.<\/p>\n<p>Common entry points we see in real incidents:<\/p>\n<ul>\n<li><strong>Outdated plugins or themes<\/strong> with known security bugs<\/li>\n<li><strong>Nulled (pirated) themes\/plugins<\/strong> that ship with backdoors<\/li>\n<li><strong>Weak admin passwords<\/strong> reused across multiple sites<\/li>\n<li><strong>Unprotected wp-login.php or XML-RPC<\/strong> allowing brute-force attacks<\/li>\n<li><strong>Old test\/staging installs<\/strong> forgotten under subfolders like <code>\/old<\/code>, <code>\/test<\/code>, <code>\/backup<\/code><\/li>\n<\/ul>\n<h3><span id=\"Shared_hosting_specifics_many_sites_one_user_account\">Shared hosting specifics: many sites, one user account<\/span><\/h3>\n<p>On typical shared hosting, your account may host several WordPress sites under the same cPanel user. Even if each site has its own database, all their files are usually accessible by that one system user. So if one installation gets compromised and the attackers gain file-level access, they often:<\/p>\n<ul>\n<li>Inject malware into <strong>every WordPress installation<\/strong> under that account<\/li>\n<li>Drop generic backdoors into shared folders such as <code>\/tmp<\/code> or <code>\/public_html<\/code><\/li>\n<li>Add cron jobs or hidden PHP scripts that re-infect sites after you \u201cclean\u201d them<\/li>\n<\/ul>\n<p>This is why recurring hacks are so common on shared hosting. You fix one visible infection, but a hidden door or scheduled task keeps bringing the malware back.<\/p>\n<h3><span id=\"Incomplete_cleanups_leave_backdoors_behind\">Incomplete cleanups leave backdoors behind<\/span><\/h3>\n<p>Another big reason hacks keep returning: partial cleanups. Removing the obviously infected file is not enough if you do not:<\/p>\n<ul>\n<li>Replace <strong>all core WordPress files<\/strong> with clean ones<\/li>\n<li>Scan and clean <strong>all plugins and themes<\/strong> (or reinstall them fresh)<\/li>\n<li>Search the <strong>database<\/strong> for malicious scripts and spam content<\/li>\n<li>Remove <strong>malicious users, cron jobs, and hidden backdoor files<\/strong><\/li>\n<\/ul>\n<p>Attackers assume cleanups will be rushed. They almost always plant multiple persistence mechanisms. If you don\u2019t remove all of them, the hack repeats.<\/p>\n<h2><span id=\"Step_1_Contain_the_Incident_and_Protect_Your_Accounts\">Step 1: Contain the Incident and Protect Your Accounts<\/span><\/h2>\n<h3><span id=\"Switch_from_panic_to_a_checklist\">Switch from panic to a checklist<\/span><\/h3>\n<p>Before touching any files, focus on containment. You want to stop the damage from spreading to more sites, your visitors, or your email reputation.<\/p>\n<h3><span id=\"Immediate_actions_to_take\">Immediate actions to take<\/span><\/h3>\n<ul>\n<li><strong>Enable maintenance mode or a simple holding page.<\/strong> If the site is serving malware or phishing pages, temporarily put up a static maintenance page while you work.<\/li>\n<li><strong>Change all critical passwords:<\/strong>\n<ul>\n<li>WordPress admin accounts<\/li>\n<li>cPanel \/ hosting control panel account<\/li>\n<li>FTP \/ SFTP users<\/li>\n<li>Database users for the affected sites<\/li>\n<li>Email accounts tied to those domains<\/li>\n<\/ul>\n<\/li>\n<li><strong>Enable two-factor authentication (2FA)<\/strong> wherever possible, especially for your hosting and WordPress admin accounts.<\/li>\n<li><strong>Log out all WordPress sessions.<\/strong> Use the \u201clog out of all sessions\u201d option in WordPress profiles or a security plugin to invalidate existing cookies.<\/li>\n<\/ul>\n<h3><span id=\"Take_and_secure_your_backups_before_touching_anything\">Take (and secure) your backups before touching anything<\/span><\/h3>\n<p>If your hosting account or dchost.com plan keeps automatic backups, <strong>confirm that you have at least one clean restore point<\/strong> from before the first hack you noticed. Then:<\/p>\n<ul>\n<li>Download <strong>full backups<\/strong> (files + database) to your local machine<\/li>\n<li>Keep them <strong>read-only<\/strong> and clearly dated for reference<\/li>\n<\/ul>\n<p>For a deeper strategy beyond this single incident, we recommend adopting the 3\u20112\u20111 approach covered in our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-yedekleme-stratejileri-paylasimli-hosting-ve-vpste-otomatik-yedek-ve-geri-yukleme\/\">WordPress backup strategies for shared hosting and VPS<\/a>. Solid backups turn a stressful cleanup into a recoverable operation.<\/p>\n<h3><span id=\"Check_if_multiple_sites_are_affected\">Check if multiple sites are affected<\/span><\/h3>\n<p>On shared hosting, do not assume only one WordPress is infected. Quickly:<\/p>\n<ul>\n<li>List all your domains, subdomains and folders under <code>public_html<\/code><\/li>\n<li>Open their <code>wp-config.php<\/code> files (if any) to see how many WordPress sites you run<\/li>\n<li>Look for suspicious files (random names, recent timestamps) in each site\u2019s directory<\/li>\n<\/ul>\n<p>Even if only one domain is obviously serving spam, treat the entire cPanel account as suspect until proven otherwise.<\/p>\n<h2><span id=\"Step_2_Deep_Cleanup_Removing_Malware_Properly\">Step 2: Deep Cleanup \u2013 Removing Malware Properly<\/span><\/h2>\n<h3><span id=\"Decide_repair_in_place_or_rebuild_from_a_clean_install\">Decide: repair in place, or rebuild from a clean install?<\/span><\/h3>\n<p>On recurring hacks, rebuilding from a clean WordPress install is often safer and faster than hunting every single malicious line. A practical approach we often use at dchost.com:<\/p>\n<ol>\n<li>Export content (posts, pages, media) and configuration that you trust.<\/li>\n<li>Deploy a <strong>fresh WordPress<\/strong> with the latest version.<\/li>\n<li>Reinstall <strong>only the plugins and themes you really need<\/strong>, directly from trusted sources.<\/li>\n<li>Import content and reapply settings.<\/li>\n<\/ol>\n<p>However, if you have a complex site with many customizations, you may need to clean in place. In that case, go methodically.<\/p>\n<h3><span id=\"1_Replace_core_WordPress_files\">1. Replace core WordPress files<\/span><\/h3>\n<p>Start with the easiest and most reliable step:<\/p>\n<ul>\n<li>Download the latest WordPress package from wordpress.org.<\/li>\n<li>Via FTP or File Manager, <strong>delete<\/strong> all core folders except <code>wp-content<\/code> and <code>wp-config.php<\/code>:\n<ul>\n<li><code>wp-admin<\/code><\/li>\n<li><code>wp-includes<\/code><\/li>\n<li>All files in the root (like <code>index.php<\/code>, <code>wp-login.php<\/code>, etc.) except <code>wp-config.php<\/code><\/li>\n<\/ul>\n<\/li>\n<li>Upload the fresh WordPress files and folders, again without replacing <code>wp-config.php<\/code> or <code>wp-content<\/code>.<\/li>\n<\/ul>\n<p>This step removes many core-level infections and hidden backdoors.<\/p>\n<h3><span id=\"2_Clean_or_reinstall_plugins_and_themes\">2. Clean or reinstall plugins and themes<\/span><\/h3>\n<p>Plugins and themes are a primary attack vector. For each site:<\/p>\n<ul>\n<li><strong>Delete every plugin<\/strong> you are not actively using.<\/li>\n<li>Delete any <strong>nulled or \u201cpremium for free\u201d<\/strong> themes and plugins. Replace them with genuine copies or safe alternatives.<\/li>\n<li>For the rest, it is often safer to <strong>delete and reinstall<\/strong> from the official WordPress.org directory or the vendor\u2019s site instead of trying to clean them manually.<\/li>\n<\/ul>\n<p>After reinstalling, check that you are on the latest version of each plugin and theme. Vulnerability reports are public; attackers follow them closely.<\/p>\n<h3><span id=\"3_Scan_and_clean_the_wp-content_directory\">3. Scan and clean the <code>wp-content<\/code> directory<\/span><\/h3>\n<p>The <code>wp-content<\/code> folder holds your uploads, themes, plugins, and sometimes must-use plugins (<code>mu-plugins<\/code>). Common malware tricks include:<\/p>\n<ul>\n<li>PHP files hidden under <code>\/uploads\/<\/code> with image-like names<\/li>\n<li>Backdoors named like core files but placed in unusual folders<\/li>\n<li>Files with long, random names and recent modification dates<\/li>\n<\/ul>\n<p>Practical steps:<\/p>\n<ul>\n<li>Use your panel\u2019s malware scanner (if provided) as a first pass, but do not rely on it alone.<\/li>\n<li>Sort files by <strong>modification time<\/strong> and inspect anything added around the time of the hack.<\/li>\n<li>Look inside suspicious files for <code>eval(<\/code>, <code>base64_decode<\/code>, <code>gzinflate<\/code>, or heavily obfuscated code.<\/li>\n<li>Remove any PHP files from <code>\/uploads<\/code> that you did not intentionally place there.<\/li>\n<\/ul>\n<h3><span id=\"4_Clean_the_database_hidden_scripts_and_spam_content\">4. Clean the database (hidden scripts and spam content)<\/span><\/h3>\n<p>Some infections live entirely in the database: injected JavaScript in posts, hidden spam links in <code>wp_options<\/code>, or malicious shortcodes. To clean this:<\/p>\n<ul>\n<li>Use phpMyAdmin or another DB tool from your hosting control panel.<\/li>\n<li>Search in the database for common suspicious patterns like <code>&lt;script&gt;<\/code>, <code>iframe<\/code>, strange domains, or known malware signatures.<\/li>\n<li>Check the <strong><code>wp_options<\/code><\/strong> table for unexpected options with long, encoded values.<\/li>\n<li>Review <strong>admin users<\/strong> in the <code>wp_users<\/code> table and delete any accounts you do not recognize.<\/li>\n<\/ul>\n<p>After changes, clear any caching layers (plugins or CDN) so you aren\u2019t serving cached malicious content.<\/p>\n<h3><span id=\"5_Remove_malicious_cron_jobs_and_backdoors\">5. Remove malicious cron jobs and backdoors<\/span><\/h3>\n<p>Persistent hacks often rely on scheduled tasks or hidden backdoors to re-infect the site:<\/p>\n<ul>\n<li>In cPanel or your hosting panel, check <strong>Cron Jobs<\/strong> for anything unfamiliar that runs PHP scripts from odd places.<\/li>\n<li>Search your account (via File Manager or SSH if available) for suspicious PHP files named like <code>wp-*.php<\/code>, <code>config-*.php<\/code>, or totally random names.<\/li>\n<li>Check <code>wp-config.php<\/code> for extra lines at the very top or bottom that do not belong to the normal configuration.<\/li>\n<\/ul>\n<p>Only after you\u2019ve done these steps should you bring the site fully back online.<\/p>\n<h2><span id=\"Step_3_Hardening_WordPress_on_Shared_Hosting\">Step 3: Hardening WordPress on Shared Hosting<\/span><\/h2>\n<h3><span id=\"Secure_configuration_in_wp-configphp\">Secure configuration in <code>wp-config.php<\/code><\/span><\/h3>\n<p>A few simple changes to <code>wp-config.php<\/code> significantly reduce risk:<\/p>\n<ul>\n<li>Use strong, unique <strong>Authentication Unique Keys and Salts<\/strong> (you can regenerate them from the official WordPress.org salt generator).<\/li>\n<li>Disable the file editor to stop attackers from using it:\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">define('DISALLOW_FILE_EDIT', true);<\/code><\/pre>\n<\/li>\n<li>Ensure database credentials are <strong>strong and unique<\/strong>, not shared with any other app.<\/li>\n<\/ul>\n<h3><span id=\"File_permissions_and_ownership\">File permissions and ownership<\/span><\/h3>\n<p>On shared hosting, correct file permissions are crucial:<\/p>\n<ul>\n<li>Folders: typically <strong>755<\/strong><\/li>\n<li>Files: typically <strong>644<\/strong><\/li>\n<li><code>wp-config.php<\/code> can often be tightened to <strong>600<\/strong> or <strong>640<\/strong> depending on your host<\/li>\n<\/ul>\n<p>Many one-click installers or manual uploads end up with overly permissive permissions like 777 on some folders. That\u2019s an invitation for trouble.<\/p>\n<h3><span id=\"Protecting_wp-loginphp_and_XML-RPC\">Protecting wp-login.php and XML-RPC<\/span><\/h3>\n<p>Brute-force attacks on the login page and XML-RPC are extremely common. On shared hosting with Apache, you can:<\/p>\n<ul>\n<li>Use a security plugin to add <strong>rate limits, lockouts and CAPTCHAs<\/strong>.<\/li>\n<li>Restrict access to <code>wp-login.php<\/code> by IP (via <code>.htaccess<\/code>) if you have a stable IP.<\/li>\n<li>Disable or limit <strong>XML-RPC<\/strong> if you do not use Jetpack, the mobile app or external publishing tools.<\/li>\n<\/ul>\n<p>For deeper system-level protections on servers you control, we wrote a dedicated guide on stopping brute-force attacks with Nginx rate limiting and Fail2ban. Even if you stay on shared hosting, the concepts in <a href=\"https:\/\/www.dchost.com\/blog\/en\/nginx-rate-limiting-ve-fail2ban-ile-wp%e2%80%91login-php-ve-xml%e2%80%91rpc-brute%e2%80%91force-saldirilarini-nasil-saksiya-alirsin\/\">our playbook for stopping wp-login.php and XML-RPC brute force<\/a> help you understand what your provider should be doing on the server side.<\/p>\n<h3><span id=\"Use_a_well-configured_security_plugin_without_slowing_the_site\">Use a well-configured security plugin (without slowing the site)<\/span><\/h3>\n<p>A good security plugin can help with:<\/p>\n<ul>\n<li>File change monitoring<\/li>\n<li>Login protection and 2FA<\/li>\n<li>Basic firewall and known exploit blocking<\/li>\n<\/ul>\n<p>However, avoid running multiple heavy security plugins at once; they can conflict and slow down your site. Configure a single, well-maintained plugin properly and complement it with server-side measures from your hosting provider.<\/p>\n<h3><span id=\"HTTP_security_headers_and_SSL\">HTTP security headers and SSL<\/span><\/h3>\n<p>While not a complete shield against hacking, proper HTTPS and security headers protect your visitors and reduce some attack surfaces. On the hosting side, settings like HSTS, X-Frame-Options and Content-Security-Policy matter. If you want to go deeper, our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/http-guvenlik-basliklari-rehberi-hsts-csp-ve-digerlerini-ne-zaman-nasil-uygulamalisin\/\">friendly guide to HTTP security headers<\/a> explains how to set these up without breaking your site.<\/p>\n<h3><span id=\"Follow_a_structured_hardening_checklist\">Follow a structured hardening checklist<\/span><\/h3>\n<p>To avoid missing steps, we recommend going through a full checklist once and then reviewing it periodically. We\u2019ve put together such a list in our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-guvenlik-sertlestirme-kontrol-listesi-dosya-izinleri-salt-keys-xml-rpc-ufw-fail2ban-nasil-tatli-tatli-kurulur\/\">WordPress hardening checklist<\/a>. Even if you are on shared hosting (and do not control the full server), many of the application-level measures apply directly.<\/p>\n<h2><span id=\"Step_4_Shared_Hosting_Realities_When_the_Problem_Is_Bigger_Than_One_Site\">Step 4: Shared Hosting Realities \u2013 When the Problem Is Bigger Than One Site<\/span><\/h2>\n<h3><span id=\"Multiple_WordPress_installs_under_one_user\">Multiple WordPress installs under one user<\/span><\/h3>\n<p>One of the most common patterns we see is a single cPanel user hosting:<\/p>\n<ul>\n<li>The main production site<\/li>\n<li>Old test versions under subdirectories<\/li>\n<li>Client projects that were never decommissioned<\/li>\n<li>Subdomain sites with outdated plugins<\/li>\n<\/ul>\n<p>Attackers only need one of these to be weak. Once they compromise a vulnerable test site, they can jump to your main domain because the same system user owns the files.<\/p>\n<p>After a hack, consider this non-negotiable:<\/p>\n<ul>\n<li><strong>Remove old, unused WordPress installs completely.<\/strong><\/li>\n<li>At minimum, update and harden every remaining site under that account.<\/li>\n<\/ul>\n<h3><span id=\"Check_your_hosting_panels_security_features\">Check your hosting panel\u2019s security features<\/span><\/h3>\n<p>Modern shared hosting (including our shared plans at dchost.com) usually includes at least some of the following:<\/p>\n<ul>\n<li>Built-in malware scanning<\/li>\n<li>WAF (Web Application Firewall) rules tuned for WordPress<\/li>\n<li>Rate limiting and brute-force protection on common endpoints<\/li>\n<li>Isolation between accounts at the system level<\/li>\n<\/ul>\n<p>If you are repeatedly getting hacked despite cleaning and hardening your site, it\u2019s worth discussing with support what protections are in place on the server. Our <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanel-guvenlik-sertlestirme-kontrol-listesi\/\">cPanel security hardening checklist<\/a> gives you an idea of what a well-hardened hosting environment should look like.<\/p>\n<h3><span id=\"DNS_domain_and_email_implications\">DNS, domain and email implications<\/span><\/h3>\n<p>Repeated hacks can damage more than your website. If attackers send spam or host phishing pages under your domain, email providers and security tools may start to distrust your domain. Over time, this can affect deliverability and brand reputation. For a broader view of domain-side security, see our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/alan-adi-guvenligi-rehberi-registrar-lock-dnssec-whois-gizliligi-ve-2fa\/\">domain security best practices<\/a> (registrar lock, DNSSEC, WHOIS privacy and 2FA).<\/p>\n<h2><span id=\"Step_5_When_and_How_to_Migrate_for_Better_Security\">Step 5: When (and How) to Migrate for Better Security<\/span><\/h2>\n<h3><span id=\"Signs_that_your_current_shared_hosting_setup_is_holding_you_back\">Signs that your current shared hosting setup is holding you back<\/span><\/h3>\n<p>Staying on shared hosting can be perfectly fine if your provider keeps the platform updated and you maintain your WordPress properly. But there are clear red flags:<\/p>\n<ul>\n<li>Repeated hacks despite <strong>cleaning, updating and hardening<\/strong> your site<\/li>\n<li>No reliable backups or restore tools in the control panel<\/li>\n<li>No clear information about server-side security or isolation<\/li>\n<li>Performance issues after enabling basic security and caching<\/li>\n<\/ul>\n<p>In these cases, moving to a better-secured shared plan or to a VPS where you have more control over the environment can significantly reduce your risk and give you room to implement stronger protections.<\/p>\n<h3><span id=\"Migrating_between_shared_hosting_providers_or_plans\">Migrating between shared hosting providers or plans<\/span><\/h3>\n<p>If you are moving from one cPanel-based shared hosting environment to another (for example, into a hardened environment at dchost.com), the migration can usually be done with near zero downtime. We recommend:<\/p>\n<ul>\n<li>Planning your DNS TTL changes in advance so that the switchover is quick.<\/li>\n<li>Using account-level transfers or full backups rather than manual partial moves.<\/li>\n<li>Performing at least one test restore on the new platform before cutting over traffic.<\/li>\n<\/ul>\n<p>We describe this process step-by-step in <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanelden-cpanele-canli-tasima-nasil-olur-incremental-rsync-ttl-oyun-plani-ve-whm-live-transfer-ile-sifir-kesinti\/\">our zero\u2011downtime cPanel\u2011to\u2011cPanel migration playbook<\/a>. The same principles apply whether you are changing regions, providers or plans.<\/p>\n<h3><span id=\"When_to_move_from_shared_hosting_to_a_VPS\">When to move from shared hosting to a VPS<\/span><\/h3>\n<p>If your site is important to your business, security incidents are recurring, and you are hitting the limits of what can be done on shared hosting, a VPS becomes very attractive. With a VPS from dchost.com, you can:<\/p>\n<ul>\n<li>Isolate each WordPress site under its <strong>own system user<\/strong><\/li>\n<li>Deploy custom WAF rules tuned to your traffic<\/li>\n<li>Use advanced tools like Fail2ban, system firewalls, and intrusion detection<\/li>\n<li>Fine-tune PHP, database and caching for performance and security<\/li>\n<\/ul>\n<p>The move does not have to be painful. We\u2019ve documented a practical path in <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-hostingden-vpse-nasil-gecersin-kesintisiz-tasima-icin-sicacik-bir-kontrol-listesi\/\">our guide to moving from shared hosting to a VPS with zero downtime<\/a>. Even if you are not ready to move today, reading through that checklist will help you plan ahead.<\/p>\n<h3><span id=\"Use_staging_for_safe_updates_and_testing\">Use staging for safe updates and testing<\/span><\/h3>\n<p>Many hacks exploit outdated components that site owners are afraid to update because \u201csomething might break\u201d. A staging environment solves that problem. You clone your live site to a separate subdomain, apply updates and test, then push the changes to production once you are confident.<\/p>\n<p>On cPanel-based hosting (including dchost.com), you can set up a staging environment relatively easily. Our step-by-step article <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-staging-ortami-nasil-kurulur-cpanelde-alt-alan-adi-klonlama-ve-guvenli-yayina-alma\/\">how to create a WordPress staging environment on cPanel<\/a> walks you through subdomain creation, cloning, and safe go-live workflows.<\/p>\n<h2><span id=\"Step_6_Long-Term_Hygiene_Staying_Clean_After_the_Hack\">Step 6: Long-Term Hygiene \u2013 Staying Clean After the Hack<\/span><\/h2>\n<h3><span id=\"Build_an_update_habit\">Build an update habit<\/span><\/h3>\n<p>Security is not a one-time project. To avoid repeating this experience:<\/p>\n<ul>\n<li>Schedule a <strong>monthly maintenance window<\/strong> for updates.<\/li>\n<li>Update WordPress core, plugins and themes during that window.<\/li>\n<li>Remove plugins and themes you no longer use instead of letting them sit outdated.<\/li>\n<\/ul>\n<p>If you use staging (as described above), this becomes a low\u2011stress routine instead of a risky event.<\/p>\n<h3><span id=\"Minimalism_fewer_plugins_fewer_problems\">Minimalism: fewer plugins, fewer problems<\/span><\/h3>\n<p>Every plugin is another potential vulnerability. We regularly see sites with 30\u201350 plugins installed, many of them doing overlapping jobs. Over time:<\/p>\n<ul>\n<li>Audit your plugins and remove those that are redundant or rarely used.<\/li>\n<li>Prefer well-known, actively maintained plugins with transparent changelogs.<\/li>\n<li>Avoid \u201call\u2011in\u2011one miracle\u201d plugins from unknown vendors.<\/li>\n<\/ul>\n<h3><span id=\"Monitor_logs_and_anomalies\">Monitor logs and anomalies<\/span><\/h3>\n<p>On shared hosting, you may not have full system logs, but you usually have:<\/p>\n<ul>\n<li>Access logs for your domains<\/li>\n<li>Error logs for PHP and Apache<\/li>\n<li>Security plugin logs (login attempts, file changes)<\/li>\n<\/ul>\n<p>Set a simple habit: after monthly updates, quickly scan logs for unusual spikes in 404s, suspicious user agents or repeated attempts on <code>wp-login.php<\/code>. The earlier you detect a pattern, the easier it is to respond.<\/p>\n<h3><span id=\"Use_a_CDNWAF_layer_if_appropriate\">Use a CDN\/WAF layer if appropriate<\/span><\/h3>\n<p>A CDN with a Web Application Firewall in front of your site can block a good portion of generic attacks before they even hit your hosting account. This is especially helpful on shared hosting where server-level tuning is limited. Combined with the hardening steps we discussed above, it adds another layer attackers must get through.<\/p>\n<h3><span id=\"Review_hosting_and_domain_settings_annually\">Review hosting and domain settings annually<\/span><\/h3>\n<p>Once a year, take a broader look at your setup:<\/p>\n<ul>\n<li>Are you still on a plan and platform that fits your traffic and risk profile?<\/li>\n<li>Is your <strong>domain secured<\/strong> with registrar lock and 2FA?<\/li>\n<li>Is your SSL\/TLS configuration up to date and free from old protocols?<\/li>\n<li>Do you have a written, simple recovery plan if something goes wrong?<\/li>\n<\/ul>\n<p>Our team at dchost.com builds these reviews into many of the projects we work on, because they catch \u201cslow\u2011burn\u201d risks that individual incidents never reveal.<\/p>\n<h2><span id=\"Conclusion_From_Endless_Cleanups_to_a_Calm_Secure_Routine\">Conclusion: From Endless Cleanups to a Calm, Secure Routine<\/span><\/h2>\n<p>If your WordPress site keeps getting hacked on shared hosting, it is rarely because of one unlucky incident. It is almost always a mix of outdated components, weak access controls, leftover test installs, and sometimes a hosting environment that is not doing enough on the server side. The good news is that you can break the cycle. A structured cleanup, followed by solid hardening and a realistic migration plan if needed, turns recurring disasters into a manageable maintenance routine.<\/p>\n<p>Start by containing the current incident, then clean thoroughly: core files, plugins, themes, uploads, database, cron jobs and backdoors. Harden your configuration with better passwords, proper file permissions, login protections and HTTP security headers. From there, decide whether staying on your current shared hosting is still the right move or whether a hardened shared plan or a VPS at dchost.com would give you the isolation and control you need. If you want help planning that journey, our team is here to assist with migration, security reviews and ongoing hosting that is built with WordPress in mind.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>If your WordPress site keeps getting hacked on shared hosting, you are not alone. We see the same pattern again and again: a quick cleanup, the site looks fine for a week or two, and then another wave of spam pages, strange redirects or phishing content appears. The problem is rarely just \u201cone infected file\u201d. [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":2482,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-2401","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2401","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=2401"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2401\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/2482"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=2401"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=2401"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=2401"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}