Why do my WordPress URLs contain index.php?

Where the index.php form comes from

A pretty permalink like /espresso-guide/ names a file that does not exist. The server has to be told to pass such requests to WordPress's index.php. On Apache that instruction lives in .htaccess and needs the mod_rewrite module; on nginx it is a try_files line in the site configuration.

When that cannot be relied on, WordPress uses PATHINFO permalinks: the request goes to index.php, a file that does exist, and the rest of the path rides along after it. There are two ways a site ends up there:

• At installation. WordPress tries to switch on pretty permalinks automatically. It tests a normal structure first and, if the test request fails, tries the same structure with /index.php in front. If only that one works, it is what you get.
• On the Permalinks screen. When core believes the server has no rewrite support, it adds /index.php to the structures it offers and saves.

So the prefix records what WordPress concluded about your server on that day. Hosts change, and the conclusion is often out of date.

Is it bad for SEO?

Not in the sense of a penalty. Google indexes /index.php/espresso-guide/ like any URL. The drawbacks are practical:

• every address is ten characters longer and looks unfinished to people;
• some caching and security rules written for standard WordPress paths do not match;
• if both forms ever respond, you have two addresses per page.

The reason to fix it is tidiness and consistency, and the fix is cheap because WordPress handles the redirects.

How to remove it

1. Check what the server supports. On Apache, confirm mod_rewrite is enabled and that the site's directory allows .htaccess overrides (AllowOverride All or at least FileInfo). On nginx, confirm the location block contains try_files $uri $uri/ /index.php?$args;. Your host can tell you which server you are on.
2. Go to Settings → Permalinks and choose Post name, or edit the Custom Structure to delete the leading /index.php.
3. Save. On Apache, WordPress writes its rewrite block to .htaccess. If the file is not writable, the screen shows the block for you to paste in by hand.
4. Test a post, a page and a category in a private window. If they return 404, rewriting is still not active; switch back while you sort out the server, so the site keeps working.

A minimal WordPress block in .htaccess looks like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

What happens to the old URLs

You do not need a redirect rule for them. Once the site is no longer using index permalinks, core's canonical redirect strips /index.php/ from any request path and sends a 301 to the clean address:

/index.php/espresso-guide/  →  301  →  /espresso-guide/

That covers links from other sites, bookmarks and everything Google has indexed. It applies as long as the rest of the structure is unchanged. If you also change the structure at the same time, say from day-and-name to post name, the date part still needs its own redirects, as described in changing permalinks without losing SEO. Doing the two changes separately makes each easier to verify.

Afterwards:

• update hard-coded internal links that still contain /index.php/, including menu custom links;
• open your sitemap and confirm the entries use the clean form;
• watch the Page indexing report, where old addresses should settle under "Page with redirect".