I'm afraid we're in a bit of a state of limbo on this issue, Nickington.

Currently, Google's ranking is based on the desktop version of the site for both desktop and mobile results.

Google has clearly stated, and many tests have confirmed, that content which is not visible unless a user interacts with the page (such as having to click the drop-down for the FAQ result) is deemphasized in search results.

BUT! Google has also stated that they are in the midst of changing to a mobile-first index which will mean that the mobile version of websites will be used for ranking assessment. In addition, they've been quite clear that at that point, since things like accordion drop-downs are so much better UX for mobile users, that kind of hidden content will no longer be "penalised".

Unfortunately, there's been no declared date for when the switch to the mobile Index will occur. Instead, they've said that it will be rolled out gradually to individual sites as they detect that the mobile version of a site is ready for it. This means it's entirely impossible to assess when the changeover might apply to your site.

So for absolute best SEO, the solution is unfortunately a bunch of extra work for a hybrid solution My best recommendation would be to build out the FAQ content using headers and sub-headers so the content is fully visible on the page and gets full indexing authority from the search engine. Then keep an eye on the mobile indexing of your site to detect when it appears that it has moved fully into the mobile-first Index stage, and at that point redo the FAQ page to utilize the accordion drop downs instead.

The alternative would be to build out the page using the accordion drop downs to start with, and accept the fact that it will be some time before that hidden content has a chance to rank effectively. this would definitely be a second-best option in my opinion.

Does that all make sense?

Paul

This situation is quite easy to resolve if you are using the Yoast WordPress SEO plugin.

Under the plugin's settings, go to the Permalink Settings page. The second section down offers the option to "Redirect attachment URLs to parent post URL." Put a checkmark in the box, click Save, and from now on, those individual image-only pages will automatically redirect back to the post on which they appear.

No idea if the same option is available in other SEO plugins - I've so long standardised on Yoast's plugin I'm not up to date on the others any more.

Brett's point about changing where images link will also work, but the plugin approach above means you don't have to go back an retroactively edit all your images.

Hope that helps?

Paul

You'll probably find Xenu Link Sleuth will work for this, Red. Not quite as elegant as using an extraction in Screaming Frog, but it is free.

Lemme know if that works?

Paul

The plugin is working on your site and is handling all of the meta-data except the page title, Arthur.

Many themes aren't coded to handle meta-titles in the standard way so plugins can control them. There's a setting in Yoast's plugin that can be used to force the rewrite of the titles.

If you go to the plugin's settings and click on the Title and Meta page, there's a check-box at the very top of the General tab called Force Rewrite Titles. If that's not selected, try putting a check-mark in the box. Then clear the WordPress cache if you;re using one, and clear your browser cache before reloading the test page.

Let us know if that works?

Paul

PS this assumes you've also turned off the SEO settings in the theme, which it looks like you have as Yoast's plugin is already setting the other metadata.

Nope - not for submitting for indexing. If there have been considerable page changes though, traffic could fluctuate as search engines take their time figuring out and understanding the changes.

Paul

Your homepage is a little over 900kb which isn't massive by any means. Your homepage loads in a little over 3.5 seconds from a Virginia location using the equivalent of a slow cable connection so it looks very-well speed optimized to me.

If you've seen that big a jump in bandwidth use with no accompanying jump in traffic, my strong guess is that some other site is leaching your content (otherwise known as hotlinking).

Typically, this means somebody else has embedded images from your site into their own, meaning every time their page displays the image, it loads form your server/bandwidth instead of their own. (Can also happen with other file types)

Some sites do this because they don't know any better, and sometimes it's malicious. I've seen this often happen from forums where a whole page of post images loads every time the thread is viewed. To see if this is happening, you'll need to check in your server logs. Google Analytics won't show it as the images aren't tagged with the tracking code.

If hotlinking is the problem, the only way to stop it is to tell your server to only display images that were requested from your own website pages. You do this through the htaccess file. If your site uses cPanel for it's hosting control panel, there's actually a button on the Panel in the Security section to disable hotlinking. I assume most other control panels have something similar. Be aware that this will disable ALL images from showing on other sites, including any badges etc you may have created for other sites to display intentionally.

Paul

That tool that Matt mentioned looked interesting, but it would have been painful to have to go through your site one page at a time.

As usual for crawling tasks like this, the paid version of Screaming Frog will do what you want. You can tell it to crawl your site looking for **href="yoursite.com **to find all occurrences of absolute internal links. You'd have to do a bit of regex magic to get it to find the relative links, but since by their nature a relative link will work even with the domain change, not sure why you'd be looking for those.

