Your code looks as if you have more than one canonical tag deployed on a single web-page, so that would be a bad deployment. One page can only have one canonical parent and that's that

It seems that you are attempting to use canonical tags to address pagination (paginated content, e.g: site.com/collection/page-2/ or site.com/collection?p=2) on your collection URLs, is that right?

Don't use canonical tags to address pagination. A paginated URL is canonical for the specified 'page' of content, which may (under some rare circumstances) be more useful to search users. Do not de-index your paginated content by making those paginated URLs canonical elsewhere

Instead, use Google's rel=prev/next guidance as outlined here.

If you de-index paginated URLs by using canonical tags, the rankings that some of those paginated URLs (due to their unique comments or tabbed content) may have gained, will not usually be given to the canonical parent. Although you will have more control over the user-journey, you will lose out on some long-tail traffic

Instead use rel=prev/next which will tell Google that the content is a  subsequent 'page' of another document. This will make the paginated URLs 'less' likely to rank, but will allow them to rank for very specific search queries. Then you have the best of both worlds

Some people think that, prev/next and canonical are actually compatible. I am a little uneasy with regards to that, but if you do decide to utilise canonical tags to force one page to rank more often - don't deploy them without rel-prev/next

Hope that helps!

There are several ways to do this, some are more accurate than others. If you have access to the site which contain the web-page on Google Analytics, obviously you could filter your view down to one page / landing page and see when the specified page first got traffic (sessions / users). Note that if a page existed for a long time before it saw much usage, this wouldn't be very accurate.

If it's a WordPress site which you have access to, edit the page and check the published date and / or revision history. If it's a post of some kind then it may displays its publishing date on the front-end without you even having to log in. Note that if some content has been migrated from a previous WordPress site and the publishing dates have not been updated, this may not be wholly accurate either.

You can see when the WayBack Machine first archived the specified URL. The WayBack Machine uses a crawler which is always discovering new pages, not necessarily on the date(s) they were created (so this method can't be trusted 100% either)

In reality, even using the "inurl:" and "&as_qdr=y15" operators will only tell you when Google first saw a web-page, it won't tell you how old the page is. Web pages do not record their age in their coding, so in a way your quest is impossible (if you want to be 100% accurate)

Google doesn't tend to like 'clone' sites and if it detects them, one of the web properties will be nerfed. Google wants people to 'add value' to the web, and then reward them with traffic. The path is not supposed to be, build one site - clone it, get double the traffic. This is also to keep Google's search results diverse

Seriously, how annoying would it be if you searched for something and every link was the same site with a different name?

In situations where you gained extra traffic illegitimately, there's not much that you can do (technically or otherwise) to re-capture the traffic that you shouldn't have been getting in the first place.

If I were you, I'd be looking at this decision more in terms of: "this will help to plug a gap and stop further deterioration". If Google think you have been gaining traffic that you shouldn't have been getting, fixing the problem won't cause Google to give you 'bonus points' that see your site(s) return to illegitimate traffic levels

If you are looking for quick and easy ways to succeed in SEO, know that the lifespan of such techniques is limited. In actual fact, you're lucky not to have received a penalty on both sites.

This is not a case of "how can I make some quick traffic again", it's a case of "how can I demonstrate to Google that my behavior is changing, and avoid a penalty for my main site". Sometimes the benefit, is NOT losing everything you have!

Darin Pirkey made some good points, but I don't think it's a case of 'the benefits of moving outweigh the risks of leaving it'. My POV is very similar but slightly different. I think that 'the risks of leaving it as it is are greater than the risks of merging the web properties' (but then... I'm a bit of a cynic)

I think I get what you are querying. What you are saying is, can Google give a wild mix of results, when Google is confused in terms of where the user wants to go? Do Google's query-spaces, contain search-entities (thematic entities) which collide with each other, when the keywords are fuzzy around the edges?

Yes that is a common thing, it's partially by design and partially an error on Google's part. It's also just down to how users search.

If Google's machine-learning detects that, usually when people type in "bsc" they are actually looking for "b.sc" (B.Sc) - then the search results will collide and impact on each other. Google uses a lot of data to tell, which search results users were happy with. But sometimes, Google gets stuck - because one acronym (or search term) genuinely means two or more things and competing groups of users want the results to swing 'their' way.

Obviously, if Google just made the query-space about one thing, there would be 100% chance that a certain group of search users (who enter the query-space) would be dissatisfied regularly. In these situations, the query-space hedges its bets and supplies mixed results, which may vary in intensity (one way or the other) based on 'personalised' search (so the query-space also becomes more variable)

I see you have already discovered that either search produces very similar search results. That is a strong indicator that two query-spaces have 'collided' to some degree. When I checked in AdWords, Google did see "B.Sc" (corrected to "b sc" with a space) and "bsc" (not corrected) as distinct, but if placed into the keyword planner individually (to find keyword ideas) they came back with very similar stuff. That's what I'd call a 'partial' query-space collision

At the point where Google corrects one of the two keywords to the other, that's full-impact

Not sure on the date / time querying aspect, but instead of using "inurl:https://mysite.com" you might have better luck checking indexation via "site:mysite.com" (don't put in subdomains, www or protocol like HTTP / HTTPS)

Then be sure to tell Google to 'include' omitted results (if that notification shows up, sometimes it does - sometimes it doesn't!)

You can also use Google Search Console to check indexed pages:

• https://d.pr/i/oKcHzS.png (screenshot)
• https://d.pr/i/qvKhPa.png (screenshot)

You can only see the top 1,000 - but it does give you a count of all the indexed pages. I am pretty sure you could get more than 1k pages out of it, if you used the filter function repeatedly (taking less than 1k URLs from each site-area at a time)

In my experience it varies greatly and depends upon what else the spam team is dealing with. Sometimes it's been dealt with in a few days, other times... never!

There are two kinds of infractions when it comes to Google's guidelines being broken. There are the infractions that are against Google's policies and which may game their ranking system, then there are more serious infractions that may cause Google to break the law by linking to certain content

Guess which one is more important to them? Fighting spam is important to Google, but the sites which get flagged for posting illegal content are more likely to be dealt with more quickly. Just my 2pence

It's a tricky lesson to learn as Google often release posts and content which over-burdens developers with false-confidence (it's not the developer's fault). Basically, website owners and company owners often ask broad brush questions and pressure Google to respond with simple, succinct answers (like in Matt's old Webmaster videos).

Google cave into this pressure and say stuff like "yeah doing redirects for your migration is good", but in some (not all) of their published content, completely neglect to mention that some redirect types are more worthy than others within the context of certain situations.

Developers read posts written by Google and just think "ok fine that's how it is now so we just do that" and, of course - unless you make a livelihood studying all this stuff, you end up pretty far wide of the mark.

I recently answered this question by a webmaster whom had taken it for granted that, because Google 'can' crawl JS they always will (under all circumstances). He made a move in terms of technical on-site architecture and saw loss as well

Just ask the guys who know!

And yes, do the redirects, you may as well. You might still get something back from it (probably not a lot though)

You should have used 301 redirects which infer a 'permanent' move from one place to another. Google doesn't send link juice through 301 redirects because that's what the SEO industry says they should do, it's the other way around. Status code 301 infers that the contents of a web page have permanently moved from one URL to another, thus is 'may' be fair to shift all (or a portion) of SEO (ranking) equity from one address to another

Note that even if you do the right thing at the right time, it won't always work. If your redesign heavily removes content (which was previously perceived as useful) from a web page, don't expect the 301 redirect to carry 'all' the link juice from one page to another. Had this recently with a client who decided to streamline some of their more in-depth articles as part of a site redesign and move to HTTP (simultaneously). They did correctly use 301 redirects (A to B, nothing in the middle) and they did point all the posts from the old HTTP URLs to the HTTPS URLs on the new site (same domain, but again - protocol altered and change of design)

Because the posts contained quite radically different (stripped down) content on the new site, the 301 redirects only seemed to pass across between 25% and 33% of the ranking equity. They did everything right, but if you're telling Google that content has moved from one URL to another, you had better actually move the content (lies don't work)

If you take into account that, even doing most things correctly you can cause some major issues, if you use the wrong response code then obviously you greatly increase the risk of losing all (or much of) your ranking power

I'm going to say this now, one year is probably way too late to get back to where you were just by changing some redirects. If that's your expectation, check yourself before you wreck yourself. Redirects (of any kind) slowly decay over time and most people think that a lot of the equity transfer has occurred by six months, let alone twelve. If you transferred your ranking equity into the void of cyberspace... well, it's probably 'mostly' gone by now. I'd still recommend converting the redirects as it really is your only option other than building your ranking equity over from scratch

**Let's get onto, why what you did was wrong **(why is important!)

So to you, a '303' is a type of redirect. But in its wider context, it's actually a 'status code'. Not all status codes result in a redirect and they all mean completely different things. They basically tell a client or a web-browser, which makes a request (that results in some kind of error), what the best way to proceed is. Some just send information back, others perform more concrete actions like the 3XX codes (redirect codes)

One common thing we get on here is, people saying: "I want to de-index some pages from Google, but I can't get Meta no-index into the source code, what can I do?" - very often I look at those questions and find, the pages which they want de-indexed are sending status code 404. Status code (error) 404 simply means "this resource or  page isn't available temporarily, but keep tabs on it because it's only temporary and it will be back". So quite often I suggest to them, well you can deploy no-index in the HTTP header via X-robots, but also why don't you change the status code from 404 to 410? Status code 410 roughly means "gone, not coming back so don't bother coming back"

You did use a redirect code, but you used the wrong one which had the wrong meaning:

• https://en.wikipedia.org/wiki/HTTP_303

So what does status code 303 mean?

I cite from Wikipedia:

"The HTTP response status code 303 See Other is a way to redirect web applications to a new URI, particularly after a HTTP POST has been performed, since RFC 2616 (HTTP 1.1).

According to RFC 7231, which obsoletes RFC 2616, "A 303 response to a GET request indicates that the origin server does not have a representation of the target resource that can be transferred by the server over HTTP. However, the Location field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that other resource might result in a representation that is useful to recipients without implying that it represents the original target resource."

So in English a 303 translates roughly to:

"Hey web user. I can't give you the page you are requesting because it's gone, and I can't redirect you to that same content on another URL because guess what? It wasn't moved to another URL. That being said, I think this page I am going to send you to, is at least partially relevant. I'll send you there - ok?"

But you're only stating that the resource is partially equivalent, so you can only expect fractional (at best) equity transfer from one URL to the other

Using a 301 tells Google: "this exact page has moved to this other exact page and it's likely to be 75% the same or higher overall. Ok so maybe we changed how the nav menu looks an moved to HTTPS, but the written content and images and stuff that was unique to this page to begin with - that should basically be all the same. As such, you don't need to re-evaluate the ranking potential of this page"

... of course, Google still will (in many instances) re-evaluate the page against the query, which is why (although loads of people say they do) - 301 redirects don't always transfer 100% of your SEO equity. If the content is adjusted too much, even 301s don't save you and it's time to build up again from ground zero

As stated redirects decay over time as the SEO equity moves from one place to another. In your case you have asked Google to move one portion of the equity from one URL to another (which they may or may not have, depending on content alterations) and also to delete the remaining portion of your ranking power. If that movement is now complete, then gains from fixing the redirects won't be all you are hoping and dreaming of

It will help. Be sure that you do it, because it's a seconds to minutes change in your .htaccess file or web.config file. It's not hard, it's very simple and you could luck out. But with a whole year behind you... the odds aren't fantastic. Still it's some 'free' equity that you can get back, which you won't have to re-earn (so take it). But it won't be all-encompassing (sorry)

I certainly don't think there's any harm in a self-referencing confirmation, if anything it gives a bit of a 'you are here' marker

I found a Stack thread which might be handy:

• https://stackoverflow.com/questions/29816633/breadcrumbs-on-current-page

... seems pretty relevant. Obviously they're using microdata and not JSON-LD, but the logic should be similar

If you can get me a reasonable sized list of KWs (like a few hundred or less) I can send you the data from Google's Keyword Planner. The decent version (not the one which gives ranged estimates like "10-100 monthly searches"). It still rounds in 10s but at least they're not ranged figures

Just attach a text file to your original post and add a comment here to let me know (or link to a WeTransfer upload or something)

Am still following this by the way, seems to be quite the mystery!

Unlike 3XX (301, 302 etc) or 4XX (404 etc) errors, 5XX errors are actually highly variable and relate to server errors. A page can give a 5XX error one second and then in a few seconds, return a full page instead. If you encounter high volumes of 'false-positive' 5XX or 0 (time out) errors, it's usually a sign that at a certain time your server is under strain and Moz is crawling it a bit too quickly (thus resulting in false positive 5XX errors)

This could be if Moz decides to crawl your sit too quickly at peak operating time, or if Moz crawls your site when it's running something like a cron job (assuming that the job is handled by the same server which is handling your web requests). There can be many other reasons for 5XX false positives, but this is the most common

You can delay Moz's crawl bot (rogerbot) from crawling your site too frequently:

• https://moz.com/help/moz-procedures/crawlers/rogerbot

See if that helps. Keep in mind the change won't be instant, it may take a few weeks for it to be processed effectively. We had to do this recently for a client's site which was bound to a ridiculously weak hosting environ

Hope that helps!

Glad to be of service

That's interesting, makes me wonder if it's the volume and quality of links from AU being smaller or lesser than inbound signals from other regions

• https://d.pr/i/ddx8Jt.png (Ahrefs screenshot)

Certainly seems like a possibility but would need a lot more work to prove. Basically download all backlinks for the site from all sources (SEOSpyGlass, Moz, Ahrefs, Majestic SEO etc) and then re-crawl to see which ones are live. Split them by origin country, then put metrics (Page Authority, Citation Flow, Trust Flow etc) against all the links and see what 'region' most of the 'authority' (not the link count, the sum of SEO auth) is coming from

That's what I'd do next

If you have regional redirects in place which are snatching up first time users and pushing them to their own regional page(s) or sub-site(s), those can interfere with Google's crawling which in turn affects rankings and indexation.

I answered a slightly different (yet highly similar) question here: https://moz.com/community/q/branded-product-dropping-from-1st-position-why#reply_392487 - so this answer might help you too!

Basically Google was crawling their site from the wrong data centre and then their bot was being bounced away, stopping a certain page from indexing very well. Google were even caching a page from one language, as the same page from another language :')

Could be that you need to exempt user-agent GoogleBot from your regional redirects. It's been floating around as an issue for a few people lately so... may be worth checking?

Don't think this is possible with your site's (current) architecture as the parts you want to link to are 'generated' and exist in the modified source-code only, rather than the base source code.

Basically you can extend a URL using the hash-anchor (#) to connect to certain areas of a web-page, which are marked up a certain way.

**I can take your URL here: **https://www.sacramentotop10.com/business/chamber-of-commerce/

And extend it to jump straight to your footer, for example: https://www.sacramentotop10.com/business/chamber-of-commerce/#footer

This is because the footer always exists in your web-page's base (non-modified) source code:

• view-source:https://www.sacramentotop10.com/business/chamber-of-commerce/ - (this link will only work in Google Chrome!)

You can see the reference for your footer here:

• https://d.pr/i/AnLonX.png (screenshot)

That is a view of the page's non-modified source code, before any scripts (JavaScript etc) have run. That's what you get with right click -> View page source

Once your scripts have run, things look a little different. The modified source (which you can access via right click -> Inspect, using Google Chrome) is richer and paints a fuller picture

Here's the same area of code again but viewed via the modified source:

• https://d.pr/i/BRXg3B.png (screenshot)

As you can see, the modified source code (less Google / SEO friendly - as Google won't always execute your scripts when crawling!) contains the actual text for the copyright notice in your footer. The base source code (un-modified, more Google friendly as it's always read by Google) does not contain the actual text, only the ID which scripts need as an anchor to generate that text for you

Your problem is that, hash anchors which should work and open that window for you - won't work because all that content is stored in the modified source code (not in the base source).

Let's say you wanted to link to this one:

• https://d.pr/i/iQVOPs.png (screenshot)

And you wanted to make a link, that deep-links people just to this part here:

• https://d.pr/i/QvAwIe.png (screenshot)

Now technically if you inspect that frame, there is something with a decent ID to hook onto:

• https://d.pr/i/kMUsDO.png (screenshot)

So this link should technically work:

• https://www.sacramentotop10.com/business/chamber-of-commerce/#busi-3328-1

But sadly it doesn't do squat (I also tried https://www.sacramentotop10.com/business/chamber-of-commerce/#3328-1 and https://www.sacramentotop10.com/business/chamber-of-commerce/#3328).The reason is that, the content (pop-up window, text etc) for specified ID only exists in the modified source code (after scripts have run) but not in "View source" (the non-modified source code)

Check it out:

• https://d.pr/i/5GqIVY.png (screenshot)

You can see the 'hook' which JS grips into (to populate the content), but if you search for any content inside of the pop-up **window in the base (**non-modified) source code:

• https://d.pr/i/HhUdJK.png (screenshot)

Let's use that text ("Folsom Chamber of Commerce") as an example. Now go to the basic source code:

• https://d.pr/i/CmXVaP.png (screenshot)

Guess what?

• https://d.pr/i/7b2UrU.png (screenshot)

Bam! There's nothing there. Your problem is, you're trying to link to something which doesn't exist until scripts have run. You can use hash-anchors ('#') to deep-link, but not to generated areas of a web-page (as far as I am aware)

This functionality would require a restructure of your site in some way.

Usually when you move pages from one URL to another, you can notice a minor dip in performance initially. This is because backlinks which hit your site through 301 redirects will give you less SEO equity than those which hit your website directly

That's just at the page level, but when the URL of every single page on a site changes, you get the same thing (it just encapsulates your total SEO performance rather than a small fraction of it). As long as the redirect migration project is handled properly by an expert at a high level of granularity, usually any performance dip (even for a whole website) is minimal

Even if your architecture doesn't change and there's no redesign, if all of your pages move from one domain to another that still counts as a 'migration' in SEO terms and you still need to take extensive measures to prevent traffic tail-off

An SEO expert should be crawling all of your current site's pages **AND **adding in historic URL (which may no longer be live) from Analytics / Omniture / Search Console. In that way, even legacy pages which may previously have been ignored can be properly redirected (rather than 'just' your live URLs before the move) which can add a little extra padding and security

You need to retain hosting on the old domain so that it can continue to host either a .htaccess or web.config file (Apache (Linux) vs IIS (Windows). This file will coordinate your granular and rule-based redirects

Having a list of your currently live (old domain) and legacy (no longer live) URLs is great but it's not enough. It's even better to scan all of those URLs using something like URL Profiler (which relies upon API keys and subscriptions to multiple other data sources, including Moz) to determine for yourself - which of these URLs are worth using your granular redirects on?

Typically you end up with a big spreadsheet that looks like this:

• https://d.pr/i/9dvkot.png

Because you're aggregating data from multiple sources, leave it to a data analyst. Don't allow such a project to be handled by an amateur. Invest in insuring your SEO performance by working with pros...

This is really weird. Really really weird!

As you say, your site's source code seems to confirm that it is set to index. If we look here, we can plainly see that the coding syntax for a no-index directive is "noindex" (all one word).

Let's look at your source code:

• https://d.pr/i/RAYzE4.png

Yep, everything seems fine there! But what if a script is modifying your source code and including the directive - and Google's picking up on that?

If we look at the modified source code which I rendered and saved to a file here:

• https://d.pr/f/1ZKNfF.php

... we can see, there are no problems here either:

• https://d.pr/i/kcxO0z.png

Wow - that's really unhelpful!

Let's see what happens if we specifically search Google's live index for the URL:

• https://d.pr/i/944xFl.png

Interestingly, when we search Google's index for this page, we get this page returned instead.

It makes sense that Google would return that URL if it couldn't return the main URL, as one is nested inside of the other. If everything was healthy, we'd see Google listing both URLs instead of just one of them. Even if you edit my index query to remove the trailing slash, you still only get the nested URL (not the one you want to be showing, which is at a slightly higher-up level)

Another thought I had was, hmm maybe this is a canonical tag gone rogue. That bore no fruit either, as this page (which you want to index, yet won't) canonicals to this page - and both of those URLs are exactly the same. As such, it's obvious that we can't blame the canonical tag either! I even viewed the modified source to see if it got altered, no dice (the canonical tag is just fine)

Maybe the XML file is telling Google not to index the URL?

• https://d.pr/i/dvbCfy.png

Nope - that's fine too! No problems there...

Could the robots.txt file be interfering?

• https://d.pr/i/DmAN1t.png

No! Darn it, that's not the problem

I know that a no-index or blocking directive can also be sent through the HTTP header (usually via X-robots). Let's check the response header of your URL out:

• https://d.pr/i/cy0MoW.png

Nothing there that really raises my eyebrow. This is enabled and set to block, but to be honest that shouldn't affect Google's crawling at all. Anyone correct me if I am wrong, but defending your site against cross-site scripting (XSS) attacks doesn't impede crawling right?

Fudge it. Let's fling it through Google's Page-Speed Insights tool. Usually that will tell you if something is being blocked and why...

• https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.onlinemortgageadvisor.co.uk%2Fbad-credit-mortgages%2Fhow-to-get-a-mortgage-with-bad-credit%2F&tab=desktop

Nothing useful still!

Google's mobile friendly tool gives us some, semi-interesting information:

• https://search.google.com/test/mobile-friendly?view=fetch-info&id=g4uSC2GcoipwxKk-PtqN2Q

But it doesn't say the page can't be loaded. It only says some resources which the page pulls in can't be loaded! And guess what? They're all external things on other websites (other than a few theme related bits, but nothing IMO that should stop the whole page loading).

Let's try DeepCrawl's indexability checker (they make amazing software by the way... expensive though):

• https://d.pr/i/Iyrzq5.png

Sir... there is NO GOOD REASON why your URL shouldn't be indexed. I am 99.9% certain you have encountered a legit Google bug. Post about it here. Only Google can help you at this juncture

Hey Neil

Wow, we are really chuffed here at Effect Digital! I guess... we have a lot of combined experience - and we also try to give something back to the community (as well as making profit, obviously)

We didn't actually know how many people used the Moz Q&A forum until recently. It seemed like a good hub to demonstrate that, not all agency accounts have to exist to give shallow 1-liner replies from a position of complete ignorance (usually just so they can link spam the comments). Groups of people, **can **be insightful and 'to the point'

Again we're just really thrilled that you found our analysis to be useful. It also shows what goes into what we do. Most of the responses on here which are under-detailed have the potential to lead people down rabbit holes. Sometimes you just have to get into the thick of it right?

I think our email address is publicly listed on our profile page. Feel free to hit us up

Ok let's have a look here.

So this is the URL of the page you want me to look at:

• https://www.nubalustrades.co.uk/

I can immediately tell you that, from my end it doesn't look like Google has even cached this page at all:

• http://webcache.googleusercontent.com/search?q=cache:https%3A%2F%2Fwww.nubalustrades.co.uk%2F (live)
• https://d.pr/i/DhmPEr.png (screenshot)

As you know I can't fetch someone else's web page as Google, but I do know Screaming Frog pretty well so let's give that a blast

First let's try a quick crawl with no client-side rendering enabled, see what that comes back with:

• https://d.pr/f/u3bifA.seospider (SF crawl file)
• https://d.pr/f/9TfNR5.xlsx (Excel spreadsheet output)

Seems as if, even without rendered crawling the words are being picked up:

• https://d.pr/i/426Ck9.png

Only the rows highlighted in green (the 'core' site URLs) should have a word count anyway. The other URLs are fragments and resources. They're scripts, stylesheets, images etc (none of which need copy).

Let's try a rendered crawl, see what we get:

• https://d.pr/f/ijprbx.seospider (SF crawl file)
• https://d.pr/f/c8ljoF.xlsx (Excel spreadsheet output)

Again - it seems as if the words are picked up, though oddly fewer are picked up with rendered crawling than with a simple AJAX source scrape:

• https://d.pr/i/y3Jv51.png

That could easily be something to do with my time-out or render-wait settings though (that being said I did give a pretty generous 23 seconds so...)

In any case, it seems to me that the content is search readable in either event.

Let's look at the homepage specifically in more detail. Basically if content appears in "inspect element" but not in "view source", **that's **when you know you have a real problem

• view-source:https://www.nubalustrades.co.uk/ - (you can only open this link with Chrome browser, it's free to download from Google)

As you can see, lots of the content does indeed appear in the 'base' source code:

• https://d.pr/i/8BzTjd.png

That's a good thing.

That being said, each piece of content seems to be replicated twice in the source code which is really weird and may be creating some content duplication issues, if Google's more simple crawl-bots aren't taking the time to analyse the source code correctly.

Go back here:

• view-source:https://www.nubalustrades.co.uk/ - (this link only works in Chrome!)

Ctrl+F to find the string of text: "issued by the British Standards Institution". Hit enter a few times. You'll see the page jump about.

On the one hand you have this, further up the page which looks alright:

https://d.pr/i/8AlJJ1.png

On the other hand you have this further down which looks like a complete mess, embedded within some kind of script or something?

https://d.pr/i/mJJaqa.png

Line 6,212 of the source code is some gigantic JavaScript thing which has been in-lined (and don't get me started on how this site is over-using inline code in general, for CSS, JS - everything). No idea what it's for or does, might be deferred stuff to boost page speed without breaking the visuals or whatever (there are many clever tricks like that, but they make the source code a virtually unreadable mess for a human - let alone a programmed bot!)

What really concerns me is why such a simple page needs to have 6,250 lines of source code. That's mental!

What we all forget is that, whilst the crawl and fetch bots pull information quickly - Google's algorithms have to be run over the top of that source code and data (which is a much more complex affair)

Usually people think that  normalizing the code-to-text ratio is a pointless SEO maneuver and in most cases, yes the return is vastly outweighed by the time taken to do it. But in your case it's actually very extreme:

• https://www.prepostseo.com/code-to-text-ratio

Put your URL in and you'll get this:

• https://d.pr/i/nXBu0S.png

I tried like 5-8 different tools and this was the most favorable result :')

It is clear that, even were the page successfully downloaded by Google, their algorithms may have trouble hunting out the nuggets of content within the vast, sprawling and unnecessary coding structure. My older colleagues had always warned me away from Wix... now I can see why, with my own two eyes

Ok. So we know that Google isn't bothering to cache the page, and that - despite the fact your content can 'technically' be crawled, it may be a marathon to do that and dig it out (especially for non-intelligent robots)

But is the content being indexed? Let's check:

• https://www.google.co.uk/search?q=site%3Anubalustrades.co.uk+%22issued+by+the+British+Standards+Institution%22
• https://www.google.co.uk/search?num=100&ei=q_MYXMj3EM_srgSNh6LYCQ&q=site%3Anubalustrades.co.uk+%22product+and+your+happy+with%22
• https://www.google.co.uk/search?num=100&ei=6vMYXPuLC4yYsAXAoKfAAg&q=site%3Anubalustrades.co.uk+%22Some+customers+like+to+have+more+than+one+balustrade%22
• https://www.google.co.uk/search?num=100&ei=CPQYXOmJFYu6tQXi8arwBA&q=site%3Anubalustrades.co.uk+%22installations+which+will+help+you+visualise+your+future+project%22
• https://www.google.co.uk/search?num=100&ei=KvQYXMyhC4LStAWopbqACg&q=site%3Anubalustrades.co.uk+%22Cleanly-designed%2C+high-quality+handrail+systems+combined+with+attention%22

Those are all special Google search queries, designed to specifically search for strings of content on your website from all the different, primary content boxes

Good news fella, it's all being found:

• https://d.pr/i/Zlb926.png

Let's make up an invalid text string and see what Google returns when text can't be found, to validate our findings thus-far:

• https://www.google.co.uk/search?num=100&ei=SfQYXJitEomwtQWRk43QDg&q=site%3Anubalustrades.co.uk+%22what+the+heck+I+don%27t+even+I+never+wrote+this+on+my+site+how+dare+you%22

If nothing is found you get this:

• https://d.pr/i/FGvT49.png

So I guess Google can find your content and is indexing your content

Phew, crisis over! Onto the next one...

If you can share a link to the site I can probably diagnose it. It's probably that the content is within the modified (client-side rendered) source code, rather than the 'base' (non-modified) source code. Google fetches pages in multiple different ways, so using fetch as Google artificially makes it seem as if they always use exactly the same crawling technology. They don't.

Google 'can' crawl modified content. But they don't always do it, and they don't do it for everyone. Rendered crawling takes like... 10x longer than basic source scraping. Their mission is to index the web!

The fetch tool shows you their best-case scenario crawling methodology. Don't assume their indexation bots, which have a mountain to climb - will always be so favourable