How to Fix: Secure file permissions

Secure file permissions is a medium-priority check in the Security & Trust category. It is filed under SEO because a hacked site is an unranked site — nothing tanks visibility faster than a malware flag in search results. This one is quiet housekeeping that prevents a very loud problem.

What this check is really about

Every file and folder on your server carries permissions that decide who can read, write and execute it. Set them too loose and any process — including an attacker who finds a foothold through a vulnerable plugin — can rewrite your files, inject code, or read secrets. This check fails when permissions are more permissive than they should be. The classic offender is 777 on a directory: full read, write and execute for absolutely everyone, usually set by someone in a hurry to “fix” an upload error.

The numbers that should be true

WordPress has sensible, well-documented defaults, and most sites should match them:

• Files: 644 — owner can write, everyone else reads only.
• Directories: 755 — owner can write, others traverse and read.
• wp-config.php: 640 or 600 — this file holds your database credentials and secret keys; lock it down harder than the rest.
• Nothing at 777, ever. If something only works at 777, the real problem is file ownership, not permissions.

How I’d fix it in WordPress

Difficulty Level: MEDIUM – This fix requires some technical knowledge or familiarity with WordPress settings and plugins.

Estimated Time: 20 min

1. Check current permissions over SFTP or SSH, or with a security plugin that reports them. Look for anything at 777 or a world-writable wp-config.php first.
2. Reset to the defaults — 644 for files, 755 for directories — and tighten wp-config.php to 640 or 600.
3. If uploads or a plugin genuinely need write access, solve it with correct file ownership (the web server user owning the files), not by loosening permissions for the whole world.
4. Re-run the audit, and confirm the site still functions — uploads, plugin updates, media — after the change.

777 is a symptom, not a fix

Almost every dangerous permission I have found got there the same way: someone hit a “cannot write to directory” error, searched it, and the top answer said “try chmod 777.” It made the error go away, so it looked like a fix. It was not. It was papering over an ownership problem by handing write access to every process on the server, and it stays there for years because nothing visibly breaks.

When a directory refuses to accept writes, the correct question is who owns it, not how to open it to everyone. On a properly configured host the web server user owns the WordPress files and 755 is plenty. If you find yourself reaching for 777, stop and talk to your host about ownership instead — and if you have already got 777 anywhere from a past emergency, this check is your reminder to go back and undo it.

Tools I actually reach for

• Yoast SEO – Comprehensive SEO plugin with built-in checks
• Rank Math – Feature-rich SEO plugin with detailed analysis
• Google Search Console – Free tool to monitor your site’s search presence
• SEO Roadmap – Complete SEO audit and action plan tool

Where people go wrong

• Using chmod 777 to clear a write error instead of fixing file ownership.
• Leaving wp-config.php at the same loose permission as ordinary files.
• Changing permissions on production with no backup and no test of uploads and updates afterward.
• Assuming the host set safe defaults without ever checking.

This guide is part of the SEO Roadmap knowledge base – your complete resource for WordPress SEO optimization.