Give your project one URL pattern with the slug in it, and RankMill knows where your posts live on your site. From then on, the writer links each new post to the relevant ones you have already published. You set the pattern once, and you no longer have to hunt down addresses for every post.
This post shows you how to work out the right pattern and what it looks like on a few common setups. It also covers what to check in a new draft so you know the links go somewhere real.
What the URL pattern does
RankMill writes your posts, but it does not host them. They live on your own site, in your repository, your WordPress or your Ghost. So on its own, RankMill knows the post but not the address it ends up at. It cannot tell whether your blog sits under /blog/, under /posts/ or on a subdomain.
The URL pattern fills that gap. It is the address of a post on your site, with the slug as the part that changes. The slug is the short, readable bit that names one post, usually the title in lower case with hyphens between the words.
With the pattern in place, the writer can build the address of each post you have already published. Then it links to the ones that fit what the new post is about.
A few things to know first:
- Only published posts get linked. A topic, a draft or a post waiting on the calendar is not a link target yet.
- Only relevant posts get linked. A post about pricing will not link to one about hiring just because both exist.
- The pattern belongs to the project. A project is one website. If you look after several sites, each one gets its own pattern.
How to work out your pattern
The quickest way is to start from a post that is already live on your site.
- Open a published post on your site in your browser.
- Copy its full address from the address bar.
- Find the slug in it, the part that names this one post.
- Open a second post and compare the two addresses. Everything that stays the same is the fixed part of your pattern. The part that changes is the slug.
- Add the pattern to your project. Keep the fixed part exactly as your site shows it, with the slug as the part that changes.
Step 4 is the one people skip, and it is the one that catches mistakes. If your two addresses differ in more than one place, the slug is not the only thing that changes. Look closer before you go on.
Always copy the full address, not just the path. The start of it matters as much as the end.
Patterns for common setups
Here is how this works on setups you are likely to have. Use these as a guide, then check them against a real post on your own site. Your setup may not match the default.
A blog under a folder
Many sites keep their posts under a folder such as /blog/ or /posts/. A post address looks like this:
https://www.example.com/blog/how-to-price-a-service
The fixed part is https://www.example.com/blog/. The slug is how-to-price-a-service.
A blog on a subdomain
Some sites run the blog on a subdomain of its own:
https://blog.example.com/how-to-price-a-service
Here the fixed part is https://blog.example.com/. Do not swap in your main domain. A link to www.example.com/how-to-price-a-service will not find a post that lives on blog.example.com.
WordPress
WordPress sets post addresses through its permalink setting, under Settings, then Permalinks. If it is set to "Post name", a post address is your site address followed by the slug. If it is set to an option that adds a date or a number, the slug is not the only part that changes from post to post. Check that setting before you write your pattern.
Ghost
By default, Ghost puts posts at the root of the site, with a slash at the end:
https://www.example.com/how-to-price-a-service/
If you have changed Ghost's routes, your posts may live somewhere else. Open a live post and copy its address to be sure.
A blog in a git repository
If your blog lives in a repo next to the site and you publish through GitHub, RankMill writes the post file into the folder where your repo keeps its posts. But the address the post ends up at is decided by how your site is built, not by where the file sits in the repo. Many site generators turn the file name into the slug. Some also add a folder or a section name in front of it.
So do not work the pattern out from the repo. Open the live site and copy a real address.
The small details that break links
Most broken links come from small differences, not big ones. Check these:
- www or no www. Use whichever one your site shows in the address bar.
- https. Copy it exactly as your site serves it.
- The slash at the end. If your site shows posts with a trailing slash, keep it in the pattern. Some sites redirect between the two forms, and some show a missing page.
- Upper and lower case. Keep the fixed part exactly as your site prints it.
Checking the links in a new draft
Once the pattern is set, check the next post the writer finishes before it goes out. It only takes a few minutes, and it tells you whether the pattern is right for every post that comes after.
Open the finished post in RankMill and find its links. For each one, ask:
- Does the address match your pattern? The fixed part should be exactly what your site uses.
- Does it open a real page? Paste the address into your browser. You want the post, not a "page not found".
- Is it the right post? The page should be about what the link text says.
- Does the link text make sense? It should tell a reader what they will find when they click.
If a link is wrong, fix two things. First, the post in front of you: tell the editor agent what to change, or fix the link yourself in the block editor. Second, the pattern on the project, so the next post starts from the right address.
If the draft has no links
That is not always a fault. The writer only links to posts you have already published, and only where one is relevant. A project with no published posts has nothing to link to yet. A post on a subject none of your earlier posts cover may have no links either. That is better than a link that does not fit.
If a link opens a missing page
The usual causes are:
- The fixed part is off: a missing folder, the wrong subdomain, or www where your site has none.
- The slash at the end is there when your site does not use one, or the other way round.
- The post's address was changed on your site after it went out, for example you edited its slug in WordPress. A link built from the pattern points at the old slug, not the new one.
The first two are pattern problems, so fix the pattern. The third is a mismatch between your site and the post, so keep slugs as they are once a post is live.
Why this matters more as your archive grows
With five posts, you could add the links by hand. You remember what you wrote, and you know where it lives.
With fifty, you do not. You forget the post from last spring that covers exactly the question a new post raises. Finding it, copying its address and working it into the right sentence is a small job, and it is the kind of small job that gets skipped.
That is where the pattern earns its place. Each new post is written with your published posts in view, so the links come with the post. You do not keep a list. If your project publishes on a cadence, the links go out with each post just the same.
There is no promise here about search rankings, and RankMill does not track them. The case for internal links is simpler than that. Someone who lands on one of your posts came looking for an answer. A link to a related post you have already written gives them the next answer without a search. The bigger your archive gets, the more of those answers you have to offer, and the less likely you are to remember them all yourself.
So take five minutes, open a live post, copy its address and set the pattern. Then check the links in the next post the writer hands you.