Here are the original articles if you want to start at the beginning

WordPress For The Enterprise – Article 1 – Setting The Mood
WordPress For The Enterprise – Article 2 – Issues And Plugins
WordPress For The Enterprise – Article 3 – Implementation Problems
WordPress For The Enterprise – Article 4 – Upgrading

Some of what I am going to discuss in this article has to do with small details which occurred after the implementation and continue to happen.  These small details are important because they are some of those gotchas after a big migration.  They are just listed here in random order:

301 Redirects On Additional Domains

Let’s say you own about 10 other domains that you have pointed to the same web site as your base site.  This would be like having http://www.strategicpoints.com and then having http://www.internetanalysistools.com and then pointing internetanalysistools.com to strategicpoints.com.  It just happens that on additional domains, WordPress should take care of this for you.  Just set the DNS to point to the same server and make sure the apache conf (in Linux is set) and you are good to go.  The second domain should hit the site and switch over to the real site.  This also works the same way for www.strategicpoints.com and strategicpoints.com.  Set it to one in wordpress admin and it will always redirect to the other.  This is important for the search engines to have one domain for the site to avoid duplication and getting crawled incorrectly on the secondary domains.

Nofollow Meta Tags Left On (kind of like your headlights left on)

Just happened that prior to our migration, we set the dev and QA sites to not be indexed by the search engines.  This setting is under Settings/Privacy.  It is called Blog Visibility, and the exact wording is “I would like to block search engines, but allow normal visitors”.  We had these Dev and QA sites set this way, so that we would not get these sites indexed.  However, somehow this template theme was transferred to the components of our enterprise production system which are not WordPress sites.  This means that we copied the template as is, and it had the follow Meta tag because of this setting:

<meta name="robots" content="noindex,nofollow" />

In particular we ended up leaving this in production on these non WordPress sites.  It was an oversight, and one we immediately fixed.  But this just says that even after you do your QA and job and the best you can, there is still a potential problem that you are not aware of in these environments.  So you  have to be vigilant and look things over periodically.

I am going to keep adding to this article as issues slowly bubble to the surface on the enterprise wordpress implementations we have been through.

To solve this problem, there are several places to look, including Google and doing a site:YOURWEBSITENAME.com search and clicking on every link to using Google Analytics.  The Google Analytics method is the best, since it automatically tells you what needs to be fixed.  This does not mean you should ignore the google search engine and looking at what are big incoming links in advance.  Remember once you find a broken link, and you are using the WordPress Redirection Plugin, I highly recommended in a previous blog entry (click here to learn more info), you need to enter the entry into Redirection and fix it.  If you are just learning that this did not require an .htaccess entry in Linux or htapi entry in windows, you are learning about a whole new world of improvement…

So back to Google Analytics.  First of all you need to have a 404 page, which is where all the pages end up when they find no entry in WordPress, including the redirection plugin.  This typically will be a 404.php page in the theme directory you are using.  If you are sending people to your site map page, that is fine as well. 

There are several ways to get this info in google analytics.  I recommend using page title.  For instance, on our site, the page title of our 404 page is called “Page Not Found”.  Go into Google Analytics and click on “Content” and then on “Content by Title”.  If you have just migrated, and the first day has passed, just set the date to the current day, to remove anything that is older than today, and find the “Page Not Found” (or other) title.  If you click on this title name itself, another screen will open and reveal all the URLs that arrive at that page.  This is your list of incoming broken links, sorted by the most important links at the top of the list.

Now is the detailed nitty gritty work.  You need to re-enter each of these links into a url to test them and make sure they are broken.  Once you are have found one that is being clicked on from a website out yonger, take it, copy it into the redirection plugin.  You do this by Adding a new Redirection, then copying the link into the Source URL.  Remember to not use your full path, just the /filedirectoryetc/ path, and then go over to another browser and find the end URL you want to send the visitor to and then copy and paste this path into Target URL and click Add Redirection.  The default is a Permanent 301 redirect. 

There are a lot of other options in the redirection program like using Regular Expressions.  These work fine as well, but make sure you read the instructions carefully, since some redirections are impacted by other redirections…sequentially.

Let me know if you have any comments are questions about this process, because almost all sites come to point of migration, and this blog entry is really about the aftermath of a big migration.  Our last WordPress migration did go through, but it had lots of small items that we had to fix along the way.  I am going to add another blog entry covering these additional problems we ran into, creating a load balanced WordPress Enterprise solution!