This is a good URL design.
The URLs are can be persistent (they contain no parts that are likely to change; name changes are rare).
The URLs are descriptive (users can read the URL and they’ll get an idea what the page is about).
The URLs are browsable (users can remove path segments from right to left, and they’ll get no 404).
It’s also good that they don’...
Wow. This is too big a topic to cover completely, so I will try and focus on your question with something of a mini-tutorial.
When you do a site:mydomain.com in Google, you will see your site listed somewhat in order of importance according to what Google has found. Often your sites home page is listed first, but not always. If it is not, do not worry about ...
There are 2 things here:
There is absolutely no issue in terms of ranking when it comes WP pages vs post. As long as you got rich content either should be fine.
Pages vs Post could come under your website planning and future consideration. For general understanding, pages are generally for website page and posts are for the ...
The double slash has a meaning when it is used in resource URL's. For example, when it is user in CSS for an URL of a background image:
background : url("//example.com/a/b/c/d.png");
Here it means this background image is fetching from a different domain other than the domain of the present web page. Or in other words, http:// can be ...
Before I get too far down the rabbit hole should I make this kind of content as pages?
Doesn't really matter as long as you remain consistent with it. Personally, I would make this content into a custom post type and that would allow for custom taxonomies to better handle navigation and SEO issues, but this isn't necessary.
The fear is that eventually ...
Your folder structure looks fine, nothing to worry about there. However, you might not want to go any deeper that that, as research by moz.org says:
The quantity of subfolders in a URL appears to correlate to rankings. URLs with fewer trailing slashes perform better than those with more. Additionally, search engine representatives have recommended that ...
This is too much opinion but I'll answer anyway. You are doing too much description in the URL. A restaurant is a category so no need to prefix it with "category". restaurant-tavern-bistro ... we get it ... don't throw the kitchen sink in there, too. example.be/restaurants, we get it.
But are all tavern's restaurants? Will you be cluttering drink-only ...
fileadmin contains files that can be uploaded, managed and used in the TYPO3 backend, such as images, PDF, videos etc. This can be named differently or even split up into several storages, but fileadmin is the default. So the files in fileadmin are files that can be changed by the editor in the TYPO3 backend. You can name the subdirectories any way you want. ...
TWiki stores content directly in the file system. Look for twiki/data and twiki/pub directories.
The twiki/data has directories representing TWiki webs (workspaces). Those webs contain files representing the wiki page data. There is a .txt file with page content, and a .txt,v file with page history. For example, page SlicedBread in the Eng web will be at ...
you have in your source code the JSON-LD snippet with the type "SiteNavigationElement" twice, the first beginning in the line 119, the second beginning in the line 163 - thats why Google recognizes it twice. This one:
The goal of a URL is not to mirror your site structure. There are four goals of good URLs:
Uniquely identify the content of the page
Sites include a numeric ID in the URL because it works well with databases. The numeric id is a database key for the content. This site works that way. When that is the case, the ...
Google doesn't put much (if any) SEO weight on the words in your URL path. Using just a number is not going to hurt your search engine rankings directly.
Using words in your URLs does have some indirect benefits for SEO and usability. See Are keywords in URLs good SEO or needlessly redundant? for full details. In summary:
They can help click through rate ...
As mentioned, some servers are setup to ignore a double slash in the URL path, but Amazon S3 static hosting will not. If you want to handle/ignore them in that case, you can use Redirection Rules in the properties panel.
If you want to ignore a double slash following the domain name then you could use something like this:
The internal links does matter.
The number of internal links pointing to a page is a signal to search
engines about the relative importance of that page. If an important
page does not appear in this list, or if a less important page has a
relatively large number of internal links, you ...
If you remove pages you generally don't want to redirect them to a central location. When you do this, Google considers them "soft 404" and tries to treat them the same way as if you had just removed them and let them be 404 pages. I wouldn't redirect any pages to a sitemap or home page.
The other possibility would be to use the meta rel canonical tag:
For your site architecture, you can take inspiration from famous newspapers websites. In general,
articles on these websites are categorized by theme (all economics articles in the same category, all
sport articles in the same category, etc.). If your site has many articles, you can also create
subcategories like for example football, tennis, golf, etc. ...
If you can SSH into your host log in and check the folder and file permissions on that sub-directory. they should be normal but may have gotten changed inadvertently.
You can use .htaccess to define the default page but it doesn't sound like locating it is the issue here.
Check that you have no other strangely named files. Try deleting everything in the ...
It’s a good practice to make URLs browsable. But for usability, not necessarily for SEO.
I think there is no reason to assume that there will be any kind of SEO consequence. Most bots will probably never try to visit new URLs by removing path segments from right to left, but even if some bots try it, they can hardly expect this to work for all sites.
So as ...
Question 1: Using a Page for a top-level category can be beneficial for SEO, because your Site B scenario suggests that each category - both parent and child - is showing only a collection of products. Since the parent category will contain products that are also in the child categories, search engines may see the parent and child categories as duplicate ...
If a webmaster isn't using an index file in a directory, a person visiting that directory url will see all of the folders and files in that directory.
To protect the code of a website, a webmaster should almost always be adding this to their htaccess file:
The above code prevents people from seeing the contents inside of a directory.
Creating duplicate content will surely affect your SEO for both posts badly.
However if the URL of the posts involved are different and there is a difference, even if its only a sentence difference, between the content this won't affect you as one will rank more than the other.
If the URLs and the content are exactly the same, it will cause a bad effect.
Let's pretend for a second that the answer to your question is 'yes' and that duplicate content is okay (I agree with the idea that it is probably more 'tolerated' on larger sites, but in general we all know it is bad).
What would happen then is that you would have a bunch of pages ranking for the same query, cannibalizing each other and while you could ...
This question is not about SEO but about ranking in search results pages of search engines.
If a page has a lot of traffic and it links to another page inside the same domain, it can push the latter higher in the search results pages. This is not a SEO boost. The SEO score of the page that receives the link is not raised, what is raised is its ranking in ...
From an SEO perspective, keeping everything on a single website is preferable to duplicating content. You're correct that having two separate websites promoting a single book means those two sites are competing; that you shouldn't have identical product details on two websites; and that leaving some information off the "main" website weakens its authority.
Much of this depends upon what you are expecting to achieve. You do not say in your question.
For example, are you looking for a job, freelance work, or to market yourself or expertise for other purposes, etc? Are you using the blog for this purpose?
Certainly a profile page on the blog is appropriate and adds credibility within search engines. Profiles ...
To be honest, I think this is really just going to boil down to personal opinion.
e.g. example.com/~about. This is my favourite at the moment.
However using a tilde (~) in such a way could end up conflicting with Apache's per-user web directories which is common on shared Apache servers.
With using an additional path segment, ...
I think you could do it without any major problems. The only things I can think of that could go wrong are:
If you need a directory with that name on your server, it may be difficult to create and work with. Command line programs use the dash (-) to specify flags and special arguments. They don't like working with files and directories that start with ...
This is an question how you want to make it, there is nothing you must to have.
I recommend to have your template files outside of /fileadmin I use often /template for this.
As next step you should create folders for an structure you understand.
Many customers try to place the files like the navigation structure, so they find the content belongs to them.
What keywords did you want the page optimised for in organic search?
You can name a page you don't care about whatever you like. Your primary channel appears to be e-mails rather than search engines. Focus on user experience and associated metrics instead of SEO.
If you wanted it to show up on a search for 'Your company landing page' then optimise around ...
It appears you've got a good grasp on how to lay out the breadcrumbs and get pages rated. So I'll skip commentary in those areas.
On-page SEO is something that doesn't just rely on experience or best practice - but testing. Set up two different structures and test them extensively. Create backlink profiles of roughly equal worth and figure out what works ...