Using a Custom Image Size In WordPress SEO Open Graph Tags

WordPress SEO is an essential plugin for any WordPress site. Although WordPress in general is pretty great for SEO, this plugin handles a ton of methods for improving your site’s SEO, from generation XML sitemaps to suggesting keywords for your content.

One area where the WordPress SEO plugin really shines is with Open Graph tags, which define how your content is shared with certain social networks, most notably Facebook. The WordPress SEO plugin will automatically generate the following Open Graphs tags for each page of your site:

If you have a Featured Image set for the post or page, the plugin will also generate an og:image tag. However, by default the URL of the original image will be used. This can prove to be problematic if the original image is very large, or has uncommon proportions. If you have defined a custom image size in your theme using add_image_size() you may wish to use that size instead. Thankfully, the WordPress SEO plugin applies a filter, wpseo_opengraph_image_size, to the value used when grabbing the image URL for the open graph tag. Add a hook in your theme’s functions.php file similar to the following:

In this example I’ve set the image size as ‘large’, which will be contained to 1024×1024 pixels. You can use any image size you want, but keep these requirements in mind from the official Facebook Developer blog:

Images must be at least 200×200 pixels for desktop web and ideally, 600×600 pixels or greater for the best experience across devices.

Images may not appear in the new design if they are smaller than 200×200 pixels, and rectangular photos may be cropped.

Image requirements include:

  • 4 Megapixel limit
  • 5MB limit
  • direct links to the image only
  • only JPG, PNG, GIF, or BMP file formats
Pageviews, Time on Site, and Google Analytics

Pageviews, Time on Site, and Google Analytics

  • Goals, Virtual Pageviews and Event Tracking in Google Analytics

    This article discusses two methods of capturing actions on your site in Google Analytics: Event Tracking and Pageview Tracking. Event Tracking can be used for any action a user takes on your site. A couple examples would be signing up for the RSS feed, clicking through to your twitter page, or sharing a story on Facebook. Since these actions don’t generate a new pageview on your site, event tracking is one way to measure that. Pageview tracking would be used for tracking links to external pages, and for setting Goals in analytics for on-page events, since only URLs can be set as goals. You can also use this for tracking pageviews for dynamically loaded content.

  • Page Views vs. Time Spent: Balance Competing Metrics

    This article discusses the rise of time spent as a core metric. “As visitors spend more time viewing AJAX pages or watching video, the pure page-view metric can underreport a property’s marketing performance.” The article frames the discussion in terms of content-driven sites vs. data-driven or app-like sites, and although much of the article is confusing and poorly written, the conclusion is valid: make your site easy to use, and focus on engagement over pageviews.

  • The Pros and Cons of Virtual Page View Tracking in Google Analytics
  • The Pros and Cons of Event Tracking in Google Analytics

    There is a surprising lack of of articles regarding pageview and event tracking with Google Analytics, aside from technical implementation posts. These two articles outline the two types of dynamic tracking, with pros and cons for each. One interesting fact is that if an event is recorded on a single-page session, that will not be counted as a bounce, since there was some interaction. Web developers should consider implementing this for features on their page which don’t trigger an organic pageview, such as a social media widget or RSS link. Another implication of this has to do with time on site. If a user only visits one page, the time on site isn’t recorded since there isn’t another data point for GA to compare times with. If an event or virtual pageview were tracked, it stands to reason that time spent on site would increase.