En alguno de nuestros clientes, nos hemos visto obligados a instalar WordPress en un servidor IIS en la versión 6.0

Esta versión de IIS, no admitía aún el módulo URL Rewrite que permite una configuración fácil del re-direccionamiento.  De haber sido una versión IIS 7.0 o superior, habría sido tan fácil como poner en nuestro fichero web.config en la raiz de nuestra aplicación (la raiz del filesystem que sirva WordPress, siempre que este está instalado en el raiz del dominio) una configuración como esta:

<?xml version="1.0"?>
<configuration>
	<system.webServer>
		<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" />
				</rule>
			</rules>
		</rewrite>
	</system.webServer>
</configuration>

En este tipo de instalaciones, aunque configuremos los permalinks para servir por ejemplo /%post-name%/, no nos dará nuestra página a no ser que escribamos delante de la URL “index.php”, es decir, obliguemos desde la petición real a pasar necesariamente por index.php

Pretty permalinks en WordPress con IIS

Pretty permalinks en WordPress con IIS

Obviamente tener una URL legible es fundamental para una buen posicionamiento, además de hacer nuestras URL más fáciles de recordar, y tener algo como midominio.com/index.php/pagina, aunque no es extremadamente “feo”, pero es francamente mejorable si logramos eliminar “index.php” de la URL.

Así que optamos por hacernos nuestra propia redirección, haciendo uso de un script en PHP, que llamamos wp-404-handler.php y al que dirigimos, desde el panel de control de nuestro hosting con IIS, los errores 404, 404:2 y 404:3

Lo que hace este script es re-escribir la variable REQUEST_URI y PATH_INFO con la URL  que aparece realmente en la barra de dirección, y ejecuta directamente index.php

Este script de WordPress, al usar esas variables de la request para saber qué página debe mostrar, se ocupa con su propio motor de re-escritura de URLs de mostrar el contenido adecuado.

Además, elimina o limpia algún rastro del parámetro pasado por GET que algunos hostings envían con el error 404 al ejecutar la URL específica de este error (midominio.com/miscript404.php?404=/mi-pagina-no-encontrada.html, por ejemplo)

Aquí tenéis el script:

<?php
// Script de ejecución por defecto de WP
$default = 'index.php';

// El nombre de este script que servirá de 404
$thisfile = 'wp-404-handler.php';
$_SERVER['ORIG_PATH_TRANSLATED'] = str_replace($thisfile, $default, $_SERVER['ORIG_PATH_TRANSLATED']);
$_SERVER['SCRIPT_FILENAME'] = str_replace($thisfile, $default, $_SERVER['SCRIPT_FILENAME']);
$_SERVER['ORIG_PATH_INFO'] = str_replace($thisfile, $default, $_SERVER['ORIG_PATH_INFO']);
$_SERVER['SCRIPT_NAME'] = str_replace($thisfile, $default, $_SERVER['SCRIPT_NAME']);
$_SERVER['PHP_SELF'] = str_replace($thisfile, $default, $_SERVER['PHP_SELF']);
$_SERVER['PATH_INFO'] = false;

$qs =& $_SERVER['QUERY_STRING'];
$ru =& $_SERVER['REQUEST_URI'];
$pos = strrpos($qs, '://');
$pos = strpos($qs, '/', $pos + 4);
$_SERVER['URL'] = $ru = substr($qs, $pos);
$qs = trim(stristr($ru, '?'), '?');

// Necesario para WordPress 2.8+
$_SERVER['HTTP_X_ORIGINAL_URL'] = $ru;

// Eliminación de parámetros 404 por GET foreach ( $_GET as $var =--> $val ) {
    if ( substr($var, 0, 3) == '404') {
        if ( strstr($var, '?') ) {
            $newvar = substr($var, strpos($var, '?') + 1);
            $_GET[$newvar] = $val;
        }
        unset($_GET[$var]);
    }
    break;
}
include($default);
?>

Información obtenida de la web:
http://einaregilsson.com/pretty-wordpress-permalinks-on-iis/ y http://ikailo.com/94/url-modrewrite-workaround-iis-60/