Closte Down? How to Get Your Site Back Online (and Move It Safely)

If your website is down right now and your hosting company isn’t answering, the fastest path back online is usually not waiting for them — it’s moving your site somewhere else. That’s only possible if you know what you own and where it lives.

This was on our minds because in July 2026 it happened to real businesses. Customers of the managed WordPress host Closte reported multi-day outages, with third-party monitors showing roughly 90.5% uptime over a 30-day window at the time. To translate that: about three days of downtime in a single month. As of 21 August 2026 that figure has fallen to roughly 52.6%. Reviews describe support tickets going unanswered for weeks, and one reported incident on a France-based server left sites offline for over a month.

We’re not writing this to pile on one company — every host has bad weeks, and we have no inside knowledge of what’s happening there. We’re writing it because the situation is a perfect illustration of a risk most small business owners never think about until the day it lands: your website’s availability depends on a company you probably chose on price, years ago, and haven’t thought about since.

Is Closte down? What we know (July–August 2026)

If you landed here because your Closte-hosted site or dashboard is unreachable, here’s what is publicly verifiable as of 26 August 2026. We’re not affiliated with Closte and have no inside information — everything below is either checkable yourself or clearly labelled as a user report.

What’s independently verifiable:

• closte.com is returning NXDOMAIN — the domain isn’t resolving in DNS.
• ICANN Lookup shows the domain in clientHold status. That’s a registrar-applied hold, and it’s what removes a domain from DNS — which explains the NXDOMAIN responses. Importantly, clientHold tells you that a hold exists, not why.
• Because app.closte.com is unreachable, many customers can’t open a support ticket, reach SFTP, or download the nightly backups stored inside Closte’s own infrastructure.
• Support has reportedly been unresponsive for months, with multiple users describing tickets going unanswered well before this incident.

This has happened before — that’s the part that matters. Users report a near-identical incident in April 2025, also a DNS-level failure that took the platform down with no advance communication. One affected user described it as an upstream DNS problem with no backup DNS or redundancy in place. Recovery times varied from around 12 hours for dashboard access to considerably longer for others.

A single bad week is bad luck. The same failure mode twice, with the same silence, is a pattern — and a pattern is something you can plan around.

What is not confirmed — be careful here:

• There is no official statement from Closte explaining the outage, and no announcement that they are shutting down. We won’t speculate.
• A claim circulating that this was caused by a DDoS attack is unverified. When asked for a source, the person who posted it didn’t provide one. Treat it as rumour.
• Whether all customer sites are affected, whether backups remain recoverable, and when service returns are all still unknown.

The deeper lesson in that checklist: the people struggling most aren’t the ones with the most complex sites. They’re the ones whose backups, DNS, domain, and hosting all lived with the same provider — so when it went dark, every recovery route went dark with it.

Good news: your site is probably still running

This is the part that gets lost in the panic. In most reported cases the websites themselves are still online and serving visitors. What’s broken is Closte’s own infrastructure — their domain, their dashboard, and their CDN. Your WordPress install is still sitting on its server doing its job.

The most common symptom people describe is a site that loads but looks broken — missing CSS, missing images, unstyled text. That’s not your site being damaged. That’s the CDN failing to serve your static assets while the rest of the page loads fine.

So the realistic situation for most people is: my site is up, it looks wrong, and I can’t get into my dashboard. All three of those are fixable, and none of them mean your data is gone.

The workaround: reach your sites by IP

Here’s why this works. When you type a domain into your browser, two separate things happen:

1. DNS lookup — your computer asks “what’s the IP address for this domain?”
2. Connection — your computer connects to that IP and asks for the site.

Closte’s step 1 is broken. Step 2 is fine.

Every operating system has a hosts file that gets checked before any DNS server. Put an entry in it and your machine skips the lookup entirely, going straight to the IP you specify. That’s the whole trick.

Step 1 — Get back into the Closte dashboard

Closte’s control panel lives at a known IP that’s still responding.

macOS / Linux:

echo "34.95.115.200  app.closte.com" | sudo tee -a /etc/hosts
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

(Linux: skip the second line, or use sudo systemd-resolve --flush-caches.)

Windows: open Notepad as Administrator, open C:\Windows\System32\drivers\etc\hosts, add:

34.95.115.200  app.closte.com

Save, then run ipconfig /flushdns.

Now go to https://app.closte.com — it loads.

Credit where it’s due: this IP was first posted by a user in the r/Wordpress thread about the outage. It saved a lot of people a lot of hours.

Step 2 — Find your site’s server IP

In the dashboard: Sites → click your site → find the SSH / SFTP section.

The Host field is your server’s IP. Note it, along with the Port (Closte uses 55000, not the usual 22) and the User.

While you’re there, check the browser URL — it ends with your site ID:

https://app.closte.com/sites/details/a1b2c3d4e5f6a1b2c3d4e5f6
                                     └──────── site ID ────────┘

That ID matters — see the gotcha below.

A big time-saver: Closte packs many sites onto each server. When we mapped 49 sites, they lived on just 9 IPs — one server alone hosted 19 of them. So check two or three sites first. One IP probably covers most of your portfolio, and you can write all your hosts entries in a single pass instead of clicking through every site.

