Quick Answer
A WordPress file permissions checklist should confirm that site files are owned by the right account, normal files are not writable by more users than necessary, directories that WordPress must write to are intentionally scoped, wp-config.php gets extra attention, backups exist before permission changes, and dashboard file editing is disabled when it creates more risk than value. The best fit for a small publisher is a conservative review habit: loosen permissions only for a clear operational need, then tighten them again after updates, uploads, or repairs are complete.
File Permissions Decision Matrix
| Area | What to verify | Better operator choice |
|---|---|---|
| Ownership | WordPress files are owned by the correct user or group | Match the hosting model before changing modes |
| Normal files | PHP, theme, plugin, and core files are not broadly writable | Keep write access narrow outside update windows |
| Directories | Uploads, cache, and update paths have only the write access they need | Separate routine uploads from sensitive code paths |
wp-config.php | Configuration file is not left at a casual default | Review ownership and permissions after install or migration |
| Dashboard editors | Theme and plugin file editors are controlled | Disable in-dashboard edits when offline review is safer |
| Updates | Automatic and manual updates can still complete | Fix permission errors without making the whole tree writable |
| Recovery | Backups and rollback notes exist before changes | Treat permission edits as production maintenance |
Who Should Use This Checklist?
Use this checklist when a WordPress publisher sees failed updates, upload errors, unexpected writable-file warnings, broken dashboard editing, a recent host migration, a staging-to-production move, a PHP version change, a hacked-file cleanup, or a manual SFTP repair. It also fits a routine quarterly operations review for small editorial sites that do not have a full platform team.
This is not professional incident-response guidance and it does not claim that Yolkmeet inspected a private server, hosting account, filesystem, dashboard, access log, SFTP session, backup archive, malware scan, or production WordPress install. It is source-derived analysis from WordPress documentation. File permissions vary by host, owner, web server user, deployment method, and managed-hosting controls, so the operator decision is to document the hosting model first and avoid broad permission changes that are copied from generic advice.
Step 1: Identify The Hosting Ownership Model
WordPress file-permission decisions start with ownership, not with a memorized number. WordPress documentation explains that files are often owned by the user's server or FTP account, while some writable paths may need ownership or group ownership that lets WordPress perform required file operations. On shared hosting, ownership by the web server process itself can be a warning sign rather than a goal.
Use this ownership checklist before changing modes:
- [ ] Identify the account that owns the WordPress files.
- [ ] Identify whether PHP runs as the same account, a web server account, or a managed hosting service account.
- [ ] Confirm whether updates are handled by WordPress, the host panel, SFTP, Git deployment, or another release tool.
- [ ] Separate ordinary content uploads from executable theme, plugin, and core files.
- [ ] Note any directories that a cache, backup, image, or security plugin must write to.
- [ ] Confirm whether the site is on shared hosting, VPS, managed WordPress hosting, or containerized infrastructure.
- [ ] Record the current owner/group/mode snapshot before changing anything.
The better choice is to understand the running model before applying a template. A command that is safe on one VPS can break automatic updates on another host, and a setting that makes a support article warning disappear can also make too many files writable.
Step 2: Keep The Default Posture Narrow
The practical WordPress rule is simple: normal files should not be writable by everyone, and writable paths should be intentional. WordPress hardening documentation describes locking permissions down as much as practical, then loosening only when a write operation needs it. The file-permissions documentation also notes that different installations and umask settings can produce different defaults.
Use this baseline review table:
| Path type | Operator question | Decision cue |
|---|---|---|
| WordPress core files | Does WordPress need routine write access outside updates? | Avoid leaving broad write access in place |
| Theme files | Are theme edits deployed intentionally? | Prefer offline edits, staging, or versioned changes |
| Plugin files | Are updates controlled by WordPress or the host? | Keep update flow working without open-ended writes |
| Uploads | Can editors upload media normally? | Allow required media writes without exposing code paths |
| Cache folders | Does the cache plugin need a writable directory? | Scope the writable directory to that plugin need |
.htaccess | Does WordPress need to rewrite permalink rules? | Allow only the access required by the permalink workflow |
wp-config.php | Does this file contain secrets and site constants? | Treat as a sensitive configuration file |
Do not make the entire WordPress tree writable to fix one failed upload, plugin update, or cache write. Fix the narrow path that explains the failure, confirm the update or upload works, and record what changed.
Step 3: Review wp-config.php Separately
The wp-config.php file carries database connection details and important WordPress constants. WordPress documentation calls special attention to this file because it sits at the center of site configuration. For operators, it deserves its own review line instead of being treated as just another PHP file in the root directory.
Use this wp-config.php checklist:
- [ ] Confirm the file exists only where expected for the install.
- [ ] Confirm it is owned by the intended server or deployment account.
- [ ] Confirm it is not world-writable.
- [ ] Confirm secrets are not copied into public notes, screenshots, or article drafts.
- [ ] Confirm temporary migration constants have been removed after the migration.
- [ ] Confirm update-related constants match the site's maintenance policy.
- [ ] Confirm editor-control constants are deliberate, documented, and not stale.
- [ ] Back up the file before changing permissions or constants.
This is where file permissions connect to publishing operations. A content site may run smoothly for months and then fail after a migration because wp-config.php, .htaccess, or the uploads directory inherited ownership from the wrong account. Review the sensitive file first, then the writable paths.
Step 4: Decide How Dashboard File Editing Should Work
WordPress documentation describes in-dashboard theme and plugin file editing as immediate, live file editing. That can be useful for emergency work, but it is a poor default workflow for a small publisher that wants source-aware, reversible changes. WordPress also documents constants that can disable the plugin and theme file editor, and a broader constant that blocks plugin and theme installation or update modification from the admin area.
Use this decision table:
| Site condition | Dashboard file editor decision | Reason |
|---|---|---|
| Solo publisher with no staging site | Disable editor | Live edits are hard to review and easy to break |
| Managed host handles updates | Usually disable editor | Host tooling should own code changes |
| Git or SFTP deployment exists | Disable editor | Versioned changes are easier to recover |
| Temporary emergency fix | Enable only if necessary | Record the edit and close the window afterward |
| Multi-author editorial site | Disable editor | Editorial users should not have code-editing paths |
The best fit for Yolkmeet-style operator content is not "never edit files." It is "do not make production file editing the normal publishing workflow." Edit offline, keep backups, test when possible, and avoid solving a permissions warning by giving the dashboard more write access than the site needs.
Step 5: Make Updates Work Without Opening Everything
Failed updates are one of the most common reasons operators touch permissions. WordPress upgrade documentation emphasizes backups before updates and distinguishes manual update flows from automatic update behavior. Hardening documentation also describes automatic update file operations in terms of the file owner, with normal files and directories set in a conservative pattern.
Use this update repair checklist:
- [ ] Back up the database.
- [ ] Back up WordPress files, including
.htaccessandwp-config.php. - [ ] Confirm whether the host, WordPress dashboard, WP-CLI, SFTP, or Git normally performs updates.
- [ ] Reproduce the failed update or permission warning only as far as needed to identify the path.
- [ ] Check whether the failure is in core, plugin, theme, uploads, cache, or temporary upgrade directories.
- [ ] Fix ownership or group membership before increasing mode values broadly.
- [ ] Avoid recursive permission changes unless the scope and impact are understood.
- [ ] Rerun the update, then tighten any temporary write access.
- [ ] Record the changed path, reason, timestamp, and rollback step.
The better operator choice is to keep updates boring. If WordPress cannot write where it genuinely needs to write, repair that path. If everything is writable by the web server just to avoid one update failure, the site has traded an operational problem for a security and recovery problem.
Step 6: Keep Uploads And Code Paths Separate
Most editorial teams need routine media uploads. They do not need routine browser-based modification of executable PHP files. This distinction matters because wp-content/uploads has a different operational role from theme files, plugin files, core files, and wp-config.php.
Use this separation checklist:
- [ ] Media uploads work for the roles that need them.
- [ ] Upload directories are not used as an informal place to store scripts.
- [ ] Cache and optimization plugins have clearly named writable directories.
- [ ] Backup plugin output is not publicly browsable.
- [ ] Plugin and theme directories are not opened broadly to solve media-upload errors.
- [ ] Manual SFTP uploads go through a known account and folder.
- [ ] Old repair files, zip archives, and temporary PHP files are removed after maintenance.
This keeps the site easier to reason about. A publisher should be able to say which paths are writable for editorial content, which paths are writable for caching or backups, and which paths should change only during a controlled update.
Step 7: Build A Small Audit Log
File-permission work is easy to forget because it often happens under pressure. A small audit log turns a one-off fix into an operator process. The log does not need to expose sensitive account names or paths in public content. It should be useful to the site owner, future maintainer, or hosting support contact.
Use this audit-log template:
| Field | Example of what to record |
|---|---|
| Date | Date the permission review happened |
| Trigger | Failed update, migration, upload error, quarterly review |
| Path group | Core, plugin, theme, uploads, cache, root config |
| Symptom | Permission denied, writable warning, failed upload |
| Change | Ownership, group, mode, host-panel setting, disabled editor |
| Evidence | Screenshot, host ticket, command output, dashboard warning |
| Rollback | Restore backup, revert owner/group, remove temporary file |
| Follow-up | Recheck after update, host migration, plugin change |
This article intentionally does not include command recipes because command safety depends on host ownership, filesystem layout, and access model. A future version can add host-specific examples only if the article includes matching evidence and keeps the claims scoped to that environment.
What Should A WordPress File Permissions Checklist Include?
A complete WordPress file permissions checklist should include ownership review, ordinary file mode review, writable directory scoping, wp-config.php hardening, dashboard file-editor decisions, update repair workflow, backup confirmation, uploads/code separation, temporary-file cleanup, and an audit log for each change. The best fit for most small publishers is to make only the narrow permission change required for the operational task, then verify updates, uploads, backups, and dashboard access still work.
Common Questions
Should every WordPress file permission issue be fixed with a recursive command?
No. Recursive permission changes are high blast-radius maintenance. Start by identifying the specific path, owner, group, and workflow that failed. Use broad commands only when the host documentation, deployment model, and rollback path are clear.
Is a writable file always a security problem?
Not always. WordPress needs write access for some operations, such as uploads, cache files, and updates depending on the hosting model. The issue is unnecessary write access. A directory that must be writable for media uploads is different from making all plugin, theme, and core files broadly writable.
Should small publishers disable the WordPress theme and plugin file editor?
Usually yes. If edits can be made offline, through staging, SFTP, Git, or host tooling, disabling the dashboard file editor reduces the chance of instant production mistakes. The decision is especially strong on multi-user editorial sites.
Why does wp-config.php need a separate review?
It contains sensitive configuration details and site-level constants. A casual permission change on this file can create more risk than a normal content-editing issue. Back it up and review it separately after installs, migrations, recovery work, and update-policy changes.
What should be checked after changing permissions?
Check login, media upload, plugin/theme update flow, cache behavior, permalink behavior if .htaccess is involved, backups, and the specific error that triggered the change. Then remove temporary files and record what changed.
Source Notes
- https://developer.wordpress.org/advanced-administration/server/file-permissions/ checked 2026-06-10; used for source-derived analysis of WordPress file ownership, writable files, shared-hosting cautions, permission variation by install, and the special need to review
wp-config.php. - https://developer.wordpress.org/advanced-administration/security/hardening/ checked 2026-06-10; used for source-derived analysis of limiting writable files, loosening permissions only when needed, and automatic update file-operation behavior.
- https://developer.wordpress.org/advanced-administration/wordpress/wp-config/ checked 2026-06-10; used for source-derived analysis of
wp-config.phpas a sensitive configuration file and constants for file editing, file modifications, and update policy. - https://developer.wordpress.org/advanced-administration/wordpress/edit-files/ checked 2026-06-10; used for source-derived analysis of live dashboard file editing, backup-before-editing guidance, file-editor risk, and offline editing preference.
- https://developer.wordpress.org/advanced-administration/upgrade/upgrading/ checked 2026-06-10; used for source-derived analysis of update preparation, backing up files and database, and manual upgrade considerations.
- https://developer.wordpress.org/advanced-administration/upgrade/ftp/ checked 2026-06-10; used for source-derived analysis of SFTP/FTP and host file-manager workflows for manual file operations.
- https://developer.wordpress.org/advanced-administration/security/backup/ checked 2026-06-10; used for source-derived analysis of backing up WordPress files and database before file maintenance.
No private hosting dashboard, SFTP session, SSH command, WP-CLI output, WordPress admin screen, file listing, backup archive, malware scan, server log, Search Console property, AdSense account, production browser session, or managed-host support ticket was inspected for this article. If a future operator adds host-specific commands, screenshots, or file-mode evidence, attach those artifacts and narrow the article to that verified environment.
Internal Link Notes
Link to wordpress-security-checklist-for-blogs when readers need the broader access, backup, WAF, and monitoring baseline. Link to wordpress-plugin-update-checklist when permission changes are triggered by plugin maintenance. Link to wordpress-php-version-upgrade-checklist when a runtime upgrade changes file ownership or deployment behavior. Link to wordpress-debug-log-checklist when permission errors appear in logs. Link to wordpress-backup-restore-checklist before any broad file-maintenance change.
Update Note
Review this checklist every 60 days. Recheck WordPress Advanced Administration documentation for file permissions, hardening, wp-config.php, editing files, upgrading, FTP/SFTP workflows, and backups. Refresh earlier after a host migration, ownership change, managed-host tooling change, WordPress core release, plugin update failure, PHP version upgrade, backup workflow change, hacked-file cleanup, or dashboard file-editor policy change.