After a migration, a site can have every file correctly in place and still misbehave — uploads failing, pages erroring, or the whole site refusing to load — because the file permissions came across wrong. Permissions govern what the server is allowed to do with each file and folder, and a migration between hosts can scramble them. Setting them correctly is a small, often-overlooked step that resolves a surprising share of ‘the files are all there but the site is broken’ problems.

This guide explains setting file permissions after a migration: what file permissions are, the standard safe values for a website, the problems wrong permissions cause, how to set them via FTP or the file manager, the special case of wp-config.php, and the security balance to strike. By the end you will be able to get your migrated site’s permissions right, fixing and preventing the issues that bad permissions cause.

What file permissions are

File permissions are settings on every file and folder on a server that control who is allowed to do what with them — specifically, whether they can be read, written to, or executed. On the web servers most sites run on, permissions are expressed as three-digit numbers (like 644 or 755), where the digits encode the read, write, and execute rights for the owner, the group, and everyone else.

These permissions matter because the web server needs the right level of access to your files to run your site: it must be able to read your code and content to serve pages, and to write to certain folders (like the uploads directory) for features like media uploads to work. If the permissions are too restrictive, the server cannot do what it needs; if they are too loose, the files are unnecessarily exposed to security risk.

So permissions are the access-control layer on your files, and a website needs them set to the right balance — permissive enough for the server to operate, restrictive enough to be secure. A migration can disturb this balance, because permissions do not always transfer cleanly between hosts, which is why checking and setting them is a standard post-migration step. Understanding permissions as ‘what the server is allowed to do with each file’ makes the standard values and their problems easy to grasp.

The standard safe values

For a typical website, there is a well-established standard set of permission values that balances functionality and security, and setting your files to these after a migration is the safe default:

• Folders (directories): 755 — the owner can read, write, and execute (enter) the folder; others can read and enter but not write. This is the standard for directories.
• Files: 644 — the owner can read and write; others can only read. This is the standard for most files.
• wp-config.php: more restrictive — often 640 or 600, since it holds sensitive credentials (covered below).
• Avoid 777: never set files or folders to 777 (writable by everyone), which is a serious security risk, even though it sometimes ‘fixes’ a permission problem by brute force.

These values — 755 for folders, 644 for files — are the conventional safe standard for the vast majority of websites, and applying them after a migration resolves most permission-related issues while keeping the site secure. The one dangerous shortcut to avoid is setting things to 777 to make a problem go away: it does work by giving everyone full access, but it opens a serious security hole, so always use the proper 755/644 values instead. If a specific folder genuinely needs write access for a feature, there are safer ways to grant it than 777.

The problems wrong permissions cause

Wrong permissions after a migration produce a characteristic set of problems that can be confusing because the files are all present — it is their access settings, not their existence, that is wrong. Too-restrictive permissions are the common post-migration issue: if the server cannot read your files, pages error or fail to load; if it cannot write to the uploads folder, media uploads fail; if it cannot access certain files, features break.

Symptoms include internal server errors, a white screen, pages not loading, the inability to upload media or install plugins/themes, or specific features silently failing. Because these look like serious problems, people often assume the migration failed badly, when in fact all the files are fine and only the permissions need correcting — a quick fix once you recognise the cause.

On the other side, too-loose permissions (like 777) do not usually break the site — they let it work — but they create a security vulnerability, exposing files to modification by anyone. So wrong permissions cause either functional breakage (too restrictive) or security exposure (too loose). Recognising that a migrated site which is ‘all there but broken’ may simply have a permissions problem is often the key insight that turns a baffling post-migration failure into a two-minute fix.

How to set permissions via FTP or file manager

Setting permissions is done through the same tools you used to move your files: an FTP client or the host’s file manager, both of which let you view and change the permissions on files and folders. In an FTP client, you typically right-click a file or folder and choose a ‘File Permissions’ or ‘CHMOD’ option, which lets you set the numeric value (like 755 or 644); the file manager has an equivalent permissions option.

To set them efficiently across your whole site, both FTP clients and file managers usually offer a way to apply permissions recursively — setting all folders to 755 and all files to 644 in one operation, rather than changing each individually. The typical approach is to select your site’s root directory and apply 755 to all directories, then 644 to all files, recursively, which sets the standard safe values across the entire site at once.

So you set permissions with your FTP client or file manager’s CHMOD/permissions feature, applying 755 to folders and 644 to files, recursively across the site for efficiency. This is the practical action that corrects scrambled post-migration permissions in one pass. If only a specific folder has a problem, you can set just that one, but applying the standard values site-wide is the reliable way to ensure everything is correct after a migration.

The special case of wp-config.php

One file deserves stricter permissions than the standard 644: wp-config.php, because it contains your database credentials and security keys, making it the most sensitive file in a WordPress installation. Leaving it at the default file permission is acceptable, but tightening it further is good practice, since anyone who could read it would gain your database credentials.

A common recommendation is to set wp-config.php to 640 or even 600, which restricts read access more tightly than 644 — allowing the owner (and the server as needed) to read it while denying broader read access. The exact value that works depends on your host’s server configuration (some setups need the file readable by the web server user, so 640 is often the safe stricter choice), but the principle is to make this one file more restrictive than the rest.

