Yoast SEO WordPress Plugin Compatibility and Configuration Tips

Wiki.TerraBase.info
Revision as of 12:29, 29 February 2020 by Root (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Versions and Compatibility

Versions of Yoast: https://yoast.com/wordpress/plugins/seo/change-log-wordpress-seo/

Compatibility with WordPress Versions

  • According to this web page, 10.1.3 is the last official version stated to work with WordPress 4.9.X. However, after experimenting, 12.7.1 (December 12, 2019) is the last version that will work with 4.9.X

Tips

Nagging

To get rid of the annoying Premium Advertisement, edit and edit this file with the below code: /WhatEverPathToWebSite/wp-content/plugins/wordpress-seo-premium/admin/views/sidebar.php

<?php
/**
 * View for the banner sidebar.
 *
 * @package WPSEO\Admin\Views
 */
?>

or use a Plugin like WP Nag Hide.

Bulk Editor

For the Bulk Editor, to list more than 10 items per page: /WhatEverPathToWebsite/wp-content/plugins/wordpress-seo-premium/admin/class-bulk-editor-list-table.php, edit this section: protected function set_pagination, this variable: wpseo_posts_per_page (default is 10) AND same path, file name: class-admin.php, bulk_edit_options, default (default value is 10).

WP Security Plugin Issue causes the Bulk Editor to not Display

Note: For the WP Security Plugin, do NOT enable File System Security, PHP Editing Tab, Disable Ability to edit PHP Files (for logged in users only). Why screw with admin settings if they're already protected via Apache?

Terminology

Search Index or SiteMap in Yoast? Yes and no. Yes, it obviously produces one, but doesn't use those terms. Instead it's named something else and located here: SEO (Yoast), Search Appearance, Content Types

Location of Sitemap Index

And the location of the Sitemap Index? Intuitive, but not via the GUI: WhatEverSiteName/sitemap_index.xml, in the GUI: SEO (Yoast), General, Features Tab, XML Sitemaps, Click the question mark, see the XML Sitemap Index (Woof!)

Sitemaps (Various Sitemaps it generates and useful ones)

Generally speaking, Yoast will add all Posts to a Sitemap. It divides them into different Sitemaps based on what type of post they are (https://developer.wordpress.org/themes/basics/post-types/)

Naming Convention: TypeOfPost-sitemap.xml

  • te_announcement: Timeline Express
  • page: Pages (including the Front Page)
  • attachment: Images, etc. (Yoast refers to this as Media, but in the sitemap_index it is referred to as attachment-sitemap.xml)
  • post: Posts
  • "By Category"


Redirect attachment URLs to the attachment itself (AKA: Redirect Media Permalink to URL of File)

This setting is located under the SEO Tab, Search Appearance, Media Tab.

First, don't do it, because it will kill off the attachment-sitemap.xml file.

Second, what they really mean, in WordPress terminology instead of Yoast terminology, is "Redirect Media Permalink to URL of file". For example, when WordPress creates a Permalink for a Post of Attachment Type: HTTPS://WhatEverDomain/WhatEverPath/WhatEverPermalink (https://www.wordpress/images/picture-of-a-flower) is redirected to HTTPS://WhatEverDomain/WhatEverPath/FileName.Extension (https://www.wordpress.com/wp-content/uploads/picture-of-a-flower.jpg)

Solution? Make your own redirect. It's not simple, but it is possible to duplicate the functionality of Yoast to redirect WordPress Posts of Attachment Type to their physical files ending in .jpg, .png, .gif, etc. files. Plus it's a bit ugly. Why not have the Media Permalink redirect to the Image as it is on a Page or Post? Or better yet, why not have the URL to the image redirect to the image on its place in the Page or Post? It works great for end users, but not so good for search engines. Why? If an image URL is redirected to the spot on a page where an image is the image file will become the HTML code. IE, if one sets that described scenario up and uses WGET to download the .JPG file, it will instead download the HTML code of the page it redirects to.

In my case it was made even more difficult because the Post Media Attachments (Images) were displayed by a Plugin titled Magic Zoom on a Timeline created by a Plugin titled Timeline Express