Emergency website migration
Hosting unreachable or destroyed? We find the last usable backup, bring the site up on a new server, switch DNS and check payments and delivery.
A website malware scan only makes sense when it looks deeper than the page: into server files, database records, login logs and administrator accounts. Finding an infection isn't enough, though. Three separate questions follow: is the way in closed, is there a backup the site can really be restored from, and what happens if the hosting disappears along with the site. Each has its own job: hack protection, backups with restore testing, and emergency migration to another server. We start with a free review of the site's condition that takes 1–3 working days. It's an initial website security audit, after which we tell you what needs doing first and what can wait. A site without security updates keeps running as before, and the problem only shows on the day someone starts exploiting a known hole.
We update the engine and plugins, require strong passwords and two-factor login, and limit every user's permissions.
File checks, login logs and alerts help spot a break-in or suspicious activity.
Backups are stored apart from the site, so after a failure a working state can be restored.
Absolute protection doesn't exist: we reduce risk and shorten recovery time. What is actually vulnerable on your site is what an audit shows.
Hosting unreachable or destroyed? We find the last usable backup, bring the site up on a new server, switch DNS and check payments and delivery.
We update what no longer gets security fixes, close service sections, limit password guessing and verify that backups actually restore.
Copies of the database and files outside the server, with encryption and regular test recovery. We start with a free check of what you have now.
The provider gives no recovery date, or the platform is gone altogether. What you need here is an emergency migration, and the audit can wait: we start with the move and check everything else after launch.
We'll review your situation in a free auditGoogle shows a warning, unfamiliar pages have appeared in search, the host has reported malicious files, or there's a user in the admin panel nobody created. First you need to find out how they got in, and only then clean up, otherwise the infection comes back.
There's been no hack, and that's exactly why nobody has looked at what runs underneath the site. The PHP and platform versions are visible right away, and often they stopped receiving security fixes long ago. You need to close what automated scanners look for before they reach your site.
Whether they'll bring back a working store, and from what date, only a test restore can tell. The host stores something, a module archives something, but until someone actually deploys a backup there's no answer. There's a separate job for backups.
That's normal: describe what you have, and a free review will show which job is needed first. Sometimes none is, and then we'll tell you so.
We find out what's going on: the site is unavailable, there are signs of infection, or it's a scheduled check. If the site is down or was hacked just now, the review can wait. First comes what to do right away, including what not to do so the traces aren't erased.
We look at what's visible from the outside and with the hosting access you already have: versions, exposed service sections, accounts, initial signs of infection, Google warnings, whether backups exist and how recent they are, and who the domain and server are registered to. That's enough to say where the biggest risk is; investigating a hack isn't part of the review.
We take on the job the review showed as the priority and fix the scope, timeline and price in a contract. The timeline depends on what we found: setting up backups for a business card site and closing vulnerabilities in a store with dozens of third-party modules differ several times over.
We hand over a written list of what was done and what remains open, with an explanation of why. Errors on our side are fixed free of charge under the warranty; once the work is finished, we remove our access and let you know.
Online scanners only check what a visitor sees: malicious scripts on the page, redirects, blocklist status. A large share of infections hide deeper: in files changed without your knowledge, in database records, in hidden administrator accounts. That's why a full check runs on the server: we compare platform and module files against the originals, look for suspicious changes by date and review login logs. If we find something, we first figure out how it got in, otherwise it returns after the cleanup.
Don't delete suspicious files right away and don't restore a backup blindly: that destroys the traces that show how the attackers got in, and without them the hack will happen again. The first steps are changing the passwords for hosting, the admin panel and the database, and saving the current state of the server and its logs. Next comes finding the entry point, cleaning up or restoring from a backup made before the hack, and closing the vulnerability. Cleanup is separate work with its own scope; protection and backups with restore testing are set up after it.
A check of what automated attacks go after: platform, PHP and module versions without security updates, exposed admin panels and service files, weak passwords and unneeded accounts, file permissions, server settings. Backups are checked separately: where they are and whether anyone has restored from them even once. You receive a prioritized list of what to close immediately and what can be planned. On July 31, 2026, we found PHP 7.3.33 on several live stores, a version that hasn't received security updates since December 2021.
Google found malicious code, a phishing page or redirects to third-party resources on the site and flagged it in its blocklists. Visitors see the warning in the browser and in search results, and the details are in the Security Issues section of Search Console, which usually lists sample URLs. The warning can only be removed after cleanup, by submitting a review request in the same console. Submitting it before the entry point is found is pointless: the infection comes back, and the next review takes longer.
No. A certificate encrypts the connection between the browser and the server so that a password or order details can't be read in transit. It has no effect on what runs on the server itself: an outdated module with a known vulnerability is just as exposed with or without the padlock in the address bar. A hacked site with a valid certificate is a common sight.
On the surface, yes, with an online scanner: it's free, but it doesn't look deeper than the page. An initial check for signs of infection using your existing hosting access is part of our free condition review, which takes 1–3 working days. If there are signs, a full search for the entry point and cleanup is separate paid work, and we name its scope after the review.
Go by events: platform or module updates, a change of developer or of a contractor with access, the moment a PHP or platform version stops receiving security updates, and any odd behavior on the site. Backups should be checked with a test restore on a schedule: the fact that a file was created proves nothing.
That follows from what happened. The site is down because the hosting disappeared: emergency migration. The site works, but nothing underneath it has been updated in a long time: hack protection. Backups supposedly exist, but nobody has restored from them: backups with restore testing. If the site has already been hacked, cleanup comes first, and protection and backups are set up after it. Not sure? Describe the situation, and we'll name the type of work as part of the free review.
Describe the task in your own words — we will tell you where to start and whether you need what you came for. If you do not, we will say so.