Duplicate without user-selected canonical – OJS indexing issue (Google Search Console)

serunjogid · March 23, 2026, 2:13pm

Hello everyone,

I am currently experiencing a site-level indexing issue with my OJS journal website. In Google Search Console, I keep receiving the error:

“Duplicate without user-selected canonical”

Google attempted to validate fixes, but some pages are still affected.

From my checks:

The server is not blocking Googlebot (no 403 or robots.txt issues)
Some pages are indexed, but others are excluded due to this canonical issue
The problem appears to be related to how OJS generates or handles canonical URLs and duplicate content (possibly issue URLs, article URLs, or query parameters)

My questions:

How does OJS handle canonical tags by default?
Are there recommended settings or plugins to fix duplicate URL issues in OJS?
Has anyone experienced this with article/issue pages and successfully resolved it?

I would appreciate guidance on how to properly fix this so that all pages can be indexed correctly.

Thank you in advance for your support.

asmecher · March 25, 2026, 2:53pm

Hi @serunjogid,

What URLs is the search console claiming are duplicates? (Feel free to obscure the domain name etc; I just need to see the pattern of URLs that OJS uses.)

Regards,
Alec Smecher
Public Knowledge Project Team

serunjogid · March 28, 2026, 9:34am

Thank you for the reply @asmecher ,

The domain is sjhresearchafrica.org

Previously all its content was covered in Google scholar, this is not happening recently. I do not know why.

For Duplicate without user-selected canonical. These pages aren’t indexed or served on Google. They are a total of 7.87k. Examples are below;

https://sjhresearchafrica.org/index.php/public-html

https://sjhresearchafrica.org/index.php/public-html/article/view/2476/2205

https://sjhresearchafrica.org/index.php/public-html/article/view/1400?articlesBySameAuthorPage=3

https://www.sjhresearchafrica.org/index.php/public-html/citationstylelanguage/get/modern-language-association?submissionId=1244&publicationId=1246

https://sjhresearchafrica.org/plugins/generic/pdfJsViewer/pdf.js/web/viewer.html?file=https%3A%2F%2Fsjhresearchafrica.org%2Findex.php%2Fpublic-html%2Farticle%2Fdownload%2F1121%2F834%2F4187

https://sjhresearchafrica.org/plugins/generic/pdfJsViewer/pdf.js/web/viewer.html?file=https%3A%2F%2Fsjhresearchafrica.org%2Findex.php%2Fpublic-html%2Farticle%2Fdownload%2F133%2F131%2F807

https://www.sjhresearchafrica.org/index.php/public-html/article/view/1650

https://sjhresearchafrica.org/plugins/generic/pdfJsViewer/pdf.js/web/viewer.html?file=https%3A%2F%2Fsjhresearchafrica.org%2Findex.php%2Fpublic-html%2Farticle%2Fdownload%2F939%2F719%2F3728

https://www.sjhresearchafrica.org/index.php/public-html/article/view/1523

https://www.sjhresearchafrica.org/index.php/public-html/article/view/1813?articlesBySimilarityPage=1

and many others;

I will wait to hear from you.

Thank you so much.

mpbraendle · March 28, 2026, 12:10pm

Hi,
only the …/article/view/… pages are important for indexing. Don’t bother about the other pages.

You can indicate to Google what is the canonical page by adding the following lines to your plugins/generic/googleScholar/GoogleScholarPlugin.php . Add them just before the return statement of the public function submissionView (around line 222) :

        # CHIMIA CHANGE CHIMIA-19 2022/03/05/mb add canonical URL
        $templateMgr->addHeader('googleCanonicalUrl', '<link rel="canonical" href="' . $request->url(null, $submissionPath, 'view', array($submission->getBestId())) . '"/>');
        # END CHIMIA CHANGE CHIMIA-19

asmecher · April 6, 2026, 3:00pm

This topic was automatically closed after 12 days. New replies are no longer allowed.

marc · April 13, 2026, 8:01am

Do you mind to talk about this a bit more to see if we can find a general solution instead of a patch?

As far as I know, we have at least two ways to access the article URL (article/view/<article_id> vs. article/view/<url_path>).

It could become three if restful_urls are used (someday we should rename them to clean_urls :-P)… or even more if the site has mod_rewrite rules.

What I’m trying to say is that this isn’t a one-off problem but a widespread one that we’ve been ignoring for years, and I believe it affects the search engine rankings of all OJS/OMP/OPS systems.

Given this scenario, don’t you think it would be a good idea to add the canonical URL to the HTML header of the articles so that Google is happy and SEO improves as a result? It doesn’t seem like a complicated development, and it certainly won’t do any harm… I think.

Any SEO expert in the room could confirm this approach is ok?

If you think it’s a good idea, I’ll post this idea as an issue on GitHub to document the problem, and if I find the time, I’ll try to draft a PR.

What do you think?

dagosalas · April 14, 2026, 3:47pm

Hi @marc ,

The problem is that Google Search Console identifies all possible URLs for an article; of those, it might index the “view” URL, but it marks the rest as non-indexable URLs because it doesn’t identify the canonical URL, and that’s the error mentioned in the post.

This happens a lot with languages; if you have four languages, you’ll have four duplicate URLs (according to Google).

So, what it’s asking you to do is specify which is the canonical URL.

I think it’s a good idea to define the canonical URL according to the language defined in the journal and pointing to the abstract and not the galleys.

Cheers!

marc · April 15, 2026, 7:58am

Hi Dago,

Happy to read you here.

Yes, that’s exactly the problem I like to solve. As OxS includes alias and redirections, would be nice to include the “canonical” tag to make Google happy.

I recently changed it in my theme, but I think OxS could include this out-of-the-box.
Honestly, I think this change offers a very high return on investment.

Probably we might find more things in OxS to improve SEO, but if we dig deeper into the issue, they turn into massive projects, and it’s really hard to find the time to tackle them.

Actually, it can be handled in the theme (that’s how I do it)… but I think the right approach (in my opinion) would be to generate the tag directly in the core to ensure it’s always included.