Welcome to the Q&A Forum
Browse the forum for helpful insights and fresh discussions about all things SEO.
The authority has probably decayed, I think it's more a case of starting over and rebuilding the authority - rather than waiting and hoping for the best. I know, it sucks when you have shelled out on a domain. But in my experience domain purchasing is really hit and miss. If you don't see an immediate difference, often you don't see one at all. Maybe others have different POVs though
If you replace Polish characters with English characters in your URL strings, as long as you redirect the old URLs (containing foreign / Slavic characters) properly to the new ones (Latin / English alphabet characters only) and as long as you update all internal and external links to those old URLs (so Google won't navigate to them internally, or from across the web) then you shouldn't get 404s
The real question is, why would you undo the 'proper' native Slavic URL encoding?
Google say you are fine to use those characters in URLs:
https://searchengineland.com/google-using-non-english-urls-non-english-websites-fine-294758
"This includes non-Latin characters in your URLs. John Mueller said “as long as URLs are valid and unique, that’s fine.” He added, “So to sum it up, yes, non-English words and URLs are fine, [and] we recommend using them for non-English websites."
Most modern web browsers will handle these characters without throwing an exception, obviously if you were to go back to ancient browsers that no one uses any more like IE1 - IE8, or NetScape or something like that - you might have problems
Google try to reflect what they think most browsers are capable of handling. Google won't show errors on such URLs if they believe that most people on most browsers would see the content correctly
Look at this Google search:
https://www.google.co.uk/search?q=%C4%99
Result #1:
Ę - Wikipedia
https://en.wikipedia.org/wiki/Ę
Ę is a letter in the Polish, Lithuanian and Dalecarlian alphabets. It is used in Navajo to represent the nasal vowel [ẽ]. In Latin, Irish, and Old Norse palaeography, ...
In Polish · History · Alternations · In Lithuanian
Result number 1 on Google contains the character "Ę" in the URL, so you know Google can index these URLs and is doing so. Not only does it not result in an error, but Google willfully chooses to index such URLs when relevant queries are processed
Let's look at another Google result, the Polish word for "lamb" aka a young sheep which you can eat!
https://www.google.co.uk/search?q=jagni%C4%99
Loads of the results contain "ę" in the URL. Seems fine to me
It may be true that Moz and some other SEO crawlers have issues interpreting some foreign characters in the URL string (ę - is but one example). But that's not true for most modern web browsers or for Google. IMO that says Moz needs and update and you don't need to change your site. Aim for what makes Google happy
I am pretty sure that's not how Meta robots tags work. If you fail to specify something, Google assumes they are allowed to index by default. By the way, search engines do not index pages which they don't think users will like or be interested in. Just because a search engine 'can' index a URL, that doesn't mean it will!
Follow directives and index directives actually operate on two entirely different sub-sets of data. Follow / nofollow directives are link-level (meaning they apply only to the hyperlinks on a page, not to the page itself). Index / no-index directives are page-level, and apply to the entire page upon which they are situated
Due to this, I don't believe they could or would interfere with each other in the way you described
Interesting experiment though. To test, I'd recommend adding index instead of removing follow. If hat doesn't make any kind of difference, it's not the issue
A good way to check would be to load one of your client's pages (which is utilising barba.js) and turn off JavaScript using the Web Developer plugin for Chrome - then reload the page and play spot the difference
If pages look very bare or nothing really loads without JS, you could have a problem. Google can penetrate and crawl JS (by using headless browsing and script execution) - but they don't do this all the time, or for everyone
I find that sites which contain more for Google to read in the non-modified source code (before scripts execute and generated items are rendered) tend to perform better in Google's SERPs (still, yes - in 2019)
I'd at least give it a try and see what happens, if it turns out that your hypothesis is wrong you can always un-disavow the links. When you upload a txt file to the disavow tool, it counts that as your total disavow efforts (so if you just upload a txt file containing these links you have spotted, you may lose previous disavow work). Be sure to download your existing disavow file so you can add to it, instead of just uploading the links you have found
A side-effect of this though, is that later you could upload your disavow again excluding those links and un-disavow them. Before you do anything, you'd want to evaluate the technical features of those links. If they are all no-followed, they won't count towards Google's rankings anyway, so no action would be required (on your part)
Usually speaking, I would suggest making your homepage more link-worthy so that it gains more backlinks over time. Since this case is so extreme, you might actually want to consider disavow (or getting those links no-followed). Followed site-wide links can negatively affect rankings, under certain circumstances
If you have regional redirects in place (e.g: detect when users are from UK vs from PL, and then redirect incorrect queries to the right site) - then you may have failed to exempt Googlebot (user-agent) from those regional redirects
Google crawls from one data centre (location) at a time. If Google follows a link on a cached version of your old site to PL content and then regional redirects intercept Googlebot and 'incorrect' the crawl path, you can get stuff like this happening
Although regional redirects are often needed for users, it's best to exempt Googlebot from them so it doesn't get bounced around thus gaining an incomplete view of the site
The easiest way to do this would assuredly be to export all the links to a table and manipulate the data in something like Microsoft Excel. I am pretty sure that Pivot tables could generate the data-set you wanted, and then you could even make graphs and charts from it and stuff. If you can share the raw data then I can post a step by step
If you want to disavow and redirect at the same time, you probably wouldn't want to use a 301 which passes SEO authority (and negative equity) along to the resultant page. I'd probably use a 302 or a 307, and then disavow the linking domain (or page) in Google's disavow tool which is here. I might also try to no-index the redirecting URL, though with a redirect in place this could not be done within the HTML / source code. You'd have to deploy the no-index directive via the HTTP header instead, using X-Robots
Absolutely not (sorry); I mean exempting the Googlebot user-agent from your redirects - which will involve re-writing the flexible redirect rules that handle the regional 301s. It has nothing to do with no-follows or any other 'normal' SEO stuff, you will need a developer
This is interesting. Most data suppliers will say if scripts break, that's down to the programmer's poor use of error-handling (if/except/fallback statements). It's nice to see that with Moz, there's a little more thought
It's probably just taking Google a while to process all the changes. Really your 301s should point to the same content, not just all go to the homepage. If you had pages showing on two sites, the pages do 'really' exist on one site but weren't supposed to exist on the other. Correct the 301s so that they point from the URLs on the affected site, to the exact same pieces of content on the site where they were originally located (where they were supposed to be located)
If that fails use the HTTP header and X-robots (not no-index tags, fire the no-index directive from the HTTP header instead of the HTML) to tell Google not to index those URLs on the 'affected' website. In conjunction with that, alter the status code of all bogus URLs on the 'affected' site to 410, which is stronger than 404 (it means: GONE - not coming back, 404 just means temporarily gone but will return...)
As Joe said canonical is fine. No need to play with all the other tags, leave them alone!
Always a difficult question to answer! This actually depends upon what you're paying in terms of development, too. A junior or intermediate developer will take much longer to do things than a senior WordPress specialist as the junior will have to research everything they are doing, in addition to carrying out the work. A senior developer will cost much more per hour, but may finish the work significantly faster.
Instead of just thinking in hours only, you want to be considering the overall time/cost. If you pay a senior developer 3x more (hourly) but they believe they can be finished in 25% of the time (and are willing to commit to that) - then you just need to change the type and calibur of resource you are working with. Always do the math.
Here you actually have a lot of stuff going on. On the old page, although the nav is blue - it 'feels' as if the page's primary colour is yellow. On your new page, yellow is pretty much reserved for stand-out CTAs and the rest of the design elements are brought in line and re-styled to match the nav (blue).
The image carousel is altered significantly so that it actually looks like a proper image carousel, rather than an image with random thumbnails under it. That's a good move but again, every change is a new brick or a new layer of paint for the system.
You're altering the sidebar significantly, removing the form and clip-art to replace it all with CTA buttons and images of real people which inspires more confidence.
You have whole sections of new content, tables of data under the main content. That stuff didn't exist before and you're also now pulling in reviews which you weren't doing before. All of these data hard-points have to be found or created, linked and affixed to the new layout.
Considering that you're getting actual development work _and _also re-design all in one for 19 hours work - to me that doesn't sound too bad. A myriad of little things can take hours to track down and alter, to stabilise and get looking just right.
If you want to haggle maybe ask if it could be done in 17 hours but much less than that would be taking the Michael a bit (IMO)
As stated, some devs with front-end design experience and a WP specialism may be able to do this in a few hours, but you'd probably pay a far higher rate. If in doubt, find more experienced WP developers and get some comparative quotes
I think the new design is better from an SEO perspective (the granular, tabular data is something Google will latch onto and they'll like the reviews being pulled in to... MAKE SURE they're marked up with schema). It's also better from a CRO (conversion-rate optimisation) perspective IMO, so I'd advise going ahead with it
You wanna' be really careful here. From the sounds of it you had a collection of 'web pages' under an old umbrella site (which contains loads of other stuff too) and you are 'extracting' those web pages and turning them into a new website. For most intents and purposes, a domain 'is' a website
If the old site is staying live with other stuff still on it, and only part of it is migrating - obviously you DON'T want to tell Google that the whole umbrella site is 'becoming' a much narrower site on a new domain. That's inaccurate information, and will kill off the main site's performance
Another issue. Currently your 'site section' which will become its own site, is receiving SEO authority through the main domain's backlinks, then transferred through the internal link structure. If the old site is staying live, most of it won't be redirected to the new 'extract' site. The internal linking from the main site will also be gone, which means a performance reset for those section of URLs is quite darn likely
There is some potential, that I got this exactly the wrong way around. Maybe you are saying that a previously external site is coming 'under' the big umbrella. That would be much easier to deal with!
In this second scenario, yes I'd recommend telling Google that one whole domain is becoming part of another domain using the domain migration tool within search console. I have seen migration projects succeed without this, but I've also seen Google's algos throw wobblies so... Yeah, I'd say do it to be safe
The old domain needs to still exist, with a hosting package - in order to perform your redirects. Redirects are handled by the .htaccess or web.config file(s) and they need hosting to live on. Without it, all your redirects will die. If you don't keep the redirects live for 6-12 months, prepare to lose some SEO authority as it won't have all translated across by then
Your new pages, regardless of whether they are on an external or internal domain, should be listed in an XML sitemap. Wherever they are moving to, that domain's XML sitemap needs to have the newly spawned URLs in
Hope that helps
Delete all the other content on the page 
Nah just kidding. There's really no way to achieve that, other than writing a Meta Description which Google would prefer to render, against the rest of the page's content
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:
You can see the reference for your footer here:
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:
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:
And you wanted to make a link, that deep-links people just to this part here:
Now technically if you inspect that frame, there is something with a decent ID to hook onto:
So this link should technically work:
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:
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:
Let's use that text ("Folsom Chamber of Commerce") as an example. Now go to the basic source code:
Guess what?
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.
Your problem is that you have two different sites loading on the same URL. If you are returning both the mobile and desktop / laptop site on the same URL, you would be expected to be using responsive design. In-fact, you may have re-invented another different way to implement responsive design which is probably, slightly less fluid yet slightly more efficient :')
Since your mobile and desktop pages both reside on exactly the same URL, I'd test the page(s) with this tool (the mobile friendly tool) and this tool (the page-speed insights tool). If Google correctly views your site as mobile friendly, and if within PageSpeed insights Google is correctly differentiating between the mobile and desktop site versions (check the mobile and desktop tabs) then both URLs should canonical to themselves (self referencing canonical) and no alternate tag should be used or deployed. Google will misread the alternate tag, which points to itself - as an error. That tag is to be used when your separate mobile site (page) exists on a separate URL, like an 'm.' subdomain or something like that
Imagine you are Googlebot. You are crawling in desktop mode, load the desktop URL version and find that the page says, it (itself) is also the mobile page. You'd get really confused
Check to see whether your implementation is even supported by Google using the tools I linked you to. If it is, then just use self referencing canonical tags and do not deploy alternate tags (which would make no sense, since both versions of the site are on the same URL). When people build responsive sites (same source code on the same URL, but it's adaptive CSS which re-organises the contents of the page based upon viewport widths) - they don't use alternate tags, only canonicals
Since your situation is more similar to responsive design (from a crawling perspective) than it is to separate mobile site design, drop the alt
Just seems overly complex and like there's way more in there than there needs to be
I'd go with something that 'just' does what you have stated that you want to achieve, and nothing else
User-Agent: *
Disallow: /wp-content/plugins/
Disallow: /comments
Disallow: /*?s=
Disallow: /*&s=
Disallow: /search
See if that helps
Another thing that affects the effectiveness of a 301 redirect, is the 'similarity' of the content (in machine terms, I'm talking about Boolean string similarity). If the content on both pages is highly similar (say, 75% similar) then most of the SEO authority will transfer across. If the content is not very similar at all, what you are doing is replacing 'proven' content with a new, unknown quantity which is a risk to Google. As such, the new content will have to prove itself
hopefully it will prove useful...