Or you could just do a find and replace of the URL string using something like phpMyAdmin directly in your database. That would be fastest as it would find & replace in one go, instead of having to manually edit each page.

Is this a WordPress site, there's a plugin specifically for finding and automatically updating these links. (It basically automates and puts a UI on the phpMyAdmin process mentioned above.)

Any of those ideas help?

Paul

Really sorry to hear the new site is still struggling, Nicolas. In some quick indexing tests, it certainly appears that your blog posts are being indexed, and I'm seeing them in the search results for the specific post titles. [See screenshot attached] It's possible this may have picked up in the 10 days since you posted this.

I'm assuming you submitted your site's xml sitemap to the correct www version of your Google Search Console? What does the sitemaps report indicate as far as the number of pages indexed compared the number submitted?

Certainly one of the tradeoffs of a site tool like Squarespace is that you have far less control of the code to implement technical SEO, but it shouldn't be so problematic that you lose rankings completely.

If you're interested, I'd be happy to share a short Skype chat to try to narrow down the issues. You can send me a private message through my account here at Moz.

Paul

From your description, it appears that when you were tweaking your Yoast SEO settings, you changed the permalink structure in the WP Dashboard's Settings > Permalinks section from www.domain.com/�tegory%/%postname%/ to just www.domain.com/%postname%/

Doing this causes all the URLS for all posts on your site to change, which means all the original URLs are no longer correct and result in 404s.

Your two options are:

• reset your permalinks back to their original structure, and redirect whatever new posts were created since the initial change back to the /category/postname URLs
• leave the new permalink structure in place and add a blanket rewrite rule in the htaccess file to redirect all the old post URLs to the new structure without the category. (Done properly, only one redirect is needed to handle all the post URLs.)

Personally, for improved site architecture and to keep from having all your existing posts run through redirects, I'd opt for the first option above.

Hope that all makes sense?

Paul

P.S. Make certain you have a current backup of the site before making any further changes, just in case.

You have a configuration choice in your WooCommerce settings that is causing this, Bob.

You've got the default customer location in settings set to "Geolocate (with page caching support)". This causes the variable to be added to the URL in order to enable the geo-location for each customer. Turn it off and the variable will no longer be added.

And yea, this is a disaster for SEO, as Dana explains, and it will also badly foul your Analytics and it even borks your site's internal search.

Hope that makes sense?

Paul

Definitely use option #2. There's no reason to have to maintain a server presence for the old site if it's been replaced. This is best practice - still fully allows ranking authority transfer to new domain.

Yes, it's a lot of work to do the redirects. Watch for cases where large numbers of URLs are the same, with just the domain name changed. Or that all have similar change required (e.g. removing a /category directory) Those can be handled with a single regex rule instead of having to create an individual redirect for each.

To ensure you catch as many of the old URLs as possible you can use the Screaming Frog crawl as the list of URLs needing redirects. Can help to merge that with with the old site's XML sitemap for completeness. Note - you'll have to redo the redirects from the plugin as well, as those will no longer work after the DNS is pointed to the new domain.  Check the old site's htaccess for an legacy redirects as well. It's usually also beneficial to redirect the images and other important media (pdfs and other downloadable files) if you can.

Then set up a process to monitor Google Search Console and Google Analytics on the new site to immediately detect and correct any new 404 errors that show up. (That's another major advantage of doing the redirect on the new site's htaccess - the 404s will actually be detectable with tools.)

Lastly, ensure you've used the Change of Address tool in Google Search Console to notify Google that the old site has moved to the new domain. Keeping the old site verified in GSC will allow for this, and will let you monitor the drop-off in indexing of the old site as Google recognises and indexes the transition.

Hope that all makes sense?

Paul

Nope, no effect, as you suspect, Eddie. That kind of attempt at copy-blocking doesn't change the way the content is available in the DOM of the page (which is why it's so ineffective) so has no effect on crawling/indexing.

You can prove this for yourself by going to a page and right-clicking to select the browser Inspect mode. This mode shows the actual rendered DOM of the page that the search engines are reading, and you'll see the content is easily accessible. The other option is to do a Fetch and Render request from within the site's Google Search Console and it will also show you what content Google can see.

That what you were looking for?

Paul

It's likely the other site is trying to use the redirects to mask their manipulative link building. (Which doesn't work, by the way.)

Short answer - no this isn't a good idea.

Hope that helps?

Paul