Perma­links are the per­ma­nent URLs to your indi­vid­ual weblog posts, as well as cat­e­gories and other lists of weblog post­ings. A perma­link is what another weblog­ger will use to link to your arti­cle (or sec­tion), or how you might send a link to your story in an e-mail mes­sage. The URL to each post should be per­ma­nent, and never change — hence permalink.

Perma­link Types

There are three basic types of Word­Press permalinks:

Default: “Ugly”

The default looks like

http://example.com/?p=N

where N is the Post ID num­ber. It works on all server envi­ron­ments, but it doesn’t look as nice as some of the other options.

mod_rewrite: “Pretty Permalinks”

Using mod_rewrite or lighttpd you can pro­duce much nicer perma­links (see Pretty Perma­links). There are many dif­fer­ent for­mats, but the most com­mon, and most ver­sa­tile looks like

    http://example.com/category/post-name/
or  http://example.com/year/month/day/post-name

Some peo­ple elim­i­nate some or all of the date ele­ments (day, month, year) to have a shorter perma­link format.

Pretty perma­links are avail­able under

• Apache web server with the mod_rewrite module
• Microsoft IIS 7+ web server with the URL Rewrite 1.1+ mod­ule and PHP 5 run­ning as FastCGI
• pos­si­bly Microsoft IIS 6+ using a 404 han­dler or Mod-Rewrite Pro
• Lighttpd using a 404 han­dler or mod_rewrite or mod_magnet (see Exter­nal sources)

PATHINFO: “Almost Pretty”

PATHINFO perma­links look very much like mod_rewrite perma­links but for one excep­tion: they have /index.php inserted before them, like so:

http://example.com/index.php/yyyy/mm/dd/post-name/

Oth­er­wise, they are the same as the “pretty” mod_rewrite perma­links, and are sim­i­larly flex­i­ble. Any­thing that mod_rewrite perma­links can do, PATHINFO perma­links can do, with the help of that /index.php part.

There is a help­ful plu­gin that dis­plays the type of perma­links being used and detailed infor­ma­tion on the inter­nal rewrite rules used by WordPress.

Choos­ing your perma­link structure

In the Set­tings → Perma­links panel (Options → Perma­links before Word­Press 2.5), you can choose one of the “com­mon” struc­tures or enter your own in the “Cus­tom struc­ture” field using the struc­ture tags.

To acti­vate PATHINFO perma­links, start your perma­link struc­ture with index.php/.

Struc­ture Tags

You can use these tags to cus­tomize your “Pretty” or “Almost Pretty” perma­links. A few hints:

• Make sure to end your struc­ture with either %post_id% or %post­name% (e.g. /%year%/%monthnum%/%day%/%postname%/) so that each perma­link points to an indi­vid­ual post.
• For per­for­mance rea­sons, it is not a good idea to start your perma­link struc­ture with the cat­e­gory, tag, author, or post­name fields. The rea­son is that these are text fields, and using them at the begin­ning of your perma­link struc­ture it takes more time for Word­Press to dis­tin­guish your Post URLs from Page URLs (which always use the text “page slug” as the URL), and to com­pen­sate, Word­Press stores a lot of extra infor­ma­tion in its data­base (so much that sites with lots of Pages have expe­ri­enced dif­fi­cul­ties). So, it is best to start your perma­link struc­ture with a numeric field, such as the year or post ID. See wp-testers dis­cus­sion of this topic.

%year%

The year of the post, four dig­its, for exam­ple 2004

%mon­th­num%

Month of the year, for exam­ple 05

%day%

Day of the month, for exam­ple 28

%hour%

Hour of the day, for exam­ple 15

%minute%

Minute of the hour, for exam­ple 43

%sec­ond%

Sec­ond of the minute, for exam­ple 33

%post­name%

A san­i­tized ver­sion of the title of the post (post slug field on Edit Post/Page panel). So “This Is A Great Post!” becomes this-is-a-great-post in the URI (see Using only %post­name%). Start­ing Perma­links with %post­name% is strongly not rec­om­mended for per­for­mance rea­sons.. *** Note — this has been changed and is ok to do since ver. 2.0

%post_id%

The unique ID # of the post, for exam­ple 423

%cat­e­gory%

A san­i­tized ver­sion of the cat­e­gory name (cat­e­gory slug field on New/Edit Cat­e­gory panel). Nested sub-categories appear as nested direc­to­ries in the URI. Start­ing Perma­links with %cat­e­gory% is strongly not rec­om­mended for per­for­mance rea­sons.

