The reliable way to create WordPress’s default .htaccess rules is to have WordPress generate them: sign in to the dashboard, open Settings > Permalinks, choose any structure other than the default/plain option, and select Save Changes. When an Apache server can write the file, WordPress creates or updates the rules automatically. If it cannot write the file, the same screen displays the rules so you can copy them into .htaccess yourself.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
This procedure applies to a standard, single-site WordPress installation on Apache. IIS uses a different configuration file, and WordPress multisite does not perform this automatic write.
As an Amazon Associate I earn from qualifying purchases.
Free tools Windows power users keep installed
One-click scans. No signup required.
What the WordPress default .htaccess file is for
.htaccess is an Apache configuration file that lets a site apply directory-level rewrite instructions without changing the server’s main configuration. WordPress uses it to turn human-readable (“pretty”) URLs into requests that its front controller can process.
The WordPress-managed section is enclosed by two comment markers:
#1 Best Overall
# BEGIN WordPress# END WordPress
Only the content between those markers is considered WordPress’s generated block. Saving the Permalinks screen can replace that block, so custom directives should be kept outside it. The file may also contain unrelated rules supplied by your host, a security tool, a caching system, or your own configuration.
There is no single timeless block that should be copied from an old tutorial. The generated text can change between WordPress releases, installation paths, and server setups. The safest source is the rules shown by your own Permalinks screen at the time you generate the file.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchCheck these requirements before generating it
- Web server: The automatic method described here is for Apache with the
mod_rewritemodule available. WordPress’s rewrite function writes an ApacheIfModulewrapper around its rules. - File access: You need WordPress administrator access and, for a manual fallback, access to the site’s document root through your host’s file manager, SFTP, or another server-management method.
- Correct site location: A root installation normally has
.htaccessin the directory containingwp-admin,wp-content, andwp-includes. A subdirectory installation needs the file and generated path rules in that subdirectory’s document root. - Pretty permalinks: A non-default permalink structure must be selected. With the default/plain structure, WordPress has no pretty-permalink rewrite set to insert.
- Backup: If a file already exists, download or copy it before changing anything. It may contain important host or application rules that are not part of WordPress’s block.
If the server is IIS rather than Apache, this process is not the right repair. IIS uses web.config routing instead of Apache’s .htaccess mechanism.
Method A: let the WordPress dashboard create the file
This is the preferred method because WordPress builds the rules for the current permalink setting and installation path.
- Sign in to the WordPress administrator area. Use an account that can change site settings.
- Open Settings > Permalinks. This page displays the site’s current URL structure and the save control.
- Select a structure other than the default/plain option. A date-based, post-name, numeric, or custom pretty structure all cause WordPress to prepare rewrite rules. The exact choice is a site-architecture decision; changing it on an established site can alter URLs, so do not change it casually just to create the file.
- Select Save Changes. WordPress flushes the rewrite rules and calls its core rewrite-writing routine. If the file exists and is writable, the generated block is written to it. If it does not exist, WordPress attempts to create it when pretty permalinks are activated.
- Read the message displayed after saving. A successful write normally returns you to the Permalinks screen without asking you to paste anything. If WordPress cannot write the file, it presents a notice and a text box containing the rules for your current configuration.
What a successful save changes
The operation does not create a generic text file somewhere in the hosting account. It updates the .htaccess file in the document root associated with this WordPress installation and replaces only the section between the WordPress markers. Existing content outside those markers is left for other rules and applications.
In a subdirectory installation, the generated base and final rewrite target include that path. Therefore, a block copied from a root installation is not interchangeable with one generated for a site installed under a folder.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Why selecting the default/plain structure matters
The default/plain permalink option does not require the same front-controller rewrite setup. If it remains selected, WordPress may not insert the pretty-permalink block even though you repeatedly save the page. Choose a non-default structure first, save it, and then inspect the result.
Method B: copy the rules when WordPress cannot write the file
Shared hosting permissions, an absent file, a read-only directory, or local development restrictions can prevent the dashboard from writing .htaccess. In that case, the Permalinks screen is still the authoritative source for the block.
- Save the selected pretty structure and wait for the warning. WordPress may use wording such as “You should update your .htaccess now.” The important part is the text area containing the generated rules.
- Copy the entire text area. Include both
# BEGIN WordPressand# END WordPress. Do not copy only the rewrite lines in the middle and do not add formatting characters. - Locate the correct document root. It is the directory served for this domain and normally the one containing the WordPress core folders. If WordPress is installed in a subdirectory, use that installation’s directory rather than the parent account directory.
- Create or open a file named exactly
.htaccess. The leading dot is part of the filename, and there is no additional extension such as.txt. If a file already exists, preserve a backup before replacing or merging anything. - Paste the copied block as plain text. Keep the marker lines intact. If the existing file contains non-WordPress directives, leave them outside the markers; do not delete them merely to make the WordPress block fit.
- Save and upload the file. A permission mode of
644is commonly recommended by WordPress developers, but it is a convention rather than a universal WordPress requirement. Your host may impose a different safe setting. - Return to Settings > Permalinks and select Save Changes once more. This refreshes WordPress’s rewrite state. If it still reports that the file is not writable, the rules can remain in the manually saved file while the permission issue is handled with the host.
Creating a dot-file on a local Windows installation
Some Windows tools do not make it easy to create a filename that begins with a dot. If a graphical editor rejects .htaccess, create the file with a server-aware editor or file manager that supports dot-files, or create it under a temporary name and rename it after uploading. Verify that the final name is exactly .htaccess, not .htaccess.txt.
Rank #4
What the generated WordPress block does
The exact text depends on the WordPress version and installation path, so use the current block on your own screen rather than reproducing a historical snippet. Its functions are consistent:
Recommended Free Tools
- Enables URL rewriting: The block turns on Apache’s rewrite processing for the directory.
- Sets the base path: A
RewriteBasevalue reflects whether the site is at the domain root or in a subdirectory. - Leaves real resources alone: Conditions test whether the requested path is an existing file or directory, commonly using
%{REQUEST_FILENAME} !-fand%{REQUEST_FILENAME} !-d. Existing assets are not sent through WordPress’s index handler. - Routes other requests to WordPress: Requests that are not real files or directories are directed to
index.php, where WordPress resolves the post, page, archive, or other route. - May exclude
index.phpexplicitly: Newer WordPress-generated blocks can include a rule that prevents the front controller from being rewritten to itself. This is another reason not to paste a block copied from an old article.
These directives are written inside an Apache module guard. If the required rewrite module is unavailable, the block cannot provide working pretty permalinks; changing the text alone does not install or enable the module.
Keep custom rules outside the WordPress markers
WordPress regenerates the marked section whenever rewrite settings are saved. A custom redirect, access rule, or application-specific directive placed inside that section can disappear without warning. Put custom directives before # BEGIN WordPress or after # END WordPress, according to the order required by the rule and your host’s guidance.
Best Value
Keep a dated backup before adding custom directives. A useful backup lets you restore the previous file if a typo causes a server error or an unexpected redirect. After every edit, test the home page, an existing post, a page, and a static asset.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Apache, IIS, subdirectories, and multisite
| Environment | What to expect | Action |
|---|---|---|
| Apache, single site, root installation | WordPress can generate an Apache .htaccess block when the file exists and is writable, or can attempt to create it. |
Use Settings > Permalinks, select a pretty structure, and save. |
| Apache, single site, subdirectory installation | The generated base path and rewrite target include the installation directory. | Copy the block generated for that installation; do not substitute a root-site block. |
| Apache, file not writable | The dashboard shows the rules but cannot save them. | Copy the complete text area into the document-root .htaccess file and address permissions with the host if necessary. |
| IIS | Apache mod_rewrite and .htaccess are not the routing mechanism. |
Use the IIS/web.config configuration appropriate to that server; this procedure does not generate it. |
| WordPress multisite | The automatic write routine does not run for multisite; its return value is null according to the developer reference. | Follow the network’s server-specific multisite rewrite instructions and edit the server configuration with appropriate access. |
Troubleshoot a missing or ineffective file
| Symptom | Likely explanation | What to do |
|---|---|---|
| No file appears after saving | The selected structure is still default/plain, the directory is not writable, or the file was created in the wrong document root. | Select a non-default structure, save again, inspect the dashboard message, and verify the domain’s actual document root. |
| The screen says “You should update your .htaccess now” | WordPress generated the rules but lacks permission to write them. | Copy the complete displayed block into .htaccess; keep a backup of any existing content. |
| Pretty URLs return 404 errors | The block is absent or malformed, Apache rewriting is unavailable, or the file is not being read from the served directory. | Regenerate from the Permalinks screen, confirm the file location and spelling, and ask the host whether mod_rewrite is enabled and allowed. |
| Saving permalinks removes custom directives | The directives were placed between the WordPress markers. | Restore the backup, move custom rules before the begin marker or after the end marker, and save again. |
| A previously working site changes behavior after a rewrite save | The old file may have contained host or application rules outside the generated block, or the permalink structure changed. | Compare the backup with the current file, restore non-WordPress directives, and keep the established permalink structure unless a URL migration is planned. |
| A local tool refuses the filename | The tool does not support leading-dot filenames or silently appends .txt. |
Use a dot-file-capable editor or file manager, then verify the exact filename on the server. |
When renaming the existing file helps
Support technicians often use a controlled regeneration when rules appear stale: download the current .htaccess as a backup, rename the server copy so Apache no longer reads it, and select Save Changes on the Permalinks screen. WordPress can then create a fresh file if the directory permits it. This is not a substitute for preserving unrelated directives. Restore or merge those directives outside the WordPress block after the fresh file is working.
Verify the result without guessing
- Open the site’s document root and confirm that the file is named exactly
.htaccess. - Open it as plain text and check for both WordPress marker lines.
- Confirm that any non-WordPress rules remain outside those markers.
- Visit the home page, one post, one page, and a known static file in a private browser window.
- Return to Settings > Permalinks and save once more only if the file is writable and you need WordPress to refresh its rules.
- If URLs still fail, determine whether the server is Apache and whether
mod_rewriteis enabled before changing the generated text.
Common mistakes to avoid
- Pasting an archived snippet: A 2011 Codex example is not a guarantee of the block used by a current WordPress release.
- Leaving the default/plain structure selected: That setting does not ask WordPress to create pretty-permalink rewrites.
- Saving in the account home directory: The file must be in the document root that serves this WordPress site.
- Using the wrong installation path: A root-site block can break routing for a subdirectory installation, and vice versa.
- Deleting the whole existing file: Rules outside the WordPress markers may belong to other applications or the host.
- Editing inside the markers: A later Permalinks save can overwrite those edits.
- Expecting Apache rules on IIS: IIS requires its own configuration format.
- Assuming multisite behaves like single-site WordPress: The automatic write path does not run for multisite.
Bottom line
For a normal Apache single-site installation, create the default WordPress .htaccess by selecting a pretty permalink structure at Settings > Permalinks and saving. Let WordPress write the marked block when it can; otherwise copy the complete block shown on that screen into the correct document-root file. Keep custom rules outside the markers, preserve backups, and use the block generated for your current version and installation path rather than an old copied example.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