Step 3 — Reach the actual site

Two routes. Pick based on what you need.

Route A — Hosts file (use this if you want the browser and wp-admin)

203.0.113.45  app-a1b2c3d4e5f6a1b2c3d4e5f6.closte.com

Flush your DNS cache again and the site loads — including /wp-admin. HTTPS keeps working too; Closte’s certificate covers *.closte.com, so no browser warning.

Route B — SFTP (easier if you just want the files)

• Host: the IP from Step 2
• Port: 55000
• Protocol: SFTP
• User: the site ID
• Password: the Copy button in the Closte panel

Download wp-content/ and grab the database from the panel’s DB button. Route B is better for backups: no hosts editing, no plugin, and no size limits — which matters if your site is over the free All-in-One WP Migration import cap.

The gotcha that cost us an hour

Your real domain often will not work as the hostname. Use the app-<siteID>.closte.com form instead.

We hit this repeatedly: add clientsite.com → <IP>, flush, get a connection timeout. The IP was right. The server was up. But the site wouldn’t answer to that hostname.

Some Closte sites only respond to their internal app-*.closte.com address — the vhost never had the production domain properly bound. The server sees a hostname it doesn’t recognise and drops the request.

So when a real domain doesn’t respond, build the internal hostname from the site ID:

app-<siteID>.closte.com

Test an IP without touching your hosts file at all. curl can fake the DNS lookup for a single request:

curl -sI --resolve app-a1b2c3d4e5f6a1b2c3d4e5f6.closte.com:443:203.0.113.45 \
  https://app-a1b2c3d4e5f6a1b2c3d4e5f6.closte.com/

HTTP/2 200 means you found it. That’s how we mapped a whole portfolio — probing every hostname against every known IP in parallel — without editing /etc/hosts once.

Fix the broken styling (the CDN issue)

If pages load but the design is missing, stop the site routing assets through the dead CDN:

1. Get into wp-admin (Route A above).
2. Disable the CDN in the Closte/LiteSpeed setting, so WordPress serves assets directly.
3. Clear all caches — site, page, and browser.
4. Test in a private window or another device. Your browser cached the broken version and will keep showing it to you long after it’s fixed.

Once styling is back, visitors see a normal site again — which buys you room to migrate calmly instead of at 2am.

Step 4 — Export the site properly

With wp-admin access restored, take a complete copy before changing anything else. The simplest route bundles everything — database, media, themes, plugins — into one file:

• All-in-One WP Migration — exports to a single .wpress file. Friendliest if you’re not technical.
• Duplicator — installer plus archive. Good for larger sites.
• UpdraftPlus — component backups, can push straight to cloud storage.

Step 5 — Move it anywhere you like

That export is a standard WordPress site, so it goes to any WordPress host. Spin up a blank WordPress install at the destination, install the same plugin, import the file — your site comes back exactly as it was.

There’s no lock-in. A WordPress export is portable by design — the only thing that varies is how much server management you want to do yourself.

Order matters when you switch: get the site fully working at the new host first, on a temporary URL, and only then repoint DNS. The other way round shows visitors a broken site instead of an old one.

Other things worth knowing

A VPN doesn’t break this. The hosts file is consulted locally, before anything hits the network.

Set a generous timeout. These servers are under unusual load. We got false negatives at 10 seconds that came back clean at 25 — three sites written off as unreachable were fine all along.

phpMyAdmin SSO may not work. The handoff bounces through a hostname that isn’t in your hosts file. Add that hostname too, or use the panel’s direct DB export.

Can’t log into wp-admin? If the login is broken independently of the outage, reset the password in the database via the panel’s DB tool — set wp_users.user_pass to the MD5 hash of your new password. WordPress still accepts MD5 and silently upgrades it afterward.

Clean up when you’re done

This is the part people forget, and it bites.

Once a site’s DNS is fixed — or you’ve migrated and repointed the domain — delete that line from your hosts file. Otherwise your machine keeps sending you to the old Closte server, and you’ll be staring at the pre-migration site convinced the migration failed.

Back the file up first, and keep your entries in one clearly-marked block:

# === Closte outage workaround — remove when resolved ===
34.95.115.200    app.closte.com
203.0.113.45     app-a1b2c3d4e5f6a1b2c3d4e5f6.closte.com

How bad is website downtime, really?

Those percentages look similar and behave nothing alike. “Two nines” versus “three nines” is the difference between a rounding error and a business problem.

When your site is down, you lose more than visits:

• Leads that never arrive. Someone searched, clicked, got an error, and hired whoever was second in the results. You’ll never see that in your analytics — it just looks like a quiet week.
• Trust with people who already know you. A customer who clicks your link from an invoice or a business card and hits a dead page doesn’t think “hosting issue.” They think “is this business still running?”
• Search visibility, if it drags on. Google is forgiving of short blips. Extended outages are a different story — repeated failed crawls can push pages out of the index, and coming back is slower than going away. The same logic applies to speed: a site that loads slowly loses customers quietly, without ever going down.
• Your email, sometimes. If your domain’s email runs through the same provider, an outage can take your inbox with it. Many owners discover this connection at the worst possible moment.

The warning signs of a failing host

Hosting companies rarely announce that they’re in trouble. They just get quieter. Here’s what the slide usually looks like, roughly in order:

Any one of these can be a bad month. Three or more at once is a pattern, and it’s your cue to prepare an exit — before you’re forced into one during an outage, when everything is harder.

What do you actually own?

This is the question that decides how bad a hosting failure is for you. There are four separate things, and they are commonly confused:

The dangerous setup is having all four with one provider. That’s a single point of failure for your entire online presence: when they go down, you have no address, no site, no email, and no way to fix it. Splitting them costs nothing extra and is the single best insurance policy you can buy.

What to do when your site is down today

Work through this in order. The early steps are free and take minutes.

1. Confirm it’s actually down. Use an outside checker rather than your own browser — caching and local DNS lie. If it’s up for the rest of the world and down for you, it’s your network, not your host.

2. Check the host’s status page and their social accounts. Social is often more honest than the status page during a real incident, because status pages are updated by the same busy team.

3. Open a support ticket immediately, even if you expect nothing. It timestamps the problem. If you later want a refund, a credit, or leverage, that record matters.

4. Find your most recent backup. Not the one on the host — one you control. If you don’t have one and the site is still partially reachable, download everything you can right now, while you still can.

5. Set a deadline and mean it. Decide up front: “if this isn’t resolved in X hours, I move.” Without a threshold, most people wait indefinitely, because leaving always feels like more work than waiting one more hour. That’s how a one-day outage becomes a three-week one.

6. Put up something rather than nothing. A one-page holding site with your phone number, email, and a short note beats an error page by an enormous margin. It can be live in under an hour and it keeps the phone ringing.

7. If you’re moving, change DNS last. Get the site fully working at the new host first, then repoint. Doing it in the other order gives visitors a broken site instead of an old one.

How to make this a non-event next time

You can’t stop a host from failing. You can make it a minor annoyance instead of an emergency.

• Keep your domain at a separate registrar from your hosting. If the host disappears, you still control the address — and can point it at a new server the same day. This one habit does more than everything else combined.
• Use automatic backups you control, stored somewhere else entirely (cloud storage, another provider, your own machine). A backup that lives only on the failing server is not a backup.
• Know your recovery time honestly. Not “we have backups” — but “we could be live somewhere else within X hours.” If you don’t know the number, it’s longer than you think.
• Prefer boring, well-supported platforms. Exotic setups are fine until the one person who understands them is unreachable.
• Check in on your host once a year. Five minutes: recent reviews, status page history, and whether support still answers a test question. Cheap early warning.

How to move your site off a failing host

If you’ve decided to leave, the order matters. Doing this in the wrong sequence is what turns a migration into a second outage.

1. Secure the domain first. Log in to your registrar and confirm you have access and that the domain isn’t expiring soon. Everything else depends on this. If the domain is at the failing host, start a transfer out immediately — transfers can take days, so this is the long pole.

2. Recover whatever site data you can. Files and database if the host is reachable at all — including via a direct IP connection if DNS is the thing that’s broken. If it isn’t reachable, fall back to: your own backups, a backup plugin’s cloud copy, your developer’s copy, or — as a last resort — the Wayback Machine, which can recover page content and structure even when the original is gone.

   If you can’t find your server’s IP because the dashboard is down, check old emails from your host, your browser history, or a historical DNS lookup service like SecurityTrails or ViewDNS.

3. Rebuild at the new host before touching DNS. Get it fully working and tested on a temporary URL. No visitor should ever see a half-migrated site.

4. Lower your DNS TTL a day ahead if you can still reach your DNS settings. It makes the final switch propagate in minutes instead of hours.

5. Repoint DNS, then verify from outside your own network — a different device, mobile data, or an online checker. Your own browser caches aggressively and will lie to you.

6. Keep the old account alive briefly if it’s cheap to do so, until you’re certain nothing was missed.

For a typical small business WordPress site with backups in hand, this is a few hours of work. Without backups, it’s a rebuild — which is exactly why the boring habits in the previous section matter so much.

The real lesson

The businesses that came through this particular outage quickly weren’t lucky, and they weren’t more technical. They just happened to have their domain somewhere separate, a backup they controlled, and a willingness to stop waiting.

Everyone else is still refreshing a status page.

Your website is infrastructure now — as much as your phone line or your payment terminal. It deserves the same question you’d ask about those: what’s my plan when this fails? Answering that on a calm Tuesday takes fifteen minutes. Answering it mid-outage takes days you don’t have.

If you’re not sure how exposed you are — or you’re staring at a dead site right now — get in touch. We’re happy to tell you honestly whether your setup is fine or fragile, even if the answer is that you don’t need us.

Stuck on a host that’s gone dark and need the site moved quickly? That’s ordinary work for us — we’ll tell you upfront what’s recoverable and what isn’t, before you commit to anything.