Canonical links with Blocs

I’ll take a look at this, but done properly inside Blocs none of this should be needed.

Could you message me the text?

PM’d you for your email address

That’s a nice site! I looked at your example and I do have a question. If you use more than one script that the site generates do you use both open and close tag in each or do you put several choices in one?
Casey

I chained them all together within the same tags

Not to be funny but I bought this up when Clean URL’s first launched and it was deemed ok…It’s not ideal so I’ve not done URL links instead of navigate to page. See here:

https://httpstatus.io - Use this for 301 errors.

Visually it all works correctly and you do arrive at the right place, but it was only when I compared it directly to my RW sites that I saw the 301 difference. In theory 301 redirects do not carry an SEO penalty, but we have unnecessary redirects on every single page and Google is still picking up two pages, hence the canonical issue.

It looks like this is a glitch that needs to be fixed and seems to be down to the way Blocs is linking to pages internally without that end slash. The way you did it no doubt gets around this, however it adds a lot of additional work.

It does, but unfortunately I managed to re-organise my project slightly so I only had 40 urls tops to do instead of 200+. Took 15 minutes tops. I knew it was an issue at the time. I can understand for Norm as it’s new to him, I imagine his expertise isn’t really SEO but hopefully he can pick up on this and find a way to implement the trailing slash at some point. It was an issue for me but I made a workaround for myself.

Thanks for this, I have been using sitechecker heavily to optimise my site. I am getting a persistent critical error that complains that “H1 and Title must match each other”. I have set H1 and SEO Title with the same text but it still persists.

I had assumed “Title” is controlled by “SEO Title” in Blocs, am I wrong about this? Any help appreciated

H1 and Title don’t have to match as far as I know, as long as your main keyword is in there and preferably at the start if possible. Also make sure your changing the SEO Title in Blocs and not the Page Name.

Well it’s flagged by sitechecker, but may be an error on their part, or as you say it might not really matter. Just wondered what outer people are getting back from https://sitechecker.pro/ on this?

Ha - nice one, why didn’t I think of that? :stuck_out_tongue:

Drawback is if any links change they don’t update, so be careful for broken links.

My results:

This is on a page with over 3,000 images, roughly 12,000 words and 43 pages.

1 Like

I need another aspirin after reading that. That’s too much work.

1 Like

The motivation is unreal! Hope Guru still going well for you mate :+1:

Yeah all fine there with Guru. I actually opened a reseller account yesterday and plan on bringing over the first client tomorrow. I have to sort out the packages in cPanel and wondering what allowances to offer, especially for email.

Rebuilding the web design site it turning into a massive challenge. It will be well over 100 pages in the end.

Glad to hear. Reseller package is good, I’m on it too. It’s hard to tie your own website in with clients, I’ve had many late nights and 12+ hour days in the office but you get through it!

I still got the title error - I don’t get it

I even changed the og:title tag to match, but still got the error

Any ideas?

How do you manually exclude specific URLs from the sitemap Scrutiny builds? For example, Scrutiny finds my custom 404 pages, but 404 pages should not be included in a sitemap. Why? Because Sitemaps aid search engine bots in indexing content you want displayed in a search. You don’t want your custom 404 page to appear in a Google search, hence it should be excluded.

Currently, I use Blocs-generated sitemaps. Since I build my English & Japanese pages in two separate documents, the main sitemap.xml used at the root of my domain excludes the /en (English) URLs. I then put a different sitemap.xml at the /en directory root to list out the English pages only, excluding the Japanese. Not sure if this is the best way to do it for SEO, but that’s the way I’ve been doing it for a long time. If anyone has a source to show why doing it that way is bad, I would like to hear from you.

Next…

Canonical is an important topic of consideration seeing Blocs 4.0.0 has added that to Page Settings > SEO…

image

For a long time in Blocs, I have manually added <link rel="canonical" href="https://mysite.com"> in Page Settings > Code > Header. (Where “mysite” is just a dummy example URL.) Blocs 4.0.0 makes it more automatic if you tick that checkbox, but I currently only use a Canonical tag on the top/home page of each of my sites. Since I have Japanese (primary language) & English version pages, I use a “canonical” tag on “https://mysite.com” & “https://mysite.com/en”, for example. Since I do not use a CMS or otherwise use “parameters,” I do not use Canonical on other pages within my site. I then use .htaccess to keep the “www.” out of my URLs and to redirect http to https.

I found this page to be a good resource explaining Canonical. And this page says that Google OK’s Canonical for use on ALL pages on a site, but they also say that such is not necessary (on pages that don’t use parameters).

Lastly…

I’ve been too busy to use Clean URLs or even to study up on them in-depth. From what I understand, enabling Clean URLs would chop off .php or .html at the end of a URL in the browser using… what? Javascript? Again, I don’t use a CMS or parameters, so I don’t see a need to enable that, personally. If someone can argue what it is necessary, I’m all ears.

I’m also a bit confused by what’s written in the Knowledgebase here:

image

/press.html is not the same as /press/ ! The latter is a directory. The former is a web page.

Thanks.

Technically yes, but it doesn’t work that way. Typically a URL that doesn’t specify a file will return an index file.

Hence why /press/ is the same as /press/index.html and is how the clean URLs in this case work.

2 Likes