We enjoy using WordPress because it is so friendly with Search Engines; however, what if you have a page you want public but not indexed? There are a number of ways to do this and adding a code to a “header.php” file in your child-theme, but this gets messy. The plug-ins we used in the past are no longer in development. Well everything we needed to achieve this was already installed and it is in Yoast SEO.
In the Admin section go to the page you want to block.
Expand the Yoast SEO tab.
Go down to Advanced and expand it.
In the “Allow search engines to show this Post in search results?” set this to “NO“, and the “Should search engines follow links on this Post” to “No“
If you look at the source code of the page you will see the meta data for indexing is set to NOT INDEX.
We worked on improving the SEO of a page, so when we were finished we removed the old URL and submitted the new one. This was a mistake. We would recommended waiting till the new page has been indexed before removing the old page. The reason for this is that critical page was not indexed at all for a month. The reason for this was there was an error on the page that we didn’t notice Google was warning us. This was on the URL Inspection page.
We overlooked the text stating “because of an error.”, and we keep hitting the “Request Indexing” button. After a few weeks the page never got indexed. We decided to click on the “TEST LIVE URL” button. When we did this we got a completely different screen saying the page is available for indexing. Once it was done we now see this page.
Finally got things moving forward. We are looking forward to seeing new results.
DIVI is fun to work with, and the latest update has greatly improved the load times on your pages. We took a DIVI site and ran it through Google’s Page Insights. Our initial numbers were so-so. We need to improve a few things. We don’t like page score below 80 on Desktop and 40 on Mobile. Our first run without the DIVI update gave us the following numbers.
Desktop
59
Mobile
21
Google Page Insights Score
We deleted out the cache and installed the DIVI update, and that one change made a big difference.
Desktop
75
Mobile
44
Google Page Insights Score
Not a huge change, but what an improvement! With Google putting more weight into Mobile-first indexing this is a huge help. If you are running a DIVI site and haven’t updated you should do it, and use Page Insights to measure the difference. We think you will be please.
We try to stay on top of the 3 major Content Management Systems of WordPress, Joomla, and Drupal. This week was a big announcement from Joomla that version 4 is ready. We took a copy of a Joomla 3.9.28 and installed it in a XXAMP environment. We set the Joomla Update “options” in the “next” from the “default” and was prompted to upgrade straight to version 4. This would skip version 3.10. We went for it and it failed at the end of the update. Site was broken at that point. We are suggesting holding off from upgrading to version 4 at this moment.
We tried going from 3.9.28 to 3.10 and everything worked fine. We knew our Gantry 5 template wasn’t Joomla 4 ready, so we switched our templates to Protostar, and tried to got to version 4. The upgrade failed at this as well. We tried disabling most of the plug-ins we installed and this didn’t help. RocketThemes the maker of Gantry offers upgraded pieces you can replace your existing Gantry template to be Joomla 4 ready. We are going to try these and see if this helps. We hope to have an update for you. Here is the link to their GIT page with this information.
Although we haven’t spent much time on this effort yet we would advise before you upgrade test the site locally first. At this time we are advising against upgrading to Joomla 4 at this time.
While typing up a contract we noticed Word put a red squiggly line under the word “subcontractor“. We looked to see what was wrong and Word was suggesting a french spelling of the word. The word “subcontractor” was throughout the document; however, it didn’t have a problem with those, just the ones on this one page. We fixed this by doing the following:
Go to the “Review” tab
Click on the “Language” button
Choose “Set Proofing Language“.
Select your Language preference, and check the box “Detect Language automatically“.
We look at how fast our website loads and generally try to keep the load times under 7 seconds. Some people want the sites to load faster, but we do have a fair amount of content to display on the home page plus Google Analytics, a Translation widget, and we pull a couple of RSS feeds. We have often used Google’s PageInsights to get a general idea of where we can shed some weight from our site.
Today while doing a check on our site I see PageInsights has added “view treemap” button which takes you to Google’s Lighthouse. This was incredible handy to get a big picture of what is taking up the most bandwidth. Here is what we saw.
We can see the “translation” widget is too large for us to use. We are using the Google TagManager widget, that we are going to stop using since our site has a tag component built-in.
Simply turning these items off took our page score from 69 to 83. Still not in the Green; however, pretty good. Using the new “Treemap” is awesome.
Accelerated Mobile Pages (AMP) make your website more digestible for Google and has been adopted over the past 5 years by the other search engines. Google currently being the most utilized search engine, and the focus of this article. The goal for AMP is to make the content delivered more quickly for mobile users by condensing and indexing the pages. WordPress adopted this as a part of their core installation, and in testing we discovered Joomla is Rich Results Ready as well. Here is some of the things we have done to improve a Joomla site to be AMPping itself up to be searched.
A great place to start is to use Google as an AMP Tester. Use the link below to access Google’s AMP tester.
The hard part about these tests are they do not work on your “home” page. There is also Google Structured Data which is the actually the important part of the indexing; however, the page will benefit by being AMP ready. The combination will get your page mobile ready for search engines, with very specified content details you want indexed. We start with the Google Structured Data (GSD) on the services pages. The first thing we did was install a free plugin by Tassos Marinos which you can download in the Joomla Extension Directory (JED) or directly from his site.
Install the component like a normal Joomla component. Then enable the plug-ins. There will 3 of them.
Then go to Components >> Google Structured Data >> Dashboard.
Click on the “Items” tab on the left, and “Article” will be the main item to deal with.
Once in “Article” item we set it to pull the “Browser Page Title” vs the “Title” because of the way we have the SEO set up. Make sure to complete as much of these sections as you can. Save your changes.
Then go back to the “Configuration” tab. Fill out as much as you can. Once you are done and satisfied you can go to the “Advanced” tab and turn on the minify of the output.
Before you minify the output look at the source code and make sure the content you want in the GSD is correct. We had an issue with “description” not showing up. We had to reinstall the plugin.
We had also installed a free AMP plugin, but it didn’t help. Just using the GSD plugin from Tassos was enough to make the site Rich Result Ready. Make sure to follow the instructions and view the source of the page to make sure the Structured Data looks the way you want it to before you request Google to index your pages. If you don’t it could be weeks before Google crawls the site and indexes it properly.
We do love the ease of WordPress except when it goes wrong. While working on a new site we got the 5.7 update notification, and we hit the button to update. Well it didn’t go like planned. We had try to update manually, and not something we have done often. It went pretty easy, and we didn’t disable the plugins before starting. We were able to get back into the site when we finished; however, the page content for all the pages didn’t show. We were left with a shell. We started with this article from WordPress.
We backed up the two directories “wp-admin” and “wp-includes” into a temporary folder we called “archive”.
Downloaded the latest package from WordPress.
Extracted the zip.
Moved the extracted “wp-admin” and “wp-includes” into our site directory.
We didn’t have move any other files or disable any plugins and we were back in action, or so we thought. We restored the site with an Akeeba backup, but the update failed again.
Our final solution was to take a copy we posted for customer review on HostGator that was able to run the update and restored this to our XXAMP development machine. Not a perfect solution, but we are building once again. There are a number of variables that are different between the hosting and the PHP versions being one of them. It looks like PHP 7.3 worked better than 7.2.
We recently used Akeeba Backup to migrate a WordPress site for testing purposes; however, whenever we after enter our credentials into the new URL’s admin area we got redirected the old URL admin area. This was frustrating because we didn’t notice at first and started experimenting on the good site. A search lead us to the following post that resolved our issue.
It is a similar issue to when you manually migrate a WordPress site. We resolved the issue by going into PHPmyAdmin and the “Options” table. Sure enough the “home” and “siteURL” were set to the old site. Usually Akeeba does a great job updating this options.
While doing a review of our site for SEO we were thrown by seeing out page URL’s shortened and three vertical dots at the end of the title. An example is our shows one of our services as just our site name, the category “services”, and then the three dots. We were expecting the specific service after that. When you click on the three dots you get a modal with “About this result Beta” and some stuff. It looks like this.
Our access control page in Google search listing
Now this windows shows what the full URL is; however, at first this is alarming. We work hard on our SEO.
At first we really didn’t find any information on this, and we expected an email in our webmastertools account. It turns out to not have an affect on the search results. Eventually we found the following article to explain the new “about this result” feature.
We never found out why it pulls from Wikipedia. Colleges do not consider Wikipedia a reliable source. Sources say Google claims this feature was developed during the pandemic to ensure users on how reliable the source is. Making web searches from everyone in the USA are getting reliable information.
