I use SW 5.10 and as see as following there is standard markup (microdata) as follows:
<meta itemprop="brand" content="xxxx"/>
<meta itemprop="name" content="xxxx® xxx xxx1.4 Caps (300 xxx)"/>
<meta itemprop="weight" content="0.41 kg"/>
<div itemprop="offers" itemscope itemtype="http://schema.org/Offer" class="buybox--inner">
I do a heavy search in SO and see json+ld is better for SEO and google so I decide to use a plugin for create json+ld and now is good as follows:
<script type="application/ld+json">
{
"#context": "http://schema.org/",
"#type": "Product",
"name": "xxxx 1.4 Cxxxaps (300 xxx)",
"image": xxxx.jpg",
"mpn": "93331FIT",
"brand": {
"#type": "Thing",
"name": "xxxxx"
now main problem is that both microdata and json ld structure is present for all products that with two reason this is not good choice:
1) I search in SO and found for one product this is not good to present both microdata and json ld.
2) json ld is better for google
so as a result I need to remove standard shopware 5 markup (microdata) to google search console not detects two same products on one page as follows:
How I can remove this microdata for shopware to google search console
detect just json ld?
You need to overwrite every template file that includes the "old" syntax. This is nearly the complete detail page, since those rich snippets are included directly near their use.
e.g.:
https://github.com/shopware/shopware/blob/5.5/themes/Frontend/Bare/frontend/detail/content/header.tpl#L19
I don't think that there is any significant change in the seo performance of your site by changing this. And it could possibly break every template of plugins.
Related
StackOverflow has some good comparisons of Microdata, RDFa, and JSON-LD, especially in answers by "unor" in 2014, 2015, 2015, and 2016.
Google specifically states "Google recommends using JSON-LD for structured data whenever possible." But when I look at the page source of a Google search, the very first content of the page is:
<!doctype html>
<html itemscope="" itemtype="http://schema.org/SearchResultsPage" lang="en">
The itemscope and itemtype attributes in the <html> tag are microdata. So why is Google using microdata when it tells us to use JSON-LD? Is there something about the use of structured data in that tag that makes it unsuitable for JSON-LD?
Is it legitimate to set the canonical link to the pound symbol as shown below, or am I required to enter a physical page name?
<link rel="canonical" href="#">
When testing this, the pound setting does not generate a validation error (ala #development=1). In my scenario, the page using this layout file will not have an alternate "regular HTML" version. The only version will be the AMP HTML version.
For additional context, I'm experimenting with an MVC site that will use AMP HTML. To keep my layout file simple, I'd prefer to use the pound symbol rather than extracting the child page name and applying that to the href attribute. I know how to apply the URL to the partial view via code like so:
<link rel="canonical" href="#HttpContext.Current.Request.Url.AbsoluteUri">
I'm just curious if it's legitimate AMP HTML to use the pound symbol instead. Thank you.
From the documentation:
Required markup
AMP HTML documents MUST:
contain a <link rel="canonical" href="$SOME_URL" /> tag inside their head that points to the regular HTML version of the AMP HTML
document or to itself if no such HTML version exists.
So instead of using href="#", you should have it point to itself in order to stay consistent with the AMP specifications.
Validation is evolving, the validator doesn't catch all issues today. The issue with using "#" or any relative URL is that when this document is served elsewhere, such as cdn.ampproject.org, that relative URL will no longer point to your intended canonical. You should instead use an absolute URL <link rel=canonical href="URL">.
Can I make the generated HTML page from my DDoc-marked-up D program use richer coloring and type-setting? The default is black-and-white.
I'm currently calling DMD as
dmd -debug -gc -unittest -D -Dd$OUTPUT_DIR
Well, you should probably read through http://dlang.org/ddoc.html to get some of the details, but ultimately, what you need is a css file which tells it how to present the page. That can be set via the DDOC macro.
What I'd suggest doing is taking a look at https://github.com/D-Programming-Language/dlang.org, which contains the code for dlang.org - including the ddoc stuff. In particular, you want to grab std.ddoc along with the css, images, and js folders (as they are all referenced by std.ddoc). If you then give std.ddoc to dmd as part of your documentation build and have those folders in the parent directory of the documentation, the generated documentation should end up looking like the documentation on dlang.org. If you want to put the folders elsewhere, then just tweak the paths to them in std.ddoc.
If you want to change what the documentation looks like, just adjust std.ddoc and the css files accordingly. At that point, it's html and css stuff that you're dealing with, so you'll have to have some clue how those work to make the necessary changes to either the macros in std.ddoc or to the css files themselves. And of course, if you want to do anything with the js files, you'll need to know javascript. You can strip out all of the js and images if you want to. They're just what's used for dlang.org, but again, you'll have to have some clue how html and friends work to know what to do with that. I'm not particularly well versed in any of that, so when I've generated documentation, I've typically made only minimal changes to what dlang.org uses, but all I've typically been looking for is to get more legible colors than the default rather than anything specific.
Sorry that I can't be more specific or helpful than that, but the best that I've done with it is stumble through it enough to get pages looking like dlang.org, since I know next to nothing about web development. Hopefully this will point you in the right direction though.
Something else that you might want to look into is ddox, which uses ddoc comments to generate better looking documentation than dmd does. And it's likely that dlang.org will be switching to using ddox-generated documentation sometime in the relatively near future (some of the details still need to be sorted out, so I don't know when exactly, but that's the current plan). So, using ddox may ultimately end up becoming more common than using dmd to generate the documentation.
You can create your own .ddoc config file in which you override or create new ddoc macros to use class names and id's. Then you can style the page using CSS.
Sample .ddoc file containing custom CSS, Notice the theme.css file in the head HTML section:
DDOC = <!DOCTYPE HTML>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<link type="text/css" href="theme.css" rel="stylesheet" media="all" />
<title>$(TITLE)</title>
</head>
<body>
<h1>$(TITLE)</h1>
$(BODY)
</body>
</html>
H2 = <h2>$0</h2>
H3 = <h3>$0</h3>
STRONG = <strong>$0</strong>
EM = <em>$0</em>
DDOC_DECL = $(H2 $0)
DDOC_DECL_DD = <div class="declaration-description">$0</div>
DDOC_CLASS_MEMBERS = <div class="class-members">$0</div>
DDOC_SUMMARY = $(P $0)
DDOC_DESCRIPTION = $(P $0)
DDOC_MEMBERS = <div class="members">$0</div>
DDOC_ENUM_MEMBERS = <div class="enum-members">$0</div>
DDOC_MODULE_MEMBERS = <div class="module-members">$0</div>
DDOC_STRUCT_MEMBERS = <div class="struct-members">$0</div>
DDOC_TEMPLATE_MEMBERS = <div class="template-members">$0</div>
This file should be saved somewhere and added to the sc.ini file (in the case of Windows) or the dmd.conf file (in the case of Mac/Linux) like this:
DDOCFILE=myproject.ddoc
Then the next time you compile using -D, HTML is read from the custom ddoc macros instead of the built-in stuff and viola, you have style-able class names and id's to use with CSS.
Here's a preview of pretty documentation using a custom style-sheet and macros: http://htmlpreview.github.io/?https://github.com/kalekold/dunit/master/docs/dunit/toolkit.html
HTML files: https://github.com/nomad-software/dunit/tree/master/docs/dunit
Full ddoc macro listings can be found here: http://dlang.org/ddoc.html
Before asking I want to say that this is not a duplicated topic. I've already tried with:
Pwarelis' fork
Tcrosen's one
Gudbergur's code
...and many others, and I also read lots of Q&A, but none of them is what I am looking for.
All what I tried works with predefinite string sources, but when I do the next step: AJAX remote source, it is just showing no results on the dropdown list.
UPDATE - My code (don't understand why negative votes. Well written, well strucuted ;))
The html file
<html>
<head>
<link href="./bootstrap/css/bootstrap.css" rel="stylesheet" type="text/css" />
</head>
<body>
<input id="myElement" class="typeahead" type="text">
<script src="./js/jquery.js"></script>
<script src="./bootstrap/js/bootstrap-typeahead.js"></script>
<script language="javascript">
$('#myElement').typeahead({
ajax: '/php/ajax.php'
});
</script>
[...]
The ajax.php file:
<?php
echo "[{ id: 1, name: 'Terry'}, { id: 2, name: 'Mark'}, { id: 3, name: 'Jack'}]";
?>
It's not an AJAX issue, because it is working in other cases at the same machine.
What may I try to fix it?, I am really crashing up my head since a few days. Thanks for reading.
People who vote negative without even knowing the right answer should think a bit before acting. If someone needs a real nice/working/magic autocomplete script, here wo go:
Real good Autocomplete Script
Description: This adds a pulldown menu of suggested values to a text field. The user can either click directly on a suggestion to enter it into the field, or navigate the list using the up and down arrow keys, selecting a value using the enter key. The values for the suggestion list are to provided as XML, or as JSON (by a PHP script, or similar).
Thanks those who made negative points disappear ;)
hey set header of json in you php file
use header('Content-Type: application/json');
for more info on header plese visit here(stackoverflow question) ad for example visit here(www.funnenjoy.com)
Each blog post on my site -- http://www.correlated.org -- is archived at its own permalinked URL.
On each of these archived pages, I'd like to display not only the archived post but also the 10 posts that were published before it, so that people can get a better sense of what sort of content the blog offers.
My concern is that Google and other search engines will consider those other posts to be duplicate content, since each post will appear on multiple pages.
On another blog of mine -- http://coding.pressbin.com -- I had tried to work around that by loading the earlier posts as an AJAX call, but I'm wondering if there's a simpler way.
Is there any way to signal to a search engine that a particular section of a page should not be indexed?
If not, is there an easier way than an AJAX call to do what I'm trying to do?
Caveat: this hasn't been tested in the wild, but should work based on my reading of the Google Webmaster Central blog and the schema.org docs. Anyway...
This seems like a good use case for structuring your content using microdata. This involves marking up your content as a Rich Snippet of the type Article, like so:
<div itemscope itemtype="http://schema.org/Article" class="item first">
<h3 itemprop="name">August 13's correlation</h3>
<p itemprop="description" class="stat">In general, 27 percent of people have never had any wisdom teeth extracted. But among those who describe themselves as pessimists, 38 percent haven't had wisdom teeth extracted.</p>
<p class="info">Based on a survey of 222 people who haven't had wisdom teeth extracted and 576 people in general.</p>
<p class="social"><a itemprop="url" href="http://www.correlated.org/153">Link to this statistic</a></p>
</div>
Note the use of itemscope, itemtype and itemprop to define each article on the page.
Now, according to schema.org, which is supported by Google, Yahoo and Bing, the search engines should respect the canonical url described by the itemprop="url" above:
Canonical references
Typically, links are specified using the element. For example, the
following HTML links to the Wikipedia page for the book Catcher in the
Rye.
<div itemscope itemtype="http://schema.org/Book">
<span itemprop="name">The Catcher in the Rye</span>—
by <span itemprop="author">J.D. Salinger</a>
Here is the book's <a itemprop="url"
href="http://en.wikipedia.org/wiki/The_Catcher_in_the_Rye">Wikipedia
page.
http://schema.org/docs/gs.html#advanced_enum
So when marked up in this way, Google should be able to correctly ascribe which piece of content belongs to which canonical URL and weight it in the SERPs accordingly.
Once you've done marking up your content, you can test it using the Rich Snippets testing tool, which should give you a good indication of what Google things about your pages before you roll it into production.
p.s. the most important thing you can do to avoid a duplicate content penalty is to fix the titles on your permalink pages. Currently they all read 'Correlated - Discover surprising correlations' which will cause your ranking to take a massive hit.
I'm afraid but I think it is not possible to tell a Search Engine that a specif are of your web page should not be be indexed (example a div in your HTML source). A solution to this would be to use an Iframe for the content you do not what search engine to index, so I would use a robot.text file with an appropriate tag Disallow to deny access to that specific file linked to the Iframe.
You can't tell Google to ignore portions of a web page but you can serve up that content in such a way that the search engines can't find it. You can either place that content in an <iframe> or serve it up via JavaScript.
I don't like those two approaches because they're hackish. Your best bet is to completely block those pages from the search engines since all of the content is duplicated anyway. You can accomplish that a few ways:
Block your archives using robots.txt. If your archives in are in their own directory then you can block the entire directory easily. You can also block individual files and use wildcards to match patterns.
Use the <META NAME="ROBOTS" CONTENT="noindex"> tag to block each page from being indexed.
Use the X-Robots-Tag: noindex HTTP header to block each page from being indexed by the search engines. This is identical in effect to using the ` tag although this one can be easier to implement since you can use it in a .htaccess file and apply it to an entire directory.