Simple URL Shortener | Support Portal & SEO Forums » All Posts Thu, 26 Nov 2020 02:48:30 +0000 en-US <![CDATA[Reply To: if you are looking for other ways to increase your income, check]]> Tue, 24 Nov 2020 23:55:18 +0000 Please don’t post things like that on our SEO forums @real Stuff, thank you.

]]> <![CDATA[if you are looking for other ways to increase your income, check]]> Tue, 24 Nov 2020 02:50:50 +0000 Post had been moderated due to the post was not in compliance with our TOS.

]]> <![CDATA[A Salary is the Drug They Give You to Forget Your Dreams]]> Mon, 16 Nov 2020 21:59:36 +0000


]]> <![CDATA[5 Ways URL Shorteners Can Impact SEO]]> Mon, 16 Nov 2020 00:36:10 +0000

Here is some thoughts on how SEO impacts you if you use a URL Shortener:


]]> <![CDATA[The Hidden Benefits of A Short URL for Google SEO]]> Mon, 16 Nov 2020 00:29:40 +0000

Should you be using a short URL to rank higher on google? Neil Patel gives his view on the subject.

]]> <![CDATA[The Basic Rules For The Gift of Speed In WordPress]]> Wed, 11 Nov 2020 12:40:35 +0000

The Basic Rules Of Speeding Up WordPress load-times

Well basic rules are as follows:

1.) Don’t use too many plugins. A range of 20-30 max plugins installed and activated should be the “rule of thumb”. Using plugins impacts your server negatively in terms us each plugin use more server memory, and adding load times in terms of individual css, js and php files etc. which must be loaded and read each time a browser client request a page on your website. Add on top of that the increased need for read request to the database too.

Use real code instead if possible. It is always faster and will have much less impact on your system/server.

2.) If you must use a plugin use a MU-Plugin and also load code into that instead of functions.php. Just note that it will impact the whole network if you use WPMU, (E.g. all sub-sites and the primary site):
WordPress mu-Plugins: Your Guide to Using Must-Use Plugins

3.) Use server side caching like WP-Rocket or Hummingbird

4.) Use Browser client caching

5.) Use a CDN nextwork such as CloudFlare or Max CDN

6.) Combine CSS and JS files if possible:
  ** How to Combine External CSS in WordPress
  **How to combine CSS and JS files for WordPress

7.) Make sure your server have enough memory allocated to your WP site. Depending on if you run a Stand-alone WP Install or a WPMU network site is huge difference also in memory requirements.

8.) Make sure you have Gzip compression enabled:
  ** Enable Apache Gzip Compression (mod_deflate) in cPanel Account
  ** Check Gzip (& Brotli) Compression

9.) Make sure that your website is optimized for mobile too!
  ** 8 Quick Tips to Optimize WordPress Website for Mobile Users

10.) Minimize the number of DNS queries/lookups needed when a client request and loads your site:
  ** How to Reduce DNS Lookups? (Tips to Fasten Up the Speed)

11.) Don’t use larger images than you have to and make sure they are optimized for web so they do not weigh more than they really have to. Smaller images reduces the load times drastically. Also use jpg, webp over png if you do not need transparency in your image. Also use a image optimization plugin like WPMU Dev Smush or Imagify for even faster delivery times.
  ** An Introduction to Image Formats for the Web in 2020
** Image Optimization For The Web: The Definitive Guide

I guess that is most of it; if I have missed something then maybe add a comment below in this forum thread? ๐Ÿ™‚

]]> <![CDATA[Reply To: You Are Using WP Cron Incorrectly In Your WordPress Multisite!]]> Tue, 10 Nov 2020 13:21:01 +0000 Hi Studio 6Am

Well there could be many reasons why cron jobs needs to run on the sub-sites in a WordPress Multisite network. The most common and simple reason is this:

In WPMU installations you will have many different flavors of plugins installed and not every plugin will by default run on the primary site or be network enabled. Thus there will be plugin on individual sub-sitesย  that will run plugins that needs to be scheduled to do certain task such as they need to send out emails at a certain time due to various events or lets say a front-end meeting booking for example where the calendar needs to be refreshed and the attendances need to be notified when a meeting is about to start as an example.

The same applies for example to other types of plugins like lets say a security plugin where a malware scanner needs to be scheduled to run at a certain time and date. The same applies. The cron jobs needs to be running.

Now if you the cron jobs does not run on the sub-sites too then the functions of these plugins will simply not work as the crons are never fired up . So that is why it is not sufficient with just having the cron run on only the primary site.

Also you should think about that WordPress itself has a lot of natively scheduled background task and those need to run on the sub sites too in order for WordPress to function properly and if they to do not run there also then the WordPress background tasks will fail to complete their job on the whole network, (except for the main primary website).

I hope this explains it better for you?

Kind regards

]]> <![CDATA[Reply To: You Are Using WP Cron Incorrectly In Your WordPress Multisite!]]> Tue, 10 Nov 2020 00:59:25 +0000 Thanks for the article.ย  I’m wondering what types of things you folks use custom cron-jobs for.ย  Sharing your code above is helpful.ย  Perhaps a bit of dissecting the components for us budding developers would be helpful.

