Re: [Tiki-devel] tiki.org: Wiki attachement are indexed is Search Engine

> On Oct 12, 2021, at 6:06 PM, Jean-Marc Libs <[email protected]> wrote:
> 
> Hi Brendan,
> 
> I am pretty sure canonicals are not meant to indicate the page an image or a pdf is linked from. Here is a recap of the purpose of canonicals:
> « A canonical tag (rel=“canonical”) is a snippet of HTML code that defines the main version for duplicate, near-duplicate and similar pages. In other words, if you have the same or similar content available under different URLs, you can use canonical tags to specify which version is the main one and thus, should be indexed. » (taken from https://ahrefs.com/blog/canonical-tags/ <https://ahrefs.com/blog/canonical-tags/>).
> 
This is a very flawed statement. canonical is not just HTML, they can also be HTTP headers. It is also not just used for duplicate content, but also for attaching things together. For example, I used a third-party rating system at one point and was concerned that ratings from their website would not translate into search ratings on my own. But since they used a canonical link to point all the reviews for a specific product on their website, and pointed the canonical link to the product page on my website, all the content was transferred over onto my product webpages. I did in fact even verify at the time that this worked.

So none of the definitive statements they made are correct. It is not a snippet of HTML (that is one form it can take) and it is not meant to define the main version of duplicate content (but it is a very common application of it)


> My understanding: Either we forbid all indexing of wiki page attachments or we keep them. There is no page on our websites which duplicates the content of the file Bernard pointed out. It's a reference document. Page https://tiki.org/TikiFestCEST <https://tiki.org/TikiFestCEST> mostly mentions different topics.
> I'd say we keep them because some are very related to Tiki (like our flyers) and worth indexing. It's annoying that the link points to the file and does not give a chance to access our pages but I have no idea for solving this.

Hmm. It's not that simple. We could make options that people could select if we wanted. Keeping them indexed is the better choice in terms of SEO. But we could, for example, point the canonical link for PDF documents onto a page with Tiki navigation and display the PDF there. So when people are looking at the PDF on a tiki site (from the tiki site) it just appears as a simple PDF, but when coming from a search engine, it directs them to an HTML page with the PDF embedded. Perhaps with a button to view just the PDF on its own.

> 
> I agree with adding canonicals at the HTTP level for contents of file galleries and page attachments, but these need to be self-referenced canonicals, not links to the page(s) which links to them.
> 
> Reading up on canonicals led me to this: https://ahrefs.com/blog/hreflang-tags/ <https://ahrefs.com/blog/hreflang-tags/>
> Maybe that would help with our way of displaying relationships between language versions of the same page.

Ya, Bernard and I were talking about this. It could be very useful for TIki!

Brendan



> 
> Cheers,
> J-M
> 
> On Tue, Oct 12, 2021 at 5:01 PM Brendan Ferguson <[email protected] <mailto:[email protected]>> wrote:
> None of the content from this file will go into getting us better search rankings. And this file will be much harder to find if someone is looking for it if we block it with robots.txt,
> 
> Moreover, even if we block it with robots.txt, it still may show up in google search results. That is if another website or even our website links to this file, it still may be available in search results, it just won’t be indexed.
> 
> It would be much better to use a canonical link via HTTP headers. This way all the content and any links to this content get pointed and accounted for on the page is in use on. Search rankings grow instead of decreasing and it won’t show up in the search results in this bizarre way any longer.
> 
> Brendan
> 
> 
>> On Oct 12, 2021, at 10:40 AM, Bernard Sfez via TikiWiki-devel <[email protected] <mailto:[email protected]>> wrote:
>> 
>> Hello,
>> 
>> I found another one to block in Tiki robot file, the following link is among the 3 best results for Tiki in September 2021. 🥴
>> Shouldn’t we not allow "/tiki-download_wiki_attachment.php” by default ?
>> 
>> 
>> https://tiki.org/tiki-download_wiki_attachment.php?attId=855&page=TikiFestCEST&download=y <https://tiki.org/tiki-download_wiki_attachment.php?attId=855&page=TikiFestCEST&download=y>
>> 
>> 
>> Thanks,
>> Bernard
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel <https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel>
> 
> _______________________________________________
> TikiWiki-devel mailing list
> [email protected] <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel <https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel>
> _______________________________________________
> TikiWiki-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

_______________________________________________
TikiWiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel