You can actually get the best of both worlds using the Redirection plugin Iain mentions, Himanshu. The plugin can be configured so that the redirects you create within it get written to the .htaccess file.

Having the redirects in the .htaccess file is preferred, because the .htaccess is processed faster and with lower load by your server than the redirects within WordPress. This is obviously much more important if you have a large number or redirects to write, as opposed to a dozen or so to deal with a few changed pages.

Paul

The one thing you haven't mentioned, which is likely to be most critical for this issue, is your XML sitemap. I couldn't find it at any of the standard URLs (/sitemap.xml and /sitemap_index.xml both lead to generic 404 pages). Also, there's no directive to the sitemap in your robots.txt.

Given that the sitemap.xml is the clearest and fastest way for you to help Google to discover new content, I'd strongly recommend you get a clean, dynamically updated sitemap.xml implemented for the site, submit it through both Google and Bing webmaster tools, and place the proper pointer to it in your robots.txt file.

Once it's been submitted to the webmaster tools, you'll be able to see exactly how frequently its being discovered/crawled.

Hope that helps?

Paul

I would agree that H1s are stronger than

tags for SEO, but they're still pretty minor on-page indications.

Of much greater impact would be to better-optimize the meta-title for the page, which is one of the strongest on-page SEO factors. Right now it's just the company name "Uniko Manufacturing Limited"  Much better would be "Uniko Manufacturing Limited - Wholesale Sign and Display Industry Supply" or something similar.

Also, the page has no meta-description, which could severely handicap it when it does appear in search results. The meta-description does not help with ranking, but it's like a mini-ad for the page right in the search results to all ow you try to convince a searcher to click on your page instead of someone else's.

Better to focus on the highest impact optimizations first, rather than just the easiest.

Hope that makes sense?

Paul

Regarding the speed issue, a single rewrite rule using regex with a wildcard could handle redirecting all of those old event URLs to the new event calendar directory, as it appears you wish to do. Saves a huge amount of work and cuts way down on the 301 redirects that have be parsed on each page load.

Paul

In the "old days" (yup, I go back that far), Google's search index crawler wasn't all that powerful. So it would ration itself on each page and simply quit trying to process all the content on the page after a certain number of links and certain character count. (That's also why it used to be VERY important that your content was close to the top of your page code, not buried at the bottom of the code).

The crawler has been beefed up to the point where this hasn't been a limiting factor per page for a long time, so the crawler will traverse pretty well any links you feed it. But I +1 both Andy and Mike's advice about considering the usability and link power dilution of having extensive numbers of links on a page. (This is especially important to consider for your site's primary pages, since one of their main jobs is to help flow their ranking authority down to important/valuable second-level pages.)

Paul

This issue is resolved by adding a single self-referential rel-canonical tag to the header of each page of the site, Catherine. Once you've done that, the URLs that contain the parameters will automatically contain the canonical to the primary URL (because the pages' code are actually the same - it's just the URL itself that is changing. By which I mean - there aren't separate pages for each of the currencies. They're are all the same page code, with just the parameter added to the URL and prices dynamically changed.)

This does mean that the search engines would index the page with the default prices, which appears to be Euros.

For example, if your home page had a self-referential canonical tag, it's canonical tag would be

<link rel="<a class="attribute-value">canonical</a>" href="<a class="attribute-value">http://www.marcb.com</a>" />

While this may seem redundant, it also means that this URL https://www.marcb.com/?setCurrencyId=2 would also contain the above canonical tag, since the page is actually built from the same code. So it's canonical would point to the correct URL automatically, without having to do anything specific for all those variations. This is a core function of how CMSs (Content Management Systems) templates work. This time it works in your favour.

You definitely don't want to no-index those parameter-based variations even if you could. Once you get the canonicals properly implemented, you want the search crawlers to keep crawling those pages URLs so they can discover the corrected canonicals and understand that they are intentional dupes of the core page. They'll eventually drop the parameter-based URLs out of the index, which you can monitor in your Google Search Console, for example. There's a major benefit to the site if the search crawlers aren't wasting their time on duplicate/useless pages, as well as reducing potential issues with Panda/Quality algorithms, so well worth getting this corrected right away.

Hope all that makes sense?

Paul

While theoretically logical, Google's own John Mueller stated last week that code to text ratio has absolutely no effect on crawling of a site, and in a followup question, he directly told me text/code ratio has no effect as a ranking factor either.

These used to be very minor considerations back when the search engine crawlers weren't as powerful, but no longer.

Fully agree with Pia that the idea of "above the fold" influencing ranking is nonsense as well. Given that the sweet spot for consistently high-ranking pages is ~2200 words, the idea that only the first paragraph or two are more important is unsupportable.

Hope that helps?

Paul

Agree with Stephan - the dupe H1s, while not ideal, are not going to be a significant SEO issue.

But what will be the issue is the extra page bloat and therefore load speed of all those pages. Not necessarily for SEO, but most certainly for usability. There are much more efficient ways to get your pages to scale for different devices than to run three sets of headers.

Paul

Lazy load and infinite scroll are absolutely not the same thing, as far as search crawlers are concerned.

Lazy-loaded content, if it exists in the dom of the page will be indexed but it's importance will likely be reduced (any content that requires user interaction to see is reduced in ranking value).

But because infinite scroll is unmanageable for the crawler (it's not going to stay on one page and keep crawling for hours as every blog post rolls into view) Google's John Mueller has said the crawler will simply stop at the bottom of the initial page load.

This webinar/discussion on crawl and rendering from just last week included G's John Mueller and a Google engineer and will give you exactly the info you're looking for, right from the horse's mouth, Victoria.

To consider though - the blog's index page shouldn't be the primary source for the blog's content anyway - the individual permalinked post URLs are what should be crawled and ranking for the individual post content. And the xml sitemap should be the primary source for google's discovery of those URLs. Though obviously linking from authoritative pages will help the posts, but that's going to change every time the blog index page updates anyway. Also, did you know that you can submit the blog's RSS feed as a sitemap in addition to the xml sitemap? It's the fastest way I've found of getting new blog posts crawled/indexed.

Hope that helps!

Paul

Great that you got what you were looking for, Alex. Looks like you got a bunch of useful info from the responses. Would be great if you could designate the replies you found were "good answers", both to reward the author and to help future readers of the question.

And I had a mug of tea in your honour - not going near that coffee stuff

Paul

I actually never learned to enjoy coffee, so it's no sacrifice at all. But you'll have to pry my Earl Grey from my cold dead hands

Google tries to index the rendered page, not the raw page code. The best way to see that page as Google sees it is to use the Fetch and Render tool in Google Search Console.

Alternately, you can use the developer tools in Chrome or Firefox to show the rendered version of the page code. Right-click in an area of the page you wish to view, and then select Inspect. This will bring up the inspector which will show you the rendered page code close to how Google sees it. (Google uses Chrome V42 for indexing, while the current version of Chrome is 62 - so you're not necessarily seeing exactly what G is seeing, which is why Fetch and Render is more the view G actually sees.)

The screenshot below shows the Inspect method of viewing the rendered page in current Chrome - but as I say, safest is to view within Google Search Console's Fetch tool.

Hope that helps?

Paul

P.S. This is an example of why Wix is not recommended for critical websites - it's using JavaScript methods to render basic page content which Google "says" it can index, but it's depending on a completely non-standard way of presenting page content which depends on search crawlers deviating from their standard methods to try to crawl it. (And there have been incidents in the past where G's crawling capabilti8y for this kind of JavaScript wasn't indexing it properly, causing major issues for a huge number of sites.)

hgWsq