When i setup pretty url it seems to change the way google indexes my blog, it there a way to set canonicals for each individual post page to be indexed when using pretty urls? Or am i better off not using the pretty url in that case?
Alloy generates canonical meta data for each individual blog post. We’ll use the Foundry blog itself, which also uses Pretty URLs. Here’ an example blog post for us to inspect:
If you look at the <head> of this page you’ll find a canonical tag there with the Pretty URL for that post, as it should be:
<link rel="canonical" href="https://foundry.elixirgraphics.com/blog/three-new-stacks-add-ons-a-new-elixir-website-and-more">
Here’s a screenshot of it on the page:
If you’d like to share a link to your blog I can have a loot at one of the individual blog posts, but if you’ve set everything up correctly, it should also be generating a canonical for each individual blog post, like in the example above.
Cheers mate, ill have a look through and try and work out what is going on.
Here is an example of what is happening
pretty url and canonical showing correctly as you’ve mentioned.
unfortunately google has indexed these and the canonical shows as /page
I’m away from the computer for the evening and on my phone so the best I can do is look at the URL. That said the link you provided is not to a Pretty URL. Not sure if you have things configured incorrectly, you provided the incorrect URL or something else.
If you want to take a second look over everything and make sure you’ve configured things correctly you might catch a mistake that’s been made. You might also double check the tutorials videos. If you don’t find anything then provide your project file and I can take a look tomorrow.
Create a ZIP file containing your project file. This is the file you open in RapidWeaver to edit your site. After creating the ZIP file, upload it using a service like Dropbox, WeTransfer, Droplr, or a similar service to create download link for us. Paste that download link in your reply.
It also wouldn’t hurt to have a copy your posts folder on hand too.
The first one is a pretty url the 2nd one is the non pretty url thats duplicated.
imperiallocksmiths.com.au/page/ata-ptx4-ptx5-garagegate-remote-programming
imperiallocksmiths.com.au/page/?id=ata-ptx4-ptx5-garagegate-remote-programming
Ah gotcha. Yes you will always have access to the post via its id= url. That is actually how the pretty URL a knows where to go, so it is necessary. That is its permanent home so to speak. The pretty URL is an htaccess rewrite rule. Think of it as a kind of redirect that makes it easier to type, find and navigate to posts.
Do you have any idea how i can rewrite the canonical for the id= version? Thats the one google seems to be indexing and its canonical is for the main blog page not the individual blog post page.
I’ll take a look at it when I get to the office today. Perhaps it is a bug. If so it would need to be fixed and tested and released in the next Alloy update.
@Imperial So after looking over the code it looks like when I wrote the canonical generation bit I must have been in a Pretty URL frame of mind and wrote it toward that end. Should be able to address this with an update to Alloy.
glad you found the issue. Look forward to the update. Cheers
If you check for updates within the Stacks addon, at the base of the Library pane, you should find Alloy v3.2.1 ready for updating. After updating quit and restart RapidWeaver. This ensures That everything is in place after Stacks has updated the Alloy files. After restarting RapidWeaver load your project and do a “Republish All Files” from within RapidWeaver.
3 Likes
… and I always thought it had to be that way 
thank you for the update!
2 Likes
Thanks for the update.
After this update, ?id= theres essentially a duplicate page of every post, is it possible to rewrite the canonical to point to the pretty url?
If not then it looks like it would be better not to use pretty urls.
The canonical URL is created when the page is loaded. If you visit the pretty URL page that page’s URL is used for the canonical. If you visit the non-pretty URL then that URL is used for the canonical. It, along with the rest of the blog related content is dynamic and generated at page load.
I can look at it further to see if there’s a better way to approach it in the code, but it will unfortunately be a little while before I can do so as I have to finish up the other large project I’m working on first, unless I find some time to squeeze this in as well.
BTW: if you should take the time to update again, is it possible that you can fix the following at the same time?
if you have activated the “pretty url” it would be nice if this is also transmitted the pretty url in the RSS feed? i think this would make it a little easier for google to understand the structure of the page and the “correct” pretty url will be indexed …
but please do not stress … the large project is of course more important. when does it come out? 
thank you again for your support.
1 Like
The RSS feed would need to wait until a major update of Alloy I suspect.
No announced date yet. 
@Imperial — So it looks like there’s a possibility that I could make the canonical always be the Pretty URL when Pretty URLs are enabled, but it would take making a change in the way the “Pretty URLs for Blog Posts” checkbox works within the Alloy Control Center settings. In doing so though when users updated to the new Alloy version with that change it would turn Pretty URLs off for everyone who has them enabled currently.
This is due to the fact that I’d be changing the checkbox’s scope to be a page-wide variable, and thus the Stacks API thinks it is a new variable and resets it. This is not an acceptable outcome unfortunately as it would cause a lot of problems for a large number of users.
Alternatively I could add a new checkbox for enabling this feature separate from the “Pretty URLs for Blog Posts” checkbox, but this comes with a downside as well. Users could enable this checkbox, even if Pretty URLs are off, and would then create problems for them. This second option is the lesser of two evils, but honestly, not ideal either.
As with all things in life there are limits. The limitation here comes from how I have to interact with the Stacks API.
Would like to know your thoughts and any thoughts others might also have.
hello!
i understand and can comprehend why you do not want to implement the first solution. although it would probably be the best one.
the second variant (new checkbox) is then probably the more charming solution of the both and would prefer this.