Cheers from Canada!

]]> <![CDATA[You Are Using WP Cron Incorrectly In Your WordPress Multisite!]]> Mon, 09 Nov 2020 17:10:34 +0000 Why You are using WP Cron Incorrectly on WordPress Multiste and how to fix it.

Why You Are Running WP Cron The Wrong Way in WPMU

So you have installed your new shiny WordPress website and then converted it to an awesome WPMU network with all the bells and whistles; you have configured the WordPress cron job either though C-Panel with wp.cron.php or through a plugin. All happy days right?


Well while this is perfectly fine and good when it comes to single stand-alone WordPress installation it is just not good enough to WordPress Multisite (WPMU) and it doesn’t apply if you run a WPMU installation. Actually all the generic common advice you can find on the internet about configuring WordPress cron is absolutely incorrect!

This is because there is a little dirty WordPress secret that you cannot find even on’s own website. And “what is that secret” you might ask?

Well the secret is that thew wp-cron.php file only fire and run on your main site in Multisite and not on all your sub-sites in WPMU so all the scheduled tasks that you might setup for any sub-site in the WPMU network will never ever run correctly.. Crazy isn’t it?

So we thought too and therefore created a fix for it.

In WordPress you have a small file called wp-cron.php, which simulates normal cron-jobs. except this file isnโ€™t executed every x amount of minutes. Instead WP-Cron will execute when someone visit the website.This will in normal single site fire when either user visits the website which then in turn will run the scheduled tasks. Now there is problem with this method in two ways of course. The first reason is that if you have low traffic site, then wp-cron will almost never fire and the task will not run all the time and two; on high traffic site it be very problematic due to it can generate too many cron tasks that it quickly uses all the server memory and crash the server. So for that reason most WP cron tutorials suggest that you disable wp-cron in your WordPress installation:

and then you set up a manual cron job. This is all good so far. The issue starts when you using WPMU and the cron job only run by default for the primary website aka. site ID 1. We have coded a this a fix for this issue and our script called “wp-cron-multisite.php” which will enable cron to run on all websites in the WPMU network with a short delay of 10000000 microseconds between each site in the system.

What you need to do to fix this:

Download our wp-cron-multisite.php and wp-croncustom.php script to your computer and save it as wp-cron-multisite.php and then upload it to your root folder of your WordPress installation:



After that you will need to disable wp-cron in your wp-config.php file if you haven’t already done that:

and enable alternative cron for our custom WPMU cron job script.

Once you have completed this step then head over to your hosting control panel and create the cron job manually:

or you could alternative use a online cron service to call the script for you if you prefer that. I suggest this website which is totally free to use and just works flawlessly.

What happens when you fire the wp-cron-multisite.php is that it run alongside wit the other file and call will call โ€˜wp-cron-custom.phpโ€™ will call โ€˜wp-cron-custom.phpโ€™ which is a modification of โ€˜wp-cron.phpโ€™ file.

You should now have smoothly working WPMU network that just works with its scheduled task.

You can also if you want to test run the script your browsers to confirm that it is working properly:
Hit enter and wait a little while and you should see the response that it is starting to fire up the cron jobs individually for each website which you have in the WPMU network.

All right; that’s it good folks for now and I’m out of here!

Comment here in this SEO forum thread if you want and share this with your with anyone you think might have good use of this.

]]> <![CDATA[Why you should lock your WordPress mission critical files]]> Sun, 08 Nov 2020 23:56:25 +0000 Simple URL Shortener  Laptop computer code

Why you should lock your critical WP files with read only 400 and 404 permissions

If you have a WordPress website, (like most website owners have) and your web host is using suPHP or suExec and running PHP as a CGI (Common Gateway Interface) and not using DSO โ€“ running PHP as an Apache Module (mod_php) then you should be locking your WordPress Mission Critical files.

Why? In Mass Code Injection attacks aimed at Web Hosts there is a vulnerability with having 644 Group Permissions on files. What this means is that it could be possible to cross code inject your WordPress Mission Critical file in a Shared Hosting Environment if Group Permissions Read is allowed. Just allowing Group Permissions Read and not having Group Permissions Write on files can make them vulnerable to Mass Code Injection attacks on Web Hosts in a Shared Hosting Environment.

404 File Permissions;

.htaccess files should have 404 File Permissions

  • Owner Permissions โ€“ Read On โ€“ Write X โ€“ Execute X
  • Group Permissions โ€“ Read X โ€“ Write X โ€“ Execute X
  • Public Permissions โ€“ Read On โ€“ Write X โ€“ Execute X

400 File Permissions:

index.php, wp-config.php and wp-blog-header.php should have 400 File Permissions

  • Owner Permissions โ€“ Read On โ€“ Write X โ€“ Execute X
  • Group Permissions โ€“ Read X โ€“ Write X โ€“ Execute X
  • Public Permissions โ€“ Read X โ€“ Write X โ€“ Execute X

By doing this you will harden your installation further while minimizing the outside access to files. Remember that this doesn’t just apply to your files in the root folder of your WordPress installation, but to all your .htaccess files throughout your whole file structure within the WordPress directory.