Category: Search engine optimization (SEO)

Although the RFC (for example, [http://www.robotstxt.org/wc/norobots-rfc.html]) doesn't explicitly require a leading slash (/) before the page name, I have found that, as of late Oct, 2005, many 'bots, including Googlebots, have started requiring them.

For example, before the change,

Disallow: tiki-pagehistory.php

would prevent well-behaved 'bots from trying to index tiki-pagehistory.php. However, after the change, I had to have:

Disallow: /tiki-pagehistory.php

in robots.txt, or else all my page history would be indexed! I verified this using my server log, and also by doing google searches against my site for phrases that only appeared in page history. I have every reason to believe this is a problem for all other TikiWiki-based sites.

Others have noticed this. There is discussion in the forums at:
* [http://tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=13666&forumId=4|Googlebot ignoring robots.txt] -- includes a __graph of my bandwidth usage before and after__.
* [http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=4&comments_parentId=12342|Adding <meta name="robots" content="noindex,nofollow"> to History pages]
* [http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=4&comments_parentId=15004|Yahoo search indexes Print pages instead of Read pages]

I have completed an enhanced robots.txt file.

Initial Website XML Maps I was making were returning Just under 500 results. The Sitemap now returns 45 results, one of which is an error, that I have filed a separate bug report for. No pages are duplicated, all pages with relevant content are crawled.

Of note is that I have re-enabled the file gallery being crawled. It was returning large number of files and was disabled to prevent pressure on the web server. Results can now be indexed without the massive duplication that existed before.

There is a section in the file that can be commented out to prevent duplicated pages when SEF URL's is enabled. Applied automatically, it will prevent the entire website from being crawled.

Of importance is also that I have only tested this for the feature set that I am using. It WILL create a better crawling and therefor better Search Engine ranking with other features, but may not take it as far as one could be achieved.

Using this robots.txt file not only decreases server load, but also leads to better search engine rankings.

The robots.txt in the current distro (1.9.x Sirius) contains

Disallow: tiki-print.php

Should it not also contain

Disallow: tiki-print_article.php
Disallow: tiki-print_blog_post.php
Disallow: tiki-print_multi_pages.php
Disallow: tiki-print_pages.php

After my last upgrade of a working Tiki23 (5 days ago) sitemap creation using from the scheduler fail.

If I run the command from the scheduler manually it works.
If I run the command from the terminal php7.4 console.php sitemap:generate https://www.domain.com/, it work.

{img fileId="1680" thumb="box"}

Regarding:
[http://doc.tiki.org/Clean+URLs]

The documentation linked above states (my emphasis added):

"Search engine friendly url Postfilter - ~~#090:__To generate SEFURLs for all Tiki links, also check the second checkbox__~~ which creates short URLs by filtering the output. The SEFURL Postfilter consumes more processor (CPU) time than the non-filter version (it deals with all the text and it deals also with cached text like modules while the 'on the fly' filter does not do it. ~~#00F:__In future versions the SEFURL Postfilter will not be used__~~ - it is only necessary until the template SEFURL work is finished. ~~#906:__Either one or both features (SEFURL and SEFURL Postfilter) may be used.__~~

I had both checked. This worked when I was on 4.x, and started failing when I moved to 5.0. This is why I marked it as a regression. The problem still exists in 5.3.

Each now works OK separately, but the they no longer work together. I've disabled the postfilter.

Is the postfilter no longer necessary, or am I no longer generating sefurls for all links? Priority of 3 based on the assumption that the postfilter is still necessary, otherwise I would have set it to 1.

The search engine friendly links do not appear for forum threads. You can use the SEF link to get there, and somewhere on the website the SEF form us used (based on a crawled index of links) but it is not present under the form thread list page, which is arguably the highest traffic page to access the threads from.

I have also looked at the RSS and the SEF links are not used for the forum in there as well. They use the standard tiki-view_forum_thread.php page with a URL passed argument.

Hoping someone can track down what went wrong. I have already searched through my .htaccess file to make sure I did not break it myself, but don't think the issue is there.

SEF links for the forums themselves appear to be functionally normally.

Right now, the sefurl for article topics is:

articles?topicName=news to tiki-view_article.php

Possibly, articles/news should point to tiki-view_article.php?topicName=news

I think this might be common enough to be a core feature.

__A CMS without SEF URL means it is a Bug : Usability__

it's a by setup checkable standart in a high quality CMS
simple weblogs like http://www.s9y.org/ have such a feature

why :
google likes */this_is_a_very_god_page.html
and normaly google didn't index
*/mybugy.php?bestpage=my&t1=page&t2=is&t3=the&t4=best&indexed_by_SE=normalnever

i think the best webpage is nothing if SEFURL isn't working


the half way is done with the htaccess - ok
the next half way was a mod from http://www.coofercat.com/wiki/TikiURLtInstall

It's working in a root env with 1.9.x and 1.10cvs
that means only if /tmp is writable for the webserver - this is the bug

but online on a vserver this shit happens to me

Warning: mkdir(): open_basedir restriction in effect. File(/tmp/71) is not within the allowed path(s): (/srv/nww/webx/:/srv/nww/htdocs/phpMyAdmin/:/srv/nww/htdocs/confixx/html/gesperrt/) in /srv/nww/webx/html/wiki/lib/adodb/adodb.inc.php on line 1551

Warning: fopen(): open_basedir restriction in effect. File(/tmp/71/adodb_716f2422695ca15b221f4ce6f146321c.cache) is not within the allowed path(s): (/srv/nww/webx/:/srv/nww/htdocs/phpMyAdmin/:/srv/nww/htdocs/confixx/html/gesperrt/) in /srv/nww/webx/html/wiki/lib/adodb/adodb-csvlib.inc.php on line 298
......this msg repeats about 1000 times
did you know what's going on

I started to debug this problem
but it seams to get bigger and bigger

saved data titles must be renamed
becorce
http://localhost/HEAD/page-page%202.html
didn't result in
page 2
and so on

Hello.

I need to improve a SEFUrl feature.
The point is that it lacks some functionality needed to be a perfect tool for webmaster or seo specialist or both.

It claims to rewrite urls into shorter and more meaningful ones. However the urls with the title in language other than english (i.e. russian) have nothing after "articleN" (english version is "articleN-the-name-of-the-article").
In addition if an article is divided into several pages there will be urls like "articleN&page=M", no title in them.

Forums and its threads have no meaningful part at all.

It would be great if there are links like this
http://example.com/articles/this-article-is-about-sefurl-feuture-in-tikiwiki
http://example.com/test-forum/the-main-topic

Could you please suggest on how to do it or maybe there is already rewritten or similar feature somewhere i can find?

https://developers.google.com/search-appliance/documentation/68/admin_crawl/Preparing#pagepart

class=”robots-nocontent”

http://antezeta.com/news/avoid-search-engine-indexing

We need a way of making Tiki known or not known to search engines before we do this. (like in wp)
We need the same, a "Search engine visibility" check box (enable or disable)
If enable the Tiki site can be crawled by search engine.
If disable nothing is to be crawled.
Should be enabled by default.

Should the site map be generated from the wiki structure? from the menu?


https://www.google.com/webmasters/tools/docs/en/protocol.html#sitemapOverview
http://www.sitemaps.org/

I see from a fresh Tiki 25.1 install that the "site_title_location" global preference is set to "Before current page's descriptor" by default. This makes no sense from a usability and SEO standpoint. 99% of the time you can't read the page title in your browser tabs because it's obscured by the site title, which makes your 30 open tabs all look identical.

The default should be "After current page's descriptor".

Seen on tikiwiki.org

It gives error 404


Possible solutions:
*Users could be prevented to create pages with characters that conflict with
*Rewrite rules are not activated when page name contains such characters

Please see:
http://sourceforge.net/mailarchive/forum.php?thread_id=10026369&forum_id=12569

In tiki-browse_gallery.php, there is Sort Images by [ Name | Date | Hits | User | Size ] so robots can think these are all different pages

{syntax type="tiki" editor="plain"}
If you turn on SEF all your links will be converted to SEF-links so far with the exception of the links the bradcrumb bar of the structure.

Tested on tiki 3.5

When you try to access a wiki page which doesn't exist, Tiki offers you a list of similarly named pages, to search for that word, to create the page, etc.

__Good.__

When you try to access other contents in Tiki (articles, blog posts, etc.) that don't exist (either have been deleted, moved, not yet published, protected, etc.), you get a Tiki error message.

__Good as well.__


But what if you try an URL which is just not possible?

Ex.: If you migrated from another system to Tiki and you are still getting hits with the previous URLs?

Of course, you could check your access logs and add nice redirects. But how can we make this easier for site admins?


The bundled _htaccess file (which you need to rename .htaccess to make active) has an example line:
{img src=images/code.png}%%% {CODE()}
ErrorDocument 404 /tiki-index.php?page=Page+not+found
{CODE}

__This is good.__

Now, how could we use this to provide the Tiki admin with a top-x error pages? And thus, it would help to detect broken links, etc.

Could .htaccess include some configuration info from Tiki? So a Tiki admin could add configuration information without using FTP, all in Tiki, possibly with a secret "system" wiki page.

Great inspiration:
https://github.com/h5bp/html5-boilerplate/blob/master/dist/.htaccess

The canonical is:
<link rel="canonical" href="https://nextthemes.tiki.org/tiki-all_languages.php?page=CSS">

But should be
<link rel="canonical" href="https://nextthemes.tiki.org/CSS">

Using 1.9.7cvs from mid june 2007

I have an item in a tracker with the word "Carxoferes" in the tracker item title.
http://www.moviments.net/valldelcorb/tiki-view_tracker_item.php?itemId=15&show=view&offset=0&reloff=7&status=o&trackerId=2&sort_mode=lastModif_asc

In the search_new module, trackers doesn't show up in the dropdown box. However, if you search for the Word "Carxoferes" (without double quoting marks), the word "trackers" is listed below search results:
http://www.moviments.net/valldelcorb/tiki-searchindex.php?highlight=Carxoferes&where=trackers&search=go

So is it really searching (or attempting to search) within tracker items?
But anyway, the result is unsuccessful: no pages matches your criteria.
^
! Search results:
Search in:
__All Wiki galleries images files forums blogs blog posts directory articles trackers__


Found "Carxoferes" in 0 trackers

Find [[___________] [[go]

No pages matched the search criteria
Page: 1/0
^

And it should show the tracker item containing that word.
----
Confirmed that the same behavior is happening in 1.10cvs (from July 24th). Checked at:
[http://moviments.net/intercanvis/tracker2]
Adding a new item with the word "senzilles". If I search that word under the tiki search_new module, I can't find it. If I search through Trackers interface directly, I do find it.
----
Update2: using ((doc:Module search_box)) I can find it! (real time indexation works then)
---
Fixed on 1.10cvs. Not sure on 1.9cvs (I couldn't check with latest code). As far as I'm concerned, I leave this bug ask closed. (reopen if you test on 1.9.cvs and it fails)

The Problem
i.e. the structure tee ist partial accessible for anonymous -
but in the Page view /tiki-index.php?page=xyz all the substrucktures are clickable but they are not accessible (permission of the subtree gives a 302 for the visitor - so he must go back ...

a robot like google creates so much traffic becose he want follow this dead links

so i thought this is solvable by a sitemap
but Tiki has no intern tool for a sitemap like some other cms.
so i started with a online sitemapgenerator - but disasterarea 302 permission
next sitemap-gen.py from sourceforge but the same disasterarea 302 permission
but much bigger becourse it generates from the apache accesslog.

So next i thought about this mess!OK Why create a link if it is not clickable for anonym
yes thats the first solution to give the thing a straight line

looks like a big bugfamily

<lq_013> before a few day's i started with working on a sitemap for tiki
<lq_013> first Idea with using a external tool end up in a disaster
<lq_013> this courced by permission on some struktures
<lq_013> next disasterpart is the rewrite seo engine wich produces some pages 4 times
<lq_013> each accessible in an other way
<lq_013> the sitemaptool from sourcefrge which makes analyse of the access.log produces much more shit
<lq_013> some things can be restricted in a config file but thats no god Idea
<lq_013> so my suggestion to solve some of this sitemap disasters is to cancel all a href=... where annonymous can't click to
<lq_013> this is more then recommented becourse all visitors and searchengines follow this links and get a 302
<lq_013> with redirekt to login or whatever

{syntax type="tiki" editor="plain"}
These should all work:
* http://dev.tiki.org/item107-Restore-IRC-topic-after
* http://dev.tiki.org/item107-Restore-IRC-topic-after-TikiFest
* http://dev.tiki.org/item107-BLABAL

And should have same Canonical link -> http://dev.tiki.org/item107-Restore-IRC-topic-after-TikiFest

{syntax type="tiki" editor="plain"}
When we create a new wiki page we write {CODE()}((My New Page)){CODE} and get the URL http://example.com/My+New+Page

Is it possible to get the following URL structure

http://example.com/my-new-page

i.e. all lower case and hyphens "-" instead of plus sign "+" ?
Thank you

{syntax type="tiki" editor="plain"}
Turning on Sefurl leads to random WSOD's which can only be fixed by restoring all files and the database previous to the settings change.

After upgrading a Tiki23 to 2322c5e8 it solved some previous issues I had (see related ticket) but there is still a difference between submitting manually my sitemap generated from Tiki and using the console command (scheduler).

If I look at tiki-admin_sitemap.php I'm suggested to submit : https://www.bernardsfez.com/tiki-sitemap.php?file=sitemap-index.xml
With this url, Google discover 42 URL.

But from what I see in the Google console search, seems the console command use a different URL, https://bernardsfez.com/storage/public/sitemap-index.xml, which allow to discover 96 URL.

From a quick calculation the missing 54 URL are my Articles.

{img fileId="1670" thumb="box"}

At google search console (https://search.google.com/search-console/sitemaps) my sitemap (using https://bernardsfez.com/storage/public/sitemap-index.xml) is submitted via the console.php command (using the Tiki scheduler).

{img fileId="1670" thumb="box"}

If I click on the corresponding row it open a detailed table where I see that Google fetched 2 XML and that fetching my articles XML it produce 1 error.

{img fileId="1671" thumb="box"}

When I click on it to see the details I see error about the lasted date.

{img fileId="1672" thumb="box"}

And when I look at https://bernardsfez.com/storage/public/articles.xml the dates are all wrong.
It seems to prevent Google to index my articles.
When I index one by one articles using https://search.google.com/search-console/inspect (when a page is not indexed I have an option to index it) It work just fine with the right date.

I also checked at tiki.org and I see the same errors: https://tiki.org/storage/public/articles.xml

{FADE(label="XML where we can see the date errors" icon="y")}

<!-- Generated by https://git.io/phpseo -->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/%25D7%25AA%25D7%2595%25D7%259B%25D7%25A0%25D7%2594-%25D7%259E%25D7%25A7%25D7%2595%25D7%2595%25D7%259F-%25D7%259C%25D7%25A0%25D7%2599%25D7%2594%25D7%2595%25D7%259C-%25D7%25A6%25D7%2594%25D7%25A8%25D7%2595%25D7%259F-%25D7%2597%25D7%2595%25D7%2592%25D7%2599%25D7%259D-%25D7%2595%25D7%2592%25D7%25A0%25D7%2599-%25D7%2599%25D7%259C%25D7%2593%25D7%2599%25D7%259D</loc>
<priority>0.6</priority>
<changefreq>weekly</changefreq>
~~#F00:<lastmod>6773-12-06T16:34:41+02:00</lastmod>~~
</url>
<url>
...
~~#F00:<lastmod>1970-01-01T02:00:00+02:00</lastmod>~~
</url>
<url>
...
~~#F00:<lastmod>1970-01-01T02:00:00+02:00</lastmod>~~
</url>
<url>
...
~~#F00:<lastmod>5887-12-06T16:05:59+02:00</lastmod>~~
</url>
<url>
...
~~#F00:<lastmod>1970-01-01T02:00:00+02:00</lastmod>~~
</url>
<url>

{FADE}