So after setting the standard 755/644 across your site, give wp-config.php extra protection with a tighter permission like 640 or 600, appropriate to your host. This is part of treating wp-config.php as the sensitive credential file it is — a migration involves editing it, so it is the natural moment to also lock down its permissions. Combined with not leaving exposed backup copies of it around, a restrictive permission keeps your most sensitive file protected on the new host.

The security balance

Setting permissions after a migration is fundamentally about striking a balance: permissive enough that the server can run your site properly, restrictive enough that your files are not needlessly exposed. The standard 755-for-folders, 644-for-files pattern (with wp-config.php tighter still) is the well-tested sweet spot that achieves both for the vast majority of sites, which is why it is the recommended default.

The temptation, when a permission problem is causing a functional error, is to loosen permissions aggressively — up to 777 — until the problem disappears. Resist this: 777 makes everything writable by anyone, which does resolve access errors by brute force but at the cost of a serious security vulnerability. The correct fix for a too-restrictive permission is the proper 755/644 value, not maximum openness. If a specific folder truly needs write access, grant it in a controlled way rather than opening everything.

So aim for correct, not maximal, permissions: the standard safe values that let the site work while keeping it secure, never the lazy 777 shortcut. After a migration, applying 755 to folders and 644 to files (with wp-config.php stricter) resolves the functional problems that scrambled permissions cause, prevents the security exposure that loose permissions create, and leaves your site both working and protected on its new host. It is a small, often-forgotten step that quietly resolves a surprising share of post-migration troubles — and gets the security balance right in the process.

FAQs

How do I set file permissions after a migration?

Use your FTP client or the host’s file manager’s CHMOD/permissions feature to apply the standard safe values across your site: 755 for folders (directories) and 644 for files, ideally recursively in one pass from the site root. Give wp-config.php a tighter value like 640 or 600. Never use 777. This corrects the scrambled permissions a migration can cause and resolves most ‘files are all there but the site is broken’ problems.

What are the correct file permissions for a website?

The conventional safe standard is 755 for folders (owner can read/write/enter, others can read and enter) and 644 for files (owner can read/write, others read only). wp-config.php should be stricter (640 or 600) as it holds credentials. Never use 777 (writable by everyone) — it’s a serious security risk even though it can brute-force a permission problem away.

Why is my site broken after migration even though all files are there?

Often it’s a file-permissions problem, not missing files. Too-restrictive permissions stop the server reading your files (pages error or show a white screen) or writing to folders (media uploads fail, plugins won’t install). The files are all present — only their access settings are wrong. Applying the standard 755 (folders) and 644 (files) usually fixes it in one pass.

How do I change file permissions?

Through an FTP client (right-click a file/folder and choose ‘File Permissions’ or ‘CHMOD’ to set the numeric value) or the host’s file manager (which has an equivalent permissions option). Both usually let you apply permissions recursively, so you can set all folders to 755 and all files to 644 across the whole site at once from the root directory — the efficient way to fix them after a migration.

What permissions should wp-config.php have?

Stricter than the standard 644, because it holds your database credentials and security keys. A common recommendation is 640 or 600, restricting read access more tightly while still letting the server read it as needed (640 is often the safe stricter choice, depending on your host’s configuration). Tightening this one file is good practice — treat wp-config.php as the most sensitive file in your install.

Should I use 777 permissions to fix a problem?

No — never. 777 makes a file or folder writable by everyone, which does resolve access errors by brute force but opens a serious security hole. The correct fix for a too-restrictive permission is the proper value (755 for folders, 644 for files), not maximum openness. If a specific folder genuinely needs write access for a feature, grant it in a controlled way rather than setting 777.

The bottom line

Setting file permissions after a migration is a small, frequently overlooked step that resolves a surprising share of ‘all the files are there but the site is broken’ problems, because permissions — the settings controlling whether the server can read, write, or execute each file and folder — do not always transfer cleanly between hosts. When they come across too restrictive, the server cannot read your files or write to folders like the uploads directory, producing internal server errors, white screens, failed media uploads, or features that silently break — all while every file is correctly in place, which is exactly what makes the cause easy to miss. The fix is to apply the conventional safe standard: 755 for folders and 644 for files, set recursively across your whole site in one pass with your FTP client or the host’s file manager, using their CHMOD/permissions feature.

Two refinements complete the job. wp-config.php deserves a stricter value than the standard 644 — typically 640 or 600 — because it holds your database credentials and security keys, making it the most sensitive file in the installation, and a migration (which involves editing it) is the natural moment to lock it down. And the guiding principle throughout is balance, not maximal openness: the standard values are permissive enough for the site to run and restrictive enough to stay secure, so resist the tempting 777 shortcut that brute-forces access errors away at the cost of a serious security hole — the correct fix for a too-restrictive permission is always the proper value, never full openness. Apply 755 to folders, 644 to files, tighten wp-config.php, and avoid 777, and you correct the functional problems scrambled permissions cause while keeping your migrated site both working and protected on its new host.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. After a migration, set file permissions to the safe standard: 755 for folders, 644 for files (applied recursively from the site root via FTP or the file manager’s CHMOD feature), with wp-config.php stricter (640 or 600) since it holds credentials. Wrong permissions break a site whose files are all present — uploads fail, pages error. Never use 777 (a security hole); the correct fix is always the proper value, not maximum openness.