Introduction
When you install WordPress, you get dozens of files and a handful of folders. At first it looks like a lot. In reality, the structure is simple and consistent across every WordPress site, and you only edit a small part of it.
Understanding this structure is one of the most useful things you can learn early. It tells you where your code belongs, which files are safe to touch, and which ones you must never edit.
This article covers:
- The three core folders and what each does
- The important files in the WordPress root
- What lives inside wp-content, where your work happens
- Which files are safe to edit and which are off-limits
If you have a local site running from the previous article, open its app/public folder in your editor and follow along.
The Big Picture
A WordPress installation has three top-level folders and a set of files in the root:
/ (web root)
├── wp-admin/ ← admin dashboard files (do not edit)
├── wp-includes/ ← WordPress core code (do not edit)
├── wp-content/ ← your themes, plugins, uploads (edit here)
├── wp-config.php ← configuration and database credentials
├── index.php ← entry point for every request
├── .htaccess ← Apache rewrite rules (permalinks)
└── ... other wp-*.php core files
The single most important rule: you only work inside wp-content. The other two folders, wp-admin and wp-includes, are WordPress core. WordPress overwrites them on every update, so any change you make there is lost — and a mistake there can break the whole site.
The Three Core Folders
wp-admin: the dashboard
wp-admin contains the files that power the WordPress admin area — the dashboard you see at /wp-admin. Every screen in the admin, from the post editor to user management to settings, is driven by files in this folder.
You never edit wp-admin. It is core code, maintained by WordPress and replaced on every update. As a developer you interact with the admin by adding pages and features through plugins and hooks, not by editing these files.
wp-includes: the engine
wp-includes holds the bulk of WordPress core — the actual engine. This is where the functions, classes, and APIs that make WordPress work live, including:
- The database layer (the wpdb class)
- The hook system (actions and filters)
- WP_Query, the class that fetches content
- The REST API, HTTP API, and most core functions you call
When you call a WordPress function like get_posts() or add_action(), the code that runs lives here. It is worth browsing wp-includes occasionally to read how core works — but never edit it. Like wp-admin, it is overwritten on every update.
wp-content: where you work
wp-content is the one folder you actually edit. It holds everything that is specific to your site rather than to WordPress itself. Crucially, wp-content is persistent — WordPress does not overwrite it during a core update. This is exactly why your code belongs here.
It contains several important subfolders, covered next.
Inside wp-content
themes
wp-content/themes holds your installed themes, one folder per theme. The active theme controls how your site looks. When you build or customise a theme, this is where the files go.
A classic theme folder contains PHP template files like index.php and style.css. A block theme contains a theme.json file and HTML templates. Either way, each theme lives in its own subfolder here.
plugins
wp-content/plugins holds your installed plugins. A plugin can be a single PHP file or a folder containing many files. When you write a plugin, it goes here, and it appears on the Plugins screen in the admin once WordPress detects it.
uploads
wp-content/uploads is the media library on disk. Every image, PDF, or file uploaded through WordPress is stored here, organised into year and month subfolders by default.
You generally do not edit this folder by hand, but you should know it exists — it is what you back up to preserve a site’s media, and it can grow large over time.
mu-plugins (must-use plugins)
wp-content/mu-plugins is an optional folder for “must-use” plugins. WordPress loads any PHP file placed directly here automatically, before regular plugins, and they cannot be deactivated from the admin.
This is useful for code that must always run — for example, critical site-wide configuration on a client site. The folder does not exist by default; you create it when you need it.
A must-use plugin is just a PHP file. For example:
<?php
/**
* Plugin Name: Disable Comments (MU)
*/
add_filter( 'comments_open', '__return_false' );
add_filter( 'pings_open', '__return_false' );
languages
wp-content/languages stores translation files for WordPress core, themes, and plugins. If you build translation-ready products, this is where the compiled translation files end up.
Other folders you may see
Two more folders can appear inside wp-content over time. wp-content/upgrade is a temporary working folder WordPress uses while applying updates; you never touch it. wp-content/cache is created by many caching plugins to store generated pages. Neither exists on a fresh install, and both are safe to ignore as a developer.
Important Files in the Root
Beyond the folders, several files sit in the WordPress root.
wp-config.php
wp-config.php is the configuration file. It holds your database credentials, security keys, and various settings that control how WordPress behaves. It is one of the few root files you legitimately edit, and it is important enough to have its own article next in this cluster.
Because it contains database credentials, wp-config.php is sensitive. Never commit it to a public Git repository.
index.php
The root index.php is the entry point for every front-end request. It is short — it simply loads WordPress and tells it to render the page. You do not edit this file.
.htaccess
.htaccess is an Apache configuration file. WordPress uses it to handle pretty permalinks — turning a URL like /about/ into the right internal request. WordPress can manage this file automatically when you change permalink settings.
On Nginx servers there is no .htaccess; the equivalent rules live in the server configuration instead.
Other wp-*.php files
You will see several other core files in the root, such as wp-load.php, wp-settings.php, wp-blog-header.php, wp-login.php, and wp-cron.php. These are part of the WordPress bootstrap and login process. You do not edit them.
Which Files Can You Safely Edit?
Safe to edit:
- Anything inside wp-content (your themes and plugins)
- wp-config.php, carefully, for configuration
Never edit:
- wp-admin (core, overwritten on update)
- wp-includes (core, overwritten on update)
- The root wp-*.php files and the root index.php
If you ever feel the need to change core behaviour, the answer is almost always a hook in a plugin or theme — not a core edit.
Best Practices
- Keep all your code in wp-content. Themes, plugins, and must-use plugins are the supported places for custom code.
- Never modify core. If you edit wp-admin or wp-includes, your changes vanish on the next update. Use hooks instead.
- Protect wp-config.php. It contains database credentials. Keep it out of public version control.
- Back up wp-content and the database. The wp-content folder plus the database is everything unique about a site.
- Use mu-plugins for must-run code. For site-critical code that should never be accidentally deactivated, a must-use plugin is more reliable than a regular plugin.
A simple .gitignore entry to protect sensitive files:
wp-config.php
wp-content/uploads/
Common Mistakes
Editing core files. The classic beginner mistake is editing wp-includes or wp-admin to change behaviour. Updates overwrite it. Always use a plugin or theme with hooks.
Confusing the root index.php with a theme’s index.php. The root file is core and you leave it alone. The theme file is a template you build. They share a name but serve completely different roles.
Committing wp-config.php to a public repo. This exposes database credentials and security keys. Exclude it with .gitignore, or commit a sanitised sample instead.
Deleting the uploads folder during cleanup. This wipes the media library on disk. Treat uploads as data, not disposable files.
Assuming .htaccess always exists. It only applies to Apache. On Nginx there is no .htaccess.
FAQ
Which WordPress folder do I edit as a developer?
Only wp-content. Your themes go in wp-content/themes and your plugins go in wp-content/plugins. Leave wp-admin and wp-includes alone.
Why should I never edit wp-includes or wp-admin?
They are WordPress core, replaced on every update. Any change you make is lost, and a mistake can break the entire site. Use hooks in a plugin or theme to change behaviour instead.
What is the difference between the root index.php and a theme’s index.php?
The root index.php is a core file that boots WordPress for every request — you never edit it. A theme’s index.php is a template that renders content — you do edit it. They only share a name.
What is the mu-plugins folder?
It holds must-use plugins. WordPress loads any PHP file placed directly in wp-content/mu-plugins automatically, and they cannot be deactivated from the admin. It is useful for site-critical code. The folder does not exist until you create it.
Where are uploaded images stored?
In wp-content/uploads, organised into year and month subfolders by default. This is the media library on disk.
I do not have a .htaccess file. Is something wrong?
Not necessarily. .htaccess is only used on Apache servers. If your environment runs Nginx, there will be no .htaccess; the equivalent rules live in the server configuration.
Conclusion
The WordPress file structure is consistent and easy to reason about once you know the layout:
- wp-admin and wp-includes are core — read them to learn, but never edit them.
- wp-content is yours — themes, plugins, uploads, and must-use plugins all live here.
- wp-config.php holds configuration and credentials, and is one of the few root files you edit.
The guiding principle is simple: build in wp-content, configure in wp-config.php, and change core behaviour with hooks rather than core edits.
Next, we go deep on the most important configuration file in WordPress: wp-config.php and every constant that matters.