What is a GUID?
GUID is an acronym for Globally Unique Identifier. It’s an ID that can be assigned to something which will never change and can always be trusted to point to the same thing.
GUID’s are not unique (excuse the pun) to WordPress. They can be found in almost any type of storage system and can take many forms.
Usually, it’s a large string (32 or more) of alphanumeric random characters and there are plenty of online GUID generators if you need one for your own projects.
Here’s an example:
An example of an app that uses GUIDs is an RSS feed reader. It stores a cache of GUIDs to know whether or not it has already displayed a post, or to mark it as read.
How are WordPress GUID’s Used?
WordPress uses GUIDs in the RSS and ATOM feeds to uniquely identify posts within the feed.
If you have a look at any WordPress feed, you’ll see a GUID line relating to each post in the feed. Take a look at this site’s blog feed for examples and search for “guid”.
Here is an example of the GUID in our RSS feed.
Hang on though – isn’t that a URL? What happened to the random characters we mentioned above?
When WordPress was being put together, the developers decided to use a URL as the GUID.
If you think about it, using a URL is a pretty good choice because all URLs should inherently be unique – that’s the way they are meant to work.
However, you shouldn’t use them as URLs. Just because they look like URLs you have to bear in mind that it’s a unique reference. After all, actual URLs for posts can change.
So what’s happening here?
When a new post is created in WordPress, the very first permalink (URL) of the post is saved as the GUID for that post. That’s locked in stone as the unique reference.
If you go back into that post and change the URL, the GUID does not, and should not, change.
That’s why you can’t use the GUID as the post’s URL, use get_the_permalink() instead.
How Does Moving Sites and Domain Names Affect the GUID?
It’s very common for WordPress websites to move around from host to host, or get merged into another site or move to and from subfolders.
All these situations will mean that the overall URL of the site will change, however, the GUID should not.
If your site has done one of the things above and you look through all your post GUIDs you may see some of the original domain name URLs are being used as GUIDs and not the current URL.
That’s OK. Don’t freak out.
Also, larger business sites usually have a “Development to Staging to Live” migration model with content being created on development and staging sites for migration to production.
In these cases, some of the post GUID’s on the live production server may be for example http://development.local/?p=837 and http://staging.domain.com.au/?p=3456.
Again, that’s OK and here’s why.
Let’s take the example of an RSS feed app.
If you have a user subscribed to the blog feed at mydomain.com.au and the website gets pulled to local development, then staging, where new content is added before being pushed up to local again, the user wouldn’t expect to see all the posts that they had read in the past be highlighted as new again.
That would be damn annoying, especially if it happened regularly.
Headless CMS, App and Systems Integration
Ever since the REST API was merged into the core in version 4.7, WordPress has seen an explosion of being adopted as a headless CMS. What does that mean?
A headless CMS is where you have the back-end, the editing and user role capability part, decoupled from the front-end, the theme and content being displayed.
The REST API allows data to be pulled out from WordPress using simple URL commands by pretty much any app that can call a URL.
This means that content from WordPress can now easily be pulled in to native mobile phone and tablet apps as well as desktop apps.
This is where we see WordPress acting as an editing component of a larger overall system that syndicates content to multiple apps and devices, not being reliant on the WordPress theme rendering it out on a screen itself.
When WordPress is a component in a larger system, it’s basically being used as a content store so the other apps using it’s content need to be able to identify past, current and new content.
If you were to change the GUID in that instance then all hell would break loose and server CPU’s would go into overtime trying to synchronise what it thinks is a shedload of new content.
That would be bad!
You need to be careful if when you move your WordPress site, not to modify those GUIDs.
I have heard a lot of stories, some recently, from people who export their database SQL and do a search and replace for the old domain name to the new domain name in a text editor.
This is bad, very very bad, for lots of different reasons that I’m not going to cover in this article.
Read our How to Move WordPress to Another Server article for more information on this.
In essence, you want to preserve the GUID for posts when moving to a new server with a different domain or folder structure.
There are a couple of good ways to achieve this:
- Use WP Migrate DB (and Pro) – by default they don’t touch the GUID but have an Advanced Options checkbox to override this should you want to.
- Use WP-CLI‘s “search-replace” function with the –skip-columns=guid parameter to preserve all post GUIDs.
So, that’s why you should never change the GUID of WordPress posts.
But, Sometimes, Maybe You Can
There are times when you can and maybe should change the GUID of our WordPress posts.
I know, after all that ranting above about never changing it, why are you now saying you can?
Some people are neat freaks. I am not – ask my wife.
I get that having other domain names in the GUID such as development.local or staging.xyz.com.au may seem a bit odd and perhaps unsettling for some people to see in a production database, so, if your site has never been live, isn’t being used in a larger syndication system or you’re sure there are no connected apps or RSS feed users then…
Sure, go ahead and replace the URL in the GUIDs.
The sun will still come up tomorrow.