%tag%

A san­i­tized ver­sion of the tag name (tag slug field on New/Edit Tag panel). Start­ing Perma­links with %tag% is strongly not rec­om­mended for per­for­mance rea­sons.

%author%

A san­i­tized ver­sion of the author name.

Cat­e­gory base and Tag base

The Cat­e­gory base and Tag base are pre­fixes used in URLs for cat­e­gory and tag archives, which look like this:

 example.net/wp/category_base/category_name
 example.net/wp/tag_base/tag_name

The default val­ues for these are cat­e­gory and tag. You can change them, but you can’t remove them from the URLs altogether.

Cus­tom perma­links work on most sys­tems with­out any prob­lems, but there are still some con­di­tions where prob­lems occur.

Using only %post­name%

If using ver­sion 2.0 or greater, the fol­low­ing is no longer true as this has been changed.

If you use post­name as the only ele­ment in your perma­links to cre­ate a struc­ture such as example.com/post-title, the rewrite rules may make it impos­si­ble to access pages such as your stylesheet (which has a sim­i­lar for­mat) or the /wp-admin/ folder . It’s best to include some numeric data (e.g. the post ID or date) in the perma­link to pre­vent this from hap­pen­ing. Addi­tion­ally, Word­Press v1.2.x requires the use of a date struc­ture in order for some fea­tures, such as the cal­en­dar, to func­tion prop­erly. /%year%/%monthnum%/%day%/%postname%/ is always a good start.

You can get past the above issue and con­tinue using %post­name% if you make a sim­ple change to your .htac­cess file as below:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_FILENAME} ^wp-content.*
RewriteCond %{REQUEST_FILENAME} ^wp-admin.*
RewriteCond %{REQUEST_FILENAME} ^wp-include.*
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Sim­ply the con­di­tions now say do not apply the rule if the file name includes the word press con­tent, admin or include direc­tory. This now allows you to get to the admin area with no issues as well as content.

Using %cat­e­gory% with mul­ti­ple cat­e­gories on a post, or %tag%

When you assign mul­ti­ple cat­e­gories to a post, only one can show up in the perma­link. This will be the low­est num­bered cat­e­gory (see Man­age Cat­e­gories). The post will still be acces­si­ble through all the cat­e­gories as normal.

The same thing applies to using the %tag% field in your perma­link structure.

Using “Pretty” permalinks

Require­ments:

• Apache web server with the mod_rewrite mod­ule installed
• In WordPress’s home directory,
  • The Fol­lowSym­Links option enabled
  • File­Info direc­tives allowed (e.g. AllowOverride FileInfo or AllowOverride All)
  • An .htac­cess file (if this file is miss­ing, Word­Press will try to cre­ate it when you acti­vate “pretty” permalinks)
  • If you want Word­Press to update the .htac­cess file auto­mat­i­cally, Word­Press will need write access to the file.

• For lighttpd, see Exter­nal Resources.

When you cre­ate or update a “pretty” perma­link struc­ture, Word­Press will gen­er­ate rewrite rules and attempt to insert them into the proper .htac­cess file. If it can’t, it will say some­thing like You should update your .htac­cess now and print out the rules for you to copy and paste into the file (put them at the end).

In Word­Press 2.0+ ver­sions, you’ll prob­a­bly need to do this only once, because Word­Press does the rewrit­ing inter­nally. If you ever move your Word­Press home direc­tory (Blog address), you’ll need to repeat this step.

Word­Press will play nice with an exist­ing .htac­cess and will not delete any exist­ing RewriteRules or other direc­tives. If you have other mod_rewrite rules, put yours before WordPress’s.

Where’s my .htac­cess file?

Wordpress’s index.php and .htac­cess files should be together in the direc­tory indi­cated by the Blog address (URI) set­ting on your Gen­eral Options page. Since the name of the file begins with a dot, the file may not be vis­i­ble through an FTP client unless you change the pref­er­ences of the FTP tool to show all files, includ­ing the hid­den files. Some hosts (e.g. Godaddy) may not show or allow you to edit .htac­cess if you install Word­Press through the Godaddy Host­ing Con­nec­tion installation.

Cre­at­ing and edit­ing (.htac­cess)

If you do not already have a .htac­cess file, cre­ate one. If you have shell or ssh access to the server, a sim­ple touch .htaccess com­mand will cre­ate the file. If you are using FTP to trans­fer files, cre­ate a file on your local com­puter, call it 1.htaccess, upload it to the root of your Word­Press folder, and then rename it to .htac­cess.

You can edit the .htac­cess file by FTP, shell, or (pos­si­bly) your host’s con­trol panel.

If your .htac­cess file con­tains errors that bring down your site (“Inter­nal Server Error (500)”), you will need to use FTP or your host’s con­trol panel to delete the rogue .htac­cess file.

Auto­mat­i­cally updat­ing .htac­cess

If Word­Press can’t update your .htac­cess file auto­mat­i­cally, it will tell you some­thing like If your .htac­cess file were writable, we could do this auto­mat­i­cally, but it isn’t… near the bot­tom of the Set­tings → Perma­links panel.

If you want to let Word­Press do this, you’ll need to give Word­Press write access to the .htac­cess file. The exact per­mis­sions nec­es­sary depend on your server setup. Try adding write per­mis­sions for the owner, then group, then world, test­ing after each change; once Word­Press has edited the file suc­cess­fully, don’t add any fur­ther write permissions.

After apply­ing the perma­links, you should change the per­mis­sions to some­thing stronger like 660 or 644 to pre­vent oth­ers on the server from poten­tially hav­ing access to it.

Perma­links with­out mod_rewrite

“Pretty” perma­links usu­ally require mod_rewrite, and IIS (com­mon on Win­dows servers) does not sup­port mod_rewrite. (If you are using Apache 2.0.54, on Win­dows, mod_rewrite may work, pro­vided it is enabled in apache\conf\httpd.conf.)

If you are using IIS 7 and have admin rights on your server, you can use Microsoft’s URL Rewrite Mod­ule instead. Though not com­pletely com­pat­i­ble with mod_rewrite, it does sup­port WordPress’s pretty perma­links. Once installed, open the web.config file in the Word­Press folder and add the fol­low­ing rule to the system.webServer element

<rewrite>
    <rules>
        <rule name="Main Rule" stopProcessing="true">
            <match url=".*" />
            <conditions logicalGrouping="MatchAll">
                <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
                <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
            </conditions>
            <action type="Rewrite" url="index.php/{R:0}" />
        </rule>
    </rules>
</rewrite>

There’s a full instal­la­tion guide on the IIS site. The mod­ule is avail­able for x64 and x86 systems.

If this isn’t an option, you can try PATHINFO perma­links; put index.php/ at the start of your cus­tom perma­link structure:

 /index.php/%year%/%monthnum%/%day%/%postname%/

This option may not always work, espe­cially in cases of Word­Press run­ning on IIS 6. To make this option work on IIS, add these 2 lines to a php.ini file and store that file in your web­root (http://blog.taragana.com/index.php/archive/wordpress-tip-on-permalink-options):

 cgi.fix_pathinfo = 1
 cgi.force_redirect = 0

Another solu­tion exists using IIS’ cus­tom 404 redi­rects. It requires that your web host allows you to add a cus­tom 404 redi­rect, but it doesn’t require you to install any 3^rd party mod_rewrite soft­ware and it also doesn’t require that your perma­link struc­ture begin with /index.php/.

• http://www.keyboardface.com/IIS-Permalinks/
• Another very sim­ple cus­tom 404 redi­rect solu­tion: http://tech.einaregilsson.com/2007/07/30/pretty-wordpress-permalinks-on-iis/
• A newer ver­sion of the above solu­tion: http://www.ikailo.com/94/url-modrewrite-workaround-iis-60/

If you have admin­is­tra­tor priv­i­leges on your server, you may be inter­ested in these solutions:

• Word­Press URL Rewrite Plu­gin for blogs run­ning on IIS by Binary Fortress Software
• URL Rewrit­ing for Word­Press under IIS by Dean Lee

Fix­ing Perma­link Problems

Fix­ing .htac­cess Gen­er­a­tion Issues

If your instal­la­tion of Word­Press does not gen­er­ate a .htac­cess file or if it does not write the new rules onto your exist­ing .htac­cess file then there are a cou­ple rea­sons that could be caus­ing this. Work step by step and con­tinue to the next step only if the pre­vi­ous step does not work.

1. Change File Per­mis­sions: You must chmod the .htac­cess file to 666 to edit it with the Word­Press tem­plate edi­tor, but this is not rec­om­mended, since if you do that, any user of your blog, who can edit tem­plates will be able to edit it. You can change the per­mis­sions to 660 to make it server-writable, which again will have the same limitation.
2. Server Block­age: Your host might have blocked the SERVER_SOFTWARE vari­able and this will cause Word­Press’ .htac­cess gen­er­a­tion to fail. If you are sure that your server is run­ning Apache, you can force Word­Press to believe that your server is run­ning Apache by chang­ing your wp-includes/vars.php file. Fol­low the steps below to imple­ment these changes.
   • Open the wp-includes/vars.php file using the built in file edi­tor in your Word­Press Admin panel. To nav­i­gate to this panel, login to Word­Press, click on “Man­age”, then on “Files”, scroll to the bot­tom and type in wp-includes/vars.php into the text box under the “Other Files” title.

   Look for

   $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;

   and replace it with

   // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;

   • Add a new line under

     // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;

     and type in

     $is_apache = 1;

3. Users of XAMPP (Win­dows): Some ver­sions of XAMPP do not enable mod_rewrite by default (though it is com­piled in Apache). To enable it — and thus enable Word­Press to write the .htac­cess file needed to cre­ate pretty perma­links — you must open apache/conf/httpd.conf and uncom­ment the line Load­Mod­ule rewrite_module modules/mod_rewrite.so (i.e., delete the hash/pound sign at the front of the line).

Perma­links, .htac­cess, and MS Frontpage

A note about Microsoft Front­page: many servers (shared and ded­i­cated) main­tained and built by var­i­ous host­ing com­pa­nies come with mod_frontpage com­piled with the apache build, and in many cases with the Front­page Server Exten­sions installed, on each vir­tual server. This is more com­mon than not, many/most binary dis­tri­b­u­tions used in the server build process at most host­ing com­pa­nies these days include both mod_fronpage and the server exten­sions. Even if you’re not using Front­page, because of the way that the exten­sions inter­act with apache (and the httpd.conf file) you’ll likely get some­thing like a 500 error or blank white page when try­ing to view your WP install (although the admin panel may oper­ate cor­rectly) sim­ply because extensions/mod_frontpage exist on your server.

Word­press will oper­ate cor­rectly with the Front­page Exten­sions installed, how­ever perma­links will not func­tion at all and ANY change to the perma­links sec­tion from the Word­press admin inter­face will cause cor­rup­tion of the Front­page server exten­sions due to the addi­tion of the mod_rewrite rules to the .htac­cess file. There is how­ever now a fix for this situation.

Quick Fixes, Front­page or Permalinks

Front­page Exten­sions Fix: If you don’t care about perma­links and just want to make the MS Front­page server exten­sions work again, sim­ply edit your .htac­cess file and remove the Word­Press sec­tion with the rewrite rules.

To Use Perma­links: If you don’t care about Frontpage(but your host­ing com­pany has the exten­sions installed)

You will need to remove (or have your host­ing com­pany do so) the MS Front­page server exten­sions, or sim­ply edit the .htac­cess file to removed all of the Front­page Lines, leav­ing only the Word­Press mod_rewrite code.

Using Front­Page AND Perma­links Together

Finally, A solution.

There have been a num­ber of threads on this issue in the sup­port forums, and until now, no solu­tion to the problem.

Nor­mally, on a Unix server with the Microsoft Front­Page Server exten­sions installed Word­Press works just fine and you are able to edit and pub­lish pages (with Microsoft Front­Page) — until — you make a change to the perma­links (for exam­ple to the date based kind that I like /2005/04/etc). I often sug­gest that type of URI to folks ask­ing about perma­links etc, as that is the method rec­om­mended by the w3c (see http://www.w3.org/Provider/Style/URI ).

Now, the prob­lem is that Front­Page uses the .htac­cess file (which the Word­Press mod_rewrite rules must access) for its “pub­lish­ing” and “web author­ing” con­fig­u­ra­tion. As soon as the Word­Press mod_rewrite code is added to the file, two things hap­pen — the perma­links don’t work and the Front­page Server exten­sions become corrupt.

I have tried count­less ways to get around this, includ­ing try­ing to use rewrite rules that “ignore” the %{HTTP_USERAGENT)% used by Front­Page, to using a sec­ond Access­File­name .wpac­cess to the httpd.conf file, and a host of other things, and noth­ing worked to allow use of Front­Page and man­age­ment and use of perma­links in Word­Press at the same time.

The solu­tion is actu­ally sim­ple, and I fig­ured it out by accident.

If you are using, or wish to use Front­Page (or if your host­ing pack­age is pre-configured that way) along with Word­Press, you’ll need to take the fol­low­ing sim­ple steps on your server or have your host­ing com­pany do them for you.

Microsoft Front­Page cre­ates the fol­low­ing directory

_vti_bin

Nested within that it cre­ates both

_vti_adm

and

_vti_aut

In addi­tion to in your site (or Word­Press) root folder in all of those direc­to­ries you will find addi­tional .htac­cess files.

In all three of these direc­to­ries AND in the root direc­tory, at the top of ALL of the .htac­cess files you sim­ply need to add one line:

Options +FollowSymlinks

There may or may not already be a line in each like

Options None

Edit and save each .htac­cess file and you’re done. Now every­thing works per­fectly, includ­ing Front­Page, AND the perma­links of your choosing.

Long Permalinks

When using extra long perma­links in email and post­ing in com­ments and chats, some long perma­links are “chopped off” or only the first sec­tion is actu­ally rec­og­nized as a link and the end seen as text. Here is an example.

Can result in:

To click on the lower link, the user would get a 404 Page Not Found Error. If you have a ten­dency to use very long perma­link post titles, take these steps to pre­vent this problem.

1. Check that you are indeed using Perma­links.

2. Edit your .htac­cess file and add the following:

 RewriteRule ^post/([0-9]+)?/?([0-9]+)?/?$ /index.php?p=$1&page=$2 [QSA]

3. Test it. Find a post’s ID num­ber and type the fol­low­ing (with your infor­ma­tion) in your browser and you should be redi­rected to your post:

http://yourdomain.example.com/post/(the ID #)

It is also worth not­ing that most email soft­ware will not cut off URLs that have been delin­eated with angle-brackets (< and >), so when past­ing URLs into emails, you should write them as so:

Addi­tion­ally, some decent email clients offer a “pre­for­mat” option when com­pos­ing plain-text emails. Using the “pre­for­mat” option when past­ing links will force the email client not to insert line­breaks inside the links.

Fix­ing Other Issues

If your .htac­cess file is being gen­er­ated cor­rectly, but Perma­links still do not func­tion, the fol­low­ing might be a prob­lem. If prob­lems per­sist, post a note in the Word­Press Forum’s How To section.

AllowOver­ride Not Enabled

Your server may not have the AllowOver­ride direc­tive enabled. If the AllowOver­ride direc­tive is set to None in your Apache httpd.config file, then .htac­cess files are com­pletely ignored. In this case, the server will not even attempt to read .htac­cess files in the filesys­tem. When this direc­tive is set to All, then any direc­tive which has the .htac­cess Con­text is allowed in .htac­cess files. Exam­ple of enabled AllowOver­ride direc­tive in httpd.config:

 <Directory />
    Options FollowSymLinks
    AllowOverride All
 </Directory>

You may also have to enable the AllowOver­ride direc­tive in your DocumentRoot:

 <Directory /var/www/html>
    # ... other directives...
    AllowOverride All
 </Directory>

You may also have to change the AllowOver­ride set­tings for the site. This is surely the case when using Mac OS X Server, but might be like­wise with other sys­tems. Usu­ally you can find the site con­fig­u­ra­tion files in /etc/httpd/sites/

If you don’t want to set AllowOver­ride to all (as it is above) then your AllowOver­ride list must include the File­Info direc­tive. You must restart your Apache server for any httpd.config file changes to take effect. For more infor­ma­tion on which over­rides are allowed, read about Apache Core Fea­tures.

Paged Nav­i­ga­tion Doesn’t Work

Some­times nav­i­ga­tion to sec­ond (and sub­se­quent) pages of posts does not work as expected. Your page may gen­er­ate a link to a page with one of these URIs:

 http://www.example.com/page/2/

http://www.example.name/category/categoryname/page/2/

http://www.example/year/month/day/page/2/

http://www.example/year/month/page/2/

The result of click­ing one of those links is that the page loads with all the sur­round­ings (header, footer, side­bar), but instead of a page of posts, there is an error mes­sage: “Sorry, no posts match that criteria.”

This is due to a glitch in the .htac­cess file that Word­Press gen­er­ates. To fix it, delete the con­tents of your .htac­cess file and re-create it.

1. In the Con­trol Panel, go to Man­age > Files (More Info on Edit­ing Files)
2. Click the link to your .htac­cess file to edit its contents
3. Copy the con­tents of the file and paste it to a text file in a text edi­tor. This is a pre­cau­tion in case your .htac­cess file has man­ual entries for redi­rects, denials or other handy htac­cess tricks
4. Delete all con­tents from your .htac­cess file and click the Update File button.
5. In the Con­trol Panel, go to Options > Permalinks.
6. Click the Update Perma­link Struc­ture but­ton to freshly gen­er­ate new rewrite rules for your permalinks.
7. Test the results using a link that had pre­vi­ously broken.
8. Add any man­ual htac­cess entries back in your file (Place man­ual htac­cess entries before the # BEGIN Word­Press or after # END Word­Press lines.)

You may also per­form sim­i­lar steps by delet­ing the .htac­cess files from the server, cre­at­ing a fresh empty .htac­cess file, chang­ing its per­mis­sions to 666, and then in Options > Perma­links gen­er­ate a new set of htac­cess rules by click­ing the Update Perma­links Struc­ture button.

If that still doesn’t work, take a look at the Word­Press sup­port forums, specif­i­cally, this sup­port post.

Perma­links to pages don’t work

If you’ve tried to nav­i­gate to a newly cre­ated Page and encounter an error, you likely need to update your Perma­link struc­ture. Remem­ber, each time you add a new sta­tic Page to Word­Press, new rules must be gen­er­ated and updated to .htac­cess (Word­Press 1.X) or to the inter­nal rewrites array (Word­Press 2.X).

Perma­links to Ulti­mate Tag War­rior tag pages don’t work

If you get 404 errors on local tag URLs when using the Ulti­mate­Tag­War­rior plu­gin on Word­Press 2.X, it’s because the inter­nal rewrites gen­er­ated by Word­Press are being overly greedy and get­ting invoked before UTW’s rewrite rules have a chance. This usu­ally occurs only when using a cus­tom perma­link struc­ture (like /%postname%/). To fix it, either switch your Perma­link struc­ture to “Date and name based” or hack the UTW plu­gin to place the UTW rewrites at the top of the inter­nal rewrites array. More Info on this.

Perma­links work but no pages are returned

Some ver­sions of PHP 4.4.x and 5.x have a bug that causes mod_rewrite to fail when used with some ver­sions of Apache 2.x. More details at http://bugs.php.net/bug.php?id=35096 and http://bugs.php.net/bug.php?id=35059.

More Help

If these steps do not work, search for your prob­lem in the Codex, Trou­bleshoot­ing, or in the Sup­port Forum. As a last resort, file a bug report.

Tips and Tricks

If you want to list your site in Google News, one of the require­ments is to have at least three digit iden­ti­fier at the end of every url.

This is eas­ily accom­plished using %postname%-%post_id% struc­ture, which will append post ID to the end of URL so it becomes http://mysite.com/cooking-tips-tricks-344.

Hav­ing your posts end in .html

There’s an easy way to hav­ing your posts end in a .html exten­sion, using the struc­ture tags above. Fol­low­ing the exam­ple used on prop­erly ter­mi­nat­ing perma­links, you could have a page like http://yoursite.com/2006/01/01/happy-newyear.html with this rule:

 /%year%/%monthnum%/%day%/%postname%.html

Note that this does not gen­er­ate sta­tic .html files. It only adds the .html exten­sion, pages are still being dynam­i­cally gen­er­ated. The SEO ben­e­fit to this is debat­able, but it can be use­ful should you need to migrate away from Word­Press, since the pages can eas­ily be made sta­tic and retain their URL structure.

Word­Press ver­sions prior to 2.3 lacked canon­i­cal URLs, mak­ing .html some­thing very ben­e­fi­cial to add (forc­ing the URL to be canon­i­cal). Now it only pro­vides lim­ited, if any SEO ben­e­fits (see Exter­nal Resources for fur­ther analysis).

Avoid­ing inter­pre­ta­tion as an archive link

Note that even though one might never make more than one post­ing a day, and thus wishes to use e.g., %year%%monthnum%%day%, links so gen­er­ated will how­ever be inter­preted as the archive of all posts for that day. One needs at least %year%%monthnum%%day%%hour% to tar­get an indi­vid­ual post.

Check for perma­link structure

A way to check if the blog has a perma­link struc­ture is:

if ( get_option('permalink_structure') != '' ) { echo 'permalinks enabled' }

See Also

• Link­ing Posts Pages and Cat­e­gories for how to link from one arti­cle to another