Category: Search engine optimization (SEO)

Good:

Since Tiki4, in tiki-admin_include_sefurl.php, Tiki detects if .htaccess is there and if contains tiki-index.php?page=$1

But:
If Tiki is upgraded, by installing over, there may be issues because Tiki is still using the old .htaccess without informing tiki admin


Proposal:
Have Tiki version number in _htaccess (and thus updated as part of the release procedure)
Test on this, and inform users when they forgot to upgrade their .htaccess file.

Please see:
http://tikiwiki.org/tiki-view_blog_post.php?blogId=2&postId=343

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

The new "saved_msg=y" fails when SEFURL is on - both new pages and editing. It gives me a 404 not-found error. Makes SEFURL pretty useless. Example:
http://www.casesofinterest.com/tiki/Everything+is+Patentable&saved_msg=y

Please increase the limit and make it multilingual

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

{syntax type="tiki" editor="plain"}
Hi,

After display of a filtered list :

Various erratics behavior with the "sort" command by clicking a column of the header :

1- on "date" no effect or the list is cleared (after a crash of SQL request : before we had the crash, now it is handled but simply clears the list)

2- on "version" no effect at all.

Others not checked again (had been two years ago), who will repair can checked each column sort behavior...

In tiki-admin.php?page=sefurl, we have
* Display blog title in the sefurl
* Display article title in the sefurl

which is really nice.

Even better would be to also have:
* Display tracker item title in the sefurl

So
https://dev.tiki.org/item1000
becomes:
https://dev.tiki.org/item1000-Tracker-mail-in-in-addition-to-forum-wiki-articles

{img fileId="270"}

Visit these pages to see for yourself:
http://info.tikiwiki.org/Hosting (6.x)
http://profiles.tikiwiki.org/Profiles_in_installer (9.x)
http://dev.tikiwiki.org/Tiki13 (12.x)


It should be a redirect 301. And needs to work for 6.x, 9.x and 12.x

This worked when the feature was introduced so some other fix / enhancement must have broken it.

This is especially not good because in this version the ((canonical)) link is just relative and thus, we have two canonicals for same page...

If you go to front page, it redirects OK
http://info.tikiwiki.org (6.x)
http://profiles.tikiwiki.org (9.x)
http://dev.tikiwiki.org (12.x)

I can't see the reason for the separation between the structures feature and the menu feature - structures are massively easier to create and edit, but only menus can be shown collapsibly. Separation of functions leads to confusion and harder support.

Please see:
http://tiki.org/tiki-slideshow2.php?page_ref_id=565

The canonical should be the "Tiki Suite component interoperability" wiki page.

In 12.x if not risky, else in trunk
The canonical relation for https://themes.tiki.org/tiki-print.php?page=CSS should be:

{CODE()}<link rel="canonical" href="https://themes.tiki.org/CSS">{CODE}

ex.:

# Redirects
# This is useful if you are migrating from an old site, and you want the old URLs to still work.
# Just uncomment and edit the line below.
Redirect 301 /oldpage.html /tiki-index.php?page=newpage

When you view an article, the URL simply includes the id# of the article. On wiki pages, however, the URL lists the article title.

You cannot assign meta tags to individual pages. If you use the universal meta tags, that is not the best way to optimize for search engines.

The redirect plugin currently lacks the ability to include fragment identifiers, e.g. -+~np~{REDIRECT(page=Foo#some_id)/}~/np~+- does not work; the resulting URL is -+~np~tiki-index.php?page=Foo#some_id&redirectpage=this_page~/np~+- instead of -+~np~tiki-index.php?page=Foo&redirectpage=this_page#some_id.~/np~+-

When using the "_htaccess" files in Tikiwiki 1.9.5 you get an "Regex could not be compiled" access error in some of the directories when using Apache 2.2.
The Problem occurs, if the statement <FilesMatch "*"> is in the .htaccess file.

On our site we use the short URLs enabled by the SEO feature. We have used the default TikiWiki .htaccess file.

One of our blogs has grown to a reasonable size and users of it were claiming that the link at the bottom of the page to the next set of entries wasn't working. I confirmed this to be the case.

Looking at the source loaded into my browser for the page on clicking the "next page" button the following link should have been called :
{CODE()}/blog1?offset=20{CODE}
Manually entering this link did not work either. However if I entered the full URL below I did get the blog posts I was hoping for:
{CODE()}tiki-view_blog.php?blogId=1&offset=20{CODE}

I therefore suspected that the ReWrite rule was not correct. The standard rule is:
{CODE()}RewriteRule ^blog([0-9]+) tiki-view_blog.php?blogId=$1 [QSA,L]{CODE}

This standard rule chops off the end of the requested URL after the blog number, thereby removing the __~amp~offset=20__ parameter.

I have a comment on a wiki page. When I click Reply to post a follow-up comment, I get an error. It looks like the Reply button is generating a bad URL:

__Not Found

The requested URL /mywiki/page=IVR_Revitalization&post_reply=1&comments_threshold=0&comments_reply_threadId=5&comments_offset=0&thread_sort_mode=commentDate_asc&comments_per_page=20&comments_grandParentId=0&comments_parentId=5&thread_style=commentStyle_plain was not found on this server.__

This would be a show stopper using Tiki threaded comments is very important feature requirement for us.

Thanks,

Paul

https://tiki.org/tiki-view_forum_thread.php?comments_parentId=50396
offers a canonical of
https://tiki.org/forumthread50396

Good.

Now, it also has two links:
https://tiki.org/tiki-view_forum_thread.php?comments_parentId=50396&display=print
https://tiki.org/tiki-view_forum_thread.php?comments_parentId=50396&display=print_all

The print versions should have the canonical as well.

Please see:
http://www.seomoz.org/blog/canonical-url-tag-the-most-important-advancement-in-seo-practices-since-sitemaps

tiki-print.php -> tiki-index.php

In trackers, if you find a tracker item following a search, you have some parameters in the URL for item 6 of 70. The canonical format should be just the tracker item.

In blogs,
tiki-send_blog_post.php?postId=xyz
and
tiki-print_blog_post.php?postId=6079
should be:
tiki-view_blog_post.php?postId=xyz

Since wiki page names should avoid special characters, we'll need to think about maybe using character substitutions in page names (a instead of à, _ instead of ') and use the description field for the exact format.

Please coordinate here: ((Character substitutions))

*.Tiki.org sites have a large number of external links. It would be nice to have a tool to check all the links and to report on status. Possibly this could be related to the cacheing feature.

See: ((Link Checker))

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

Goal: Making is easy to use description field without needing to duplicate data entry

Say I use Tiki for terminology.

If I use the wiki page name for terms, I will end up with many weird characters in the URL.

If I use the description for the term, I still need to enter a cleaner/shorter wiki page name.

This is an unnecessary step.

Create wiki page could be full term, and accents and special characters are suggested (but overrideable)