Voyager Pro theme not responsive

What is google saying about Voyager that is unresponsive? That should definitely be a responsive theme.

When I type the demo site into the google mobile-friendly test, it passes fine for me.

The site I am referring to is www.advancedassessments.co.uk it definately is not responsive, I have checked on my mobile and it looks terrible!! On desk top its fine. I need to resolve this urgently or stop addres running tomorrow.

With your URL, hopefully @Elixir can answer as to what’s happening.

Hi there @Sankofa – Can you do me a favor and send me a ZIP file containing your project file? I suspect there’s something up with your content that is causing the problem, as the theme itself is definitely responsive, as has been noted above and can be seen when visiting the live preview URL for the theme.

If you send that project file over I can take a look at it.

Might remove the meta tag for rel=“canonical” you added.
Seems like it may not be plain text. It is “eating up” (treating as one statement) the viewport meta tag.

This is what it looks like if I edit the HTML in the browser:

<link rel="canonical" href="https://advancedassessments.co.uk”/&gt;&#10;&#10;&#9;&lt;!-- Meta tags --&gt;&#10;&#9;&lt;!-- These in particular setup the viewport for mobile devices --&gt;&#10;  &lt;meta name=" viewport"="" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0">

If you added this by pasting, make sure to “paste as Plan Text”.

1 Like

Dear Doug

Thank you very much for taking the time to respond the headers of now being placed pasted as plaintext and the site is running as responsive on all devices.

I also made a few other modifications, to improve search engine optimisation, firstly, the language setting in rapid we rate for some reason doesn’t seem to be picked up by some site optimisation tools such as Site Optimizer and indeed Google. To resolve this I added a tag using the hreflang Tags Generator Tool, which was simple to use even for the non-techies like me.

The Google Mobile Usability Tool, in Google Search Console detected several other errors which were not revealed when testing the site with other website optimisation tools such as MOZ or Site Analyzer, these were that the clickable links were placed to close together, to solve this I simply placed an extra line between each link, while it takes up more space on the desktop version on the mobile version it’s much easier to access its link with a URL or download.

The Google Mobile Usability Tool also indicated that the viewpoint was not set, have been out work out in plain English what this means. However, Voyager theme’s navigation bar might not be too obvious to those who are not used to navigating the web using such bars. To resolve this, by made a few prominent links on each page referring to where the site map is, to allow easier navigation. When these actions were combined it radically improve the page speed and the mobile usability score, the desktop usability score was also significantly improved.

As is apparent, different search optimisation tools and website auditing produce slightly different results therefore, I have opted to use several different website audit rules at the same time. I think that this will remain the position until all of the underlying faults in the websites are resolved.

According to MOZ there are still three remaining issues to be resolved:

(1) There is a warning that there is a redirect chain, I believe that what they mean by this is the website is available from both the http and https options. I have set Cloudflare so that it only uses https, however versions of the website and I am unsure how to resolve this issue and would welcome your views.
(2) There is a 404 error and this is produced by Cloudflare’s email protection. I have removed the robot’s txt path on the website because this was causing one of the 404 errors and there is no need for it in any event. However, the email production does still show was an error on Google Search Console. Here is the code that clouds where say should be placed in the header

"You can make modifications in your /wp-includes/functions.php file. to create an additional Disallow rule. A sample of what it would look like is below:

function do_robots() {

header( ‘Content-Type: text/plain; charset=utf-8’ );

do_action( ‘do_robotstxt’ );

$output = "User-agent: *\n";

$public = get_option( ‘blog_public’ );

if ( ‘0’ == $public ) {

$output .= "Disallow: /\n";

} else {

$site_url = parse_url( site_url() );

$path = ( !empty( $site_url[‘path’] ) ) ? $site_url[‘path’] : ‘’;

$output .= "Disallow: $path/wp-admin/\n";

$output .= "Disallow: $path/wp-includes/\n";

$output .= "Disallow: $path/cdn-cgi/\n";

}

Wanted to check with you exactly where this should be placed (that is which page should it go on?) Will this code cure is the underlying fault?

There is a rule for the robots txt which is: Disallow: /cdn-cgi/

However, as I have indicated I am not using a robits txt file.

(3) There is also a Meta no index warning arising from the same email protection file produced by Cloudflare. Moz gives the following advice but there are only tick boxes in Rapidweaver to specify whether or not the page is to be indexed. If this rule is to be used will it work and where should it go?:

“If you determine that this page should be indexed by search engines, inspect the <head> of your page and change <META NAME=”robots” CONTENT=”noindex”> to say “index”, or simply delete the META robots tag completely. Assuming this page isn’t blocked from search engines in some other fashion (in and Xrobots header or in the robots.txt), search engines should start indexing this page again.”

Thanks for offering to look at this this problem has been updated, if you see my post below. I will still send the project file as there are still a few problems as indicated below and as indicated in Google Page Speed Test

Hi there @Sankofa –

While using these optimization tools is beneficial you do have to take some of it with a grain of salt. Also, as you’re using a templated web design system you will not be able to adjust and change everything these sites ask of you. This is a tradeoff of using a template based system where you’re not hand-coding.

The Voyager Pro theme does indeed set the viewport:

Thanks for the update, I realise that you have to be cautious about some of the tools but the ones that I am mainly concerned about at the metrics designed used by Google and other search engines as errors in these will lead to manual actions taken against the site and at a more basic level higher advertising costs because of low quality scores. Always happy to work with developers to refine the template, the problem has been finding developers who are familiar with Rapid Weaver - which is why I am reaching out to you.

It isn’t a matter of refining the template. RapidWeaver’s templating system is not going to do everything that some of those sites want.

That’s why the report says

viewport was not set

The canonical meta tag you entered had syntax issues that “broke” the following viewport tag.

I agree with Adam (@Elixir) in that most of the reporting tools shouldn’t be taken as a “bible” of SEO. They are just area you can improve on.

That’s probably not an issue, you more than likely have a redirect for WWW to or from non-WWW and a redirect from HTTP to HTTPS? If they are separate rules you could combine them, but it won’t really have any effect on the sites SERP ranking. Now if you have a “chain” of redirects for a single URL that gets really deep, and/or you mix 301 and 302 redirects than that might be an issue.
As for the 404, not sure I understand what you might be saying.

Pretty simple check the box index this page and RapidWeaver produces the <META NAME=”robots” CONTENT=”index”> for you.

The viewpoint is no longer be highlighted as an issue in the Google mobile tool, so that seems to have been resolved by the other work which I did, as indicated above. All what is left now are the three issues as highlighted on the MOZ report. We will have to see what the crawl report says when the site is crawled again in Google search Console, but on the face of it, the major issues have been resolved. I agree that many of the optimisation tools often over-egg the severity of the problems. This is why I have focused on the big-ticket items, and left the other “nice to be resolved” issues till later. I think whatever solution you have, whether it’s a template website or a website customised to you there will always be some refinements that can be made according to the search optimisation tools. This is why the focus has always been on the key items/errors which will lead to low-quality scores and, therefore, higher advertising costs.

I think the best thing to do here is to upload a screenshot of the report either later today or tomorrow. As they tend to be automated reports, they are not that clear am somewhat pleased that even you don’t understand what the reports are saying. They seem to be very obscure to me, it might be worthwhile going back directly to MOZ for specific clarification on what they mean as they are automated errors which aren’t always that meaningful, as you have pointed out.