If you've ever tried to update a plugin on your WordPress "live" version, you know what I'm talking about:
The web goes down.
Styles disappear.
The client calls.
You panic.
A staging environment is like a mad scientist's secret laboratory.: there you do tests, errors and adjustments before touching “the real web”.
The problem? Many staging projects are created with plugins… and sometimes that means installing more things than you should or depending on services external
Today I'm going to teach you how to do staging in WordPress. without plugins, step by step, easy, safe, and 100% under your control.
Yes, without black magic and without fear of breaking anything.
Staging, pre-production, testing environment… it doesn't matter what you call it.
It's a copy of your real website where you can:
Test plugin or template updates.
Make redesigns.
Add new features.
Breaking things (and fixing them) without anyone noticing.
Think of it as a flight simulator for your website. It's better to make mistakes here than with your website in production.
Updating WordPress, changing settings, messing with code… everything comes with its own risks.
Staging gives you:
Peace of mind.
Safe environment.
Time to test and correct.
And above all, it allows you to be brave with your website. without risking all your traffic, your SEO or your image.
Plugins like WP Staging or Duplicator are popular, yes. But staging without plugins has its advantages.
✅ Advantages of not using plugins:
Don't overload your WordPress with more extensions (less weight, less risk).
You have complete control over the process.
You don't depend on freemium licenses or limitations.
Perfect if you have many websites and don't want to pay for extra tools.
❌ Disadvantages:
Requires basic knowledge of FTP and databases.
You have to manage the security settings yourself.
The process is manual (but it's easier than it looks, I promise).
Let's get down to business.
Attention, because here begins the tutorial real.
First, you need a place to host your staging. Two options:
Subdomain: type staging.tudominio.com.
Subfolder: type tudominio.com/staging.
The subdomain option is usually better because it more clearly separates staging from production.
From your dashboard hosting (cPanel, Plesk or similar), create one.
💡 TIP: Use a discreet, non-indexable name (nothing like pruebawebgoogleindexable.com).
Connect via FTP (FileZilla or similar) or use your hosting's file manager.
Copy All the files from your WordPress:
Folders wp-content, wp-includes, wp-admin.
Loose files: wp-config.php, .htaccess, etc.
And paste them into your subdomain or subfolder.
⌛ This step takes a little while depending on the size of your website. Patience.
In your hosting panel:
Exports your current database (phpMyAdmin ➔ Export).
Create a new database for staging.
Import the database exported to this new one.
🎯 IMPORTANT:
Remember to write down the name of the new database, the username, and the password. You'll need them in the next step.
In your staging folder, edit the file wp-config.php:
Change the data of:
define('DB_NAME', 'nueva_base_de_datos');
define('DB_USER', 'nuevo_usuario');
define('DB_PASSWORD', 'nueva_contraseña');
This way, your WordPress staging system will know to read its own database, not the production one.
You almost have it!
You don't want Google to index your staging environment, do you?
Two quick ways:
Add this to the file robots.txt:
User-agent: *
Disallow: /
From WordPress: Settings ➔ Reading ➔ Discourage search engines from indexing this site.
🔒 Extra: Some hostings allow you to protect the subdomain with a password (.htpasswd). It is another highly recommended layer of security.
You've already set up your staging environment, but we're not ready to leave it open as a showcase yet.
Staging it is not a public place, it's your testing trench, and you need to protect it well.
Here are some good practices that you should definitely implement:
In cPanel or Plesk, you can add basic authentication to your subdomain or subfolder.
It's simple: any visitor will see a popup asking for credentials before being able to enter.
It's a quick and effective barrier to block prying eyes (and bots).
If you want to be more radical, limit access to the environment to only your IP or the IPs of your development team.
You can easily do this from .htaccess:
<Limit GET POST>
order deny,allow
deny from all
allow from 123.123.123.123
</Limit>
(Change 123.123.123.123 by your real IP.)
This ensures that only those on your network or on your whitelist can enter.
I've told you this before, but I'll repeat it because it's vital:
Make sure you have the “Discourage search engines” setting enabled.
Add the robots.txt restrictive.
Even if you want to be extra cautious, you can completely block access to bots with .htaccess.
💡 EXTRA TIP:
Some developers rename the directory wp-admin in staging to make it less obvious to brute force attacks.
It is not essential, but it is a plus.
Okay, you've tinkered, tested, updated, tweaked, and your staging is worthy of a magazine.
But… before uploading anything to productionLet's take a closer look at a few key points. We don't want the party to turn into a digital funeral.
Here's your checklist:
Browse all main pages.
Scroll down (sometimes mistakes live in the footer).
Click on internal and external links.
Test contact and checkout forms if you have a store.
If you have a user login, check user access and flows.
Test your staging load speed with PageSpeed Insights or GTmetrix.
If speed suffers in staging, it can suffer even more in production.
It's not just a matter of user patience; Google also measures this for SEO.
Unique titles, meta descriptions, H1s.
Make sure there are no broken links.
Check that you have not left noindex activated in staging when you migrate (very expensive rookie mistake).
Update everything before migrating.
Perform compatibility tests: especially PHP and databases.
If you've installed new plugins in staging, check that they don't cause conflicts.
Check that different URLs have not been generated by mistake (especially if your staging is in a subfolder).
Ensure that URLs remain clean and friendly in production.
💡 TIP: Use a Screaming Frog-type crawler to compare staging vs production architecture before migrating.
In staging, it may look perfect on desktop, but definitely check it on mobile and tablets.
Check drop-down menus, sliders, CTA buttons…
Backup of the production website before touching anything.
Staging backup in case you need to replicate/move only parts.
There are never too many backups. Never.
Staging without plugins in WordPress is liberating, but it also has its pitfalls.
We don't come here to scare you, we come to put you on notice so that you don't stumble into the typical mistakes that even the most experienced person makes.
Pay attention because this part can save you from wasting hours (and brain cells).
We saw it before, but I'll repeat it here: Never, ever leave your staging accessible and visible to Google..
If Google indexes it, you will have duplicate content.
If someone curious finds it, they might see test versions that you don't want to show.
And if someone with malicious intent finds it, it can be a real security issue.
🔒 Blocking via robots.txt, subdomain passwords, and/or IP restrictions. Triple layer of security!
A very common mistake: working in staging but leaving the site connected to the production database.
Consequence?
💣 You update staging ➔ And you accidentally ruin the real website.
Double check the wp-config.php and make sure that staging and production are two separate worlds.
When you finish, delete or deactivate your staging if you are not going to use it anymore.
Why?
It's an easy target for attacks if you leave it abandoned.
It will take up space on the hosting.
It can generate unnecessary traffic and resources.
Archive or delete it if you no longer need it, just like you clean up your desk after a long work session.
Classic mistake: you migrate and don't check internal links.
In staging: staging.tudominio.com/mi-producto.
In production it should be: tudominio.com/mi-producto.
Many people forget to do this check and are left with broken URLs, unnecessary redirects, or worse: links pointing to staging.
✅ Before launching, crawl your site and fix any incorrect references.
Yes, staging is a test environment, but if you do it in a heavy, slow or unoptimized, you can draw wrong conclusions.
A slow staging website can:
Make your tests difficult.
Delay your work.
Not reflecting the actual performance you will have in production.
Conclusion: Staging in an environment similar to your live server, or the tests will not be worth what they should be.
Make a staging without plugins in WordPress It's not an impossible mission reserved for hackers in hoodies.
It is, rather, a clever way of have full control on your website and avoid depending on external tools.
Is it more manual? Yes.
Safer? Also.
More customizable? Of course.
With a well-organized staging:
You can try without fear.
You can making mistakes behind closed doors (which is how you learn best).
You can release updates, redesigns, or changes with the peace of mind of knowing that nothing will explode in your users' faces.
👉 Create your staging with subdomain, file copy and new database It is a process that takes time, but It saves you trouble later.
👉 Protect it, test thoroughly y migrate with your head They are the keys to ensuring that all your efforts yield results without drama.
So you already know:
Next time you think about updating a plugin, redesigning it, or launching a new feature…
First staging. Then production. Always.
Ready to get started and staging like a pro (without adding 20 plugins to your WordPress)?
🛠️🚀 Do it. Your website—and your future self—will thank you.
Related Entries
