Set your permalink structure once, early, and avoid changing it later. Go to Settings → Permalinks in wp-admin and choose Post name (/%postname%/). It's the structure almost every site should use: readable, keyword-friendly, and stable over time. If you're changing an existing structure on a live site, the fix isn't the settings screen, it's what you do before and after you click save.
Why post name is the default choice
WordPress offers several built-in options: plain (?p=123), day and name, month and name, numeric, and post name. Plain and numeric structures expose query strings instead of words, which tells visitors and search engines nothing about the page. Date-based structures bake a publish date into every URL, which is a problem the moment you update an old post and the date looks stale, or you want to move a page's timing without breaking its link.
Post name avoids both problems. The URL is the slug: yourdomain.com/your-post-title. It's short, it's readable, and it doesn't depend on when the content was published. If you want a custom pattern, the settings screen also has a Custom Structure field that accepts tags like %category%, %postname%, and %year% in any order, but for most sites plain post name is the right call and the one to change away from only with a real reason.
Changing permalinks on a live site
Changing the permalink structure rewrites every post and page URL on your site at once. Old links, whether they're bookmarked, linked from other sites, or indexed by Google, will 404 unless you handle the transition. This is exactly the kind of change to test somewhere other than production first. Set up a staging copy, make the permalink change there, and click through your main pages, a few posts, and any category or tag archives to confirm the new URLs resolve the way you expect.
Take a fresh backup right before you flip the switch so you have an exact pre-change restore point. See duplicating a WordPress site safely for how backups and copies relate if you're unsure which you need.
Once you're ready on the live site:
- Go to
Settings → Permalinks. - Select the new structure (or edit the custom structure field).
- Click
Save Changes. WordPress rewrites its internal rules immediately.
Saving on that screen also flushes and regenerates the rewrite rules WordPress uses to map incoming URLs to content. That step alone fixes most "page not found" errors that show up right after a structure change; if pages are still 404ing a few minutes later, revisit Settings → Permalinks and save again to force a second flush.
Redirect the old URLs
Saving the new structure does not create redirects from the old URLs to the new ones. Anyone with an old link, and any search engine with your old URLs indexed, hits a 404 unless you add redirects yourself. For a small site, a redirect plugin (Redirection is a common free option) lets you map old patterns to new ones without editing server config. For larger sites with thousands of URLs, a pattern-based rewrite rule is usually less work than mapping every URL individually.
If your host-level configuration needs changes beyond what a plugin handles, that's server-level .htaccess work, worth doing carefully and testing on staging first, same as the permalink change itself.
Cache after the switch
Once the new URLs are live and redirects are in place, clear your cache so visitors and search engines see the current state instead of stale cached pages built under the old structure. Open wp-admin → LiteSpeed Cache and purge the cache. A cached page can serve old internal links even after the rewrite rules and redirects are correct, so purging closes the loop.
If something breaks
If URLs stop resolving after a change and a second permalink save doesn't fix it, restore your pre-change backup and start again on staging. Open a ticket through the portal if you get stuck sorting out a broken rewrite or a stuck redirect.