Marketing

<div class="prose prose-hyva max-w-none"><p>Set up discount campaigns and coupon codes that apply in the cart – e.g. "10% off orders over €50".</p><p>Create cart price rules under <em>Marketing &gt; Cart Price Rules &gt; Add New Rule</em>. They only take effect in the cart/checkout, not already in product listings – the customer sees the regular price until the rule kicks in by meeting the conditions (or entering the code).</p> <h3>Rule Information</h3> <ul> <li><strong>Websites / Customer Groups:</strong> who the rule applies to at all – can be restricted to e.g. "NOT LOGGED IN" for pure new-customer promotions.</li> <li><strong>Coupon:</strong> "No Coupon" (rule applies automatically to everyone once conditions are met) or "Specific Coupon" with an actual code customers must enter in the cart.</li> <li><strong>From/To:</strong> a start date and optional end date for when the rule is active.</li> <li><strong>Priority:</strong> with several simultaneously valid rules, priority determines the order they're applied in; <strong>Discard subsequent rules</strong> prevents further, lower-priority rules from also applying.</li> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/ruleinformations6kategorie.png}}" alt="loading="lazy"" /> </ul> <h3>Conditions</h3> <p>On the <strong>Conditions</strong> tab, you build the condition the rule applies under using a building-block approach – e.g. "Subtotal is greater than 50" or "Category is 15 AND Qty in cart is greater than 2". Multiple conditions can be nested with AND/OR logic.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/conditions6kategorie.png}}" alt="Conditions" /> <h3>Actions</h3> <p>On the <strong>Actions</strong> tab you define what happens: <strong>Apply</strong> controls the discount type (percentage, fixed amount off the cart, fixed amount per item, or a shipping discount), <strong>Discount Amount</strong> its size, and optionally <strong>Buy X Get Y Free</strong> (e.g. "3 for 2" promotions) via the <strong>Buy X quantity</strong>/<strong>Free Y quantity</strong> fields.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/actions6kategorie.png}}" alt="Actions" /> <h3>Generating multiple coupon codes</h3> <p>Under <strong>Coupon Qty</strong> on the "Coupon" tab, you can automatically generate multiple distinct codes for one campaign if needed (e.g. for an influencer campaign with individual, trackable codes per partner) – exportable as CSV.</p> <p><strong>Practical tip:</strong> always test new rules with a test account in your own store and a test order first, before communicating the coupon code publicly – a typo in the conditions can otherwise lead to an unintentionally large discount, or a code that doesn't work at all.</p> <h3>Usage limits per coupon and per customer</h3> <p><strong>Uses per Coupon</strong> (Rule Information) limits how many times a single code can be redeemed in total – leave it blank for unlimited use. <strong>Uses per Customer</strong> additionally limits redemptions per individual customer account, regardless of how many different codes exist for the same rule. Together, both fields stop a coupon code that's been published somewhere (e.g. a voucher portal) from being used an uncontrolled number of times.</p> <h3>Discount label shown to the customer</h3> <p>On the <strong>Store Labels</strong> tab you enter a text (<strong>Label for All Store Views</strong>, optionally overridable per store view) that's displayed to the customer in the cart and at checkout as the name of the discount line – e.g. "Summer Discount" instead of an internal, technical rule name. If left blank, Magento falls back to the <strong>Rule Name</strong> from Rule Information.</p> <h3>Free shipping as its own action</h3> <p>Independent of the actual discount type (<strong>Apply</strong>/<strong>Discount Amount</strong>), the <strong>Free Shipping</strong> field on the Actions tab determines whether the rule also grants free shipping: "No", "For matching items only" (only the items that meet the conditions), or "For shipment with matching items" (the entire shipment becomes free as soon as at least one matching item is in the cart). This lets you model something like "10% off + free shipping over €80" in a single rule.</p> <h3>Format of auto-generated codes</h3> <p>When generating multiple coupons (see <strong>Coupon Qty</strong>), additional fields control what the generated codes look like: <strong>Code Length</strong> (number of characters), <strong>Code Format</strong> (Alphanumeric, Alphabetical, or Numeric), <strong>Code Prefix</strong>/<strong>Code Suffix</strong> (e.g. a fixed prefix like "SUMMER-"), and <strong>Dash Every X Characters</strong> for automatic dash grouping (e.g. "AB12-CD34"). This makes it easier later to tell which codes belong to which campaign.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/managecoupon6kategorie.png}}" alt="CouponQty" /> </div>

<div class="prose prose-hyva max-w-none"><p>Manage newsletter sign-ups, export subscribers, and configure the basic sending settings.</p><p>You'll find newsletter subscribers under <em>Marketing &gt; Newsletter Subscribers</em>. The list shows status (Subscribed/Unsubscribed/Unconfirmed/Not Active) and sign-up date for each contact – exportable as CSV, e.g. for an external email marketing tool. The <strong>Delete</strong> bulk action lets you remove multiple entries at once, e.g. after a GDPR deletion request.</p> <h3>Basic settings</h3> <p>Under <em>Stores &gt; Configuration &gt; Customers &gt; Newsletter</em> you can configure, among other things:</p> <ul> <li><strong>Allow Guest Subscription:</strong> whether guests without a customer account can subscribe too.</li> <li><strong>Need to Confirm:</strong> enable double opt-in – practically mandatory under EU law (a confirmation email with a confirmation link after sign-up, before the contact actually counts as "Subscribed").</li> <li><strong>Success Email Sender/Template</strong> and <strong>Unsubscribe Email Sender/Template</strong>: which emails get sent after a successful sign-up or unsubscribe.</li> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/subscription6kategorie.png}}" alt="Grundeinstellungen" /> </ul> <h3>Limits of the native feature</h3> <p>Magento itself mainly offers subscription management, not a full-fledged newsletter editor or convenient campaign sending. The native feature under <em>Marketing &gt; Newsletter Templates</em> (creating templates) and <em>Newsletter Queue</em> (scheduling sends) exists functionally but is very basic – no drag-and-drop editor, no A/B testing, no automated trigger campaigns (e.g. cart abandonment reminders).</p> <h3>In practice</h3> <p>For professional campaigns the subscriber list is therefore usually exported to, or continuously synced via API with, a specialized tool such as Klaviyo, Mailchimp or Brevo – these tools bring their own editors, automations and analytics that go far beyond Magento's built-in capabilities.</p> <h3>Creating a newsletter template</h3> <p>Under <em>Marketing &gt; Newsletter Templates &gt; Add New Template</em> you create a template: <strong>Template Name</strong> (internal label), <strong>Template Subject</strong> (subject line), <strong>Sender Name</strong>/<strong>Sender Email</strong> (sender identity), and <strong>Template Content</strong> for the actual HTML content, where you can use Magento variables such as <code>{{customer.email}}</code>. Use <strong>Preview Template</strong> to check the result before sending.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/templates6kategorie.png}}" alt="Newsletter-Vorlage" /> <h3>Scheduling delivery via the newsletter queue</h3> <p>A finished template is moved into a send queue (<em>Marketing &gt; Newsletter Queue</em>) via the <strong>Queue Newsletter</strong> button, where you set the <strong>Start Time</strong> and the relevant <strong>Stores</strong>. Actual sending, however, doesn't happen instantly – it runs through the <code>newsletter_send_all</code> cron job. If cron isn't running regularly, a scheduled queue stays stuck at status "Not Sent" even after its start time has passed.</p> <h3>Configuring the sender identity</h3> <p>The sender identities selectable in newsletter templates come from <em>Stores &gt; Configuration &gt; General &gt; Store Email Addresses</em> (fields such as <strong>Sender Name</strong>/<strong>Sender Email</strong> for "General Contact", "Sales Representative", etc.) – the same configuration area also used for order confirmations and other system emails. A credible, dedicated sender address with properly configured SPF/DKIM reduces the risk of landing in the spam folder.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/general6kategorie.png}}" alt="Absenderidentitätkonfigurieren" /> <h3>Error analysis: Newsletter Problems Report</h3> <p>Under <em>Reports &gt; Newsletter &gt; Newsletter Problems Reports</em>, Magento lists failed deliveries along with the email address and error message for each send attempt. This helps you identify permanently undeliverable addresses (bounces) and remove them from the subscriber list if needed, instead of producing the same error on every send.</p></div>

<div class="prose prose-hyva max-w-none"><p>URL structure, meta tags and sitemap settings that Magento provides in the backend by default.</p><p>The basic SEO settings are under <em>Stores &gt; Configuration &gt; Catalog &gt; Catalog &gt; Search Engine Optimization</em>:</p> <ul> <li><strong>Use Web Server Rewrites:</strong> should be set to "Yes" so readable URLs like <em>/category/product.html</em> are used instead of technical parameter-based URLs (<em>catalog/product/view/id/123</em>) – essential for SEO and usability alike.</li> <li><strong>Product/Category URL Suffix:</strong> the file extension of the URLs (usually ".html").</li> <li><strong>Generate "category/product" URL Rewrite Key based on:</strong> whether URL keys are generated manually or automatically from the name.</li> <li><strong>Redirect to CMS Page for URL with slash in the end:</strong> behavior for URLs ending with a trailing slash.</li> </ul> <h3>Meta tags per product/category/CMS page</h3> <p>You maintain meta title, meta description and meta keywords directly in the respective product, category, or CMS page form under the "Search Engine Optimization" or "Content" tab – Magento Open Source has no central place to edit all meta tags at once (SEO extensions with meta templates, which automatically apply patterns like "{{name}} – Buy Now | My Store" across many products at once instead of maintaining each individually, fill that gap).</p> <h3>301 redirects</h3> <p>If a URL key changes (e.g. because a product name was revised), Magento automatically creates a 301 redirect from the old to the new URL (controllable via the <strong>Create Permanent Redirect for old URL</strong> checkbox in the respective form) – important so already linked or indexed URLs don't turn into a 404.</p> <h3>Robots meta tag</h3> <p>Under <em>Stores &gt; Configuration &gt; Design &gt; Search Engine Robots</em> you control the global robots.txt as well as the default value for the robots meta tag (index/noindex, follow/nofollow) – individually overridable at the product, category and CMS page level.</p> <h3>XML sitemap</h3> <p>Under <em>Marketing &gt; SEO &amp; Search &gt; Site Map</em> you create an XML sitemap that tells search engines about your full page tree – important so new products and categories get crawled reliably. Use <strong>Add Sitemap</strong> to set the filename and storage path; under the <strong>Generation Settings</strong> tab you can set up a recurring cron job for automatic generation, instead of having to regenerate the sitemap manually. What actually ends up in it is its own, more detailed topic – see the next chapter.</p> <h3>Enabling canonical tags</h3> <p>The same configuration section (<em>Stores &gt; Configuration &gt; Catalog &gt; Catalog &gt; Search Engine Optimization</em>) contains two often-overlooked toggles: <strong>Use Canonical Link Meta Tag For Categories</strong> and <strong>Use Canonical Link Meta Tag For Products</strong>. Both should be set to "Yes" – they make Magento report a single, unambiguous "main URL" as canonical to search engines for filtered category views (layered navigation) and for products linked in multiple categories, avoiding duplicate-content issues.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/searchengine6kategorie.png}}" alt="Canonical-Tags" /> <h3>Maintaining manual URL redirects</h3> <p>Under <em>Marketing &gt; SEO &amp; Search &gt; URL Rewrites &gt; Add URL Rewrite</em> you can also create redirects that Magento doesn't generate automatically – for example for old URLs from a previous shop system, or for marketing landing pages. Key fields: <strong>Request Path</strong> (the old URL being requested), <strong>Target Path</strong> (the destination), and <strong>Redirect Type</strong> ("No" = internal rewrite with no visible redirect, "Temporary (302)", or "Permanent (301)").</p> <h3>Analyzing customer search terms</h3> <p>Under <em>Marketing &gt; SEO &amp; Search &gt; Search Terms</em>, Magento shows what customers actually searched for in your store's own search, including the <strong>Num Results</strong> column (number of hits). Search terms with zero results are a direct signal of missing products, incorrect synonyms, or a good target for an additional category or CMS page.</p></div>

<div class="prose prose-hyva max-w-none"><p>Which content automatically ends up in the generated sitemap, which doesn't, and how custom module content like our Tutorial section can be added afterwards.</p><p>Out of the box, Magento ships with exactly four "providers" that together determine the content of every generated <em>sitemap.xml</em>: the store root URL itself, categories, products, and CMS pages. Each provider is its own PHP class (a so-called "item provider") that gets asked, on every generation run: "which URLs should go into the sitemap for this store?" Anything that doesn't belong to these four types – such as a fully custom module like our Tutorial section – stays invisible to the sitemap until someone registers a custom provider for it.</p> <h3>Categories: all or nothing</h3> <p>Every category with <strong>Enable Category = Yes</strong> automatically ends up in the sitemap – Magento has NO individual toggle to "exclude this one category from the sitemap". Even <strong>Include in Menu = No</strong> (hiding a category from navigation) has zero effect on sitemap inclusion – the two settings are completely independent. If you really want to keep a specific category out of the sitemap, your only practical options are <strong>Enable Category = No</strong> (which also makes it unreachable in the store itself) or a targeted exclusion in <code>robots.txt</code>.</p> <h3>Products: visible AND enabled</h3> <p>Products are filtered on two criteria: <strong>Enable Product = Yes</strong> (status) AND <strong>Visibility</strong> other than "Not Visible Individually" (i.e. "Catalog", "Search", or "Catalog, Search"). A disabled product never shows up; an enabled product set to "Not Visible Individually" (e.g. a single variation of a configurable product) doesn't either – only the parent, visible main product gets listed. Here too, there's no dedicated "include in sitemap" checkbox on the product itself.</p> <h3>CMS pages</h3> <p>Active CMS pages (<strong>Enable Page = Yes</strong>) get included automatically – the same all-or-nothing logic as categories.</p> <h3>Setting priority and change frequency</h3> <p>Under <em>Stores &gt; Configuration &gt; Catalog &gt; XML Sitemap</em>, you set <strong>Frequency</strong> (how often the content typically changes – purely a hint to search engines, not a technical guarantee) and <strong>Priority</strong> (0.0 to 1.0, relative importance within your own sitemap) SEPARATELY for categories, products, and CMS pages. In the same area, <strong>Product Images Include Policy</strong> controls whether and which product images get added as extra <code>&lt;image&gt;</code> entries in the sitemap.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/priorit_t6kategorie.png}}" alt="PrioritätundÄnderungshäufigkeit" /> <h3>What does NOT get included automatically</h3> <p>Any content that runs through its own module and isn't a category, product, or CMS page stays invisible to the sitemap – until a custom item provider gets registered for it. Two concrete examples from this project:</p> <ul> <li><strong>Magefan Blog:</strong> already ships its own item provider (registered via its own <code>di.xml</code>) – blog posts and the blog index therefore already appear in the sitemap automatically, without us having to build anything for it.</li> <li><strong>Our Tutorial section (Mironsoft_Tutorial):</strong> series and chapters under <em>/tutorial/...</em> are a completely custom data structure (own database tables, own router) – until recently, they were therefore entirely absent from the sitemap. We've retrofitted this: a new class (<code>Mironsoft\Tutorial\Model\Sitemap\TutorialItemProvider</code>) registers itself with Magento's sitemap mechanism via <code>di.xml</code> and supplies every active series and chapter URL per store on every generation run. For you as an editor, this means: every new tutorial series and every new chapter automatically shows up in the sitemap on the next sitemap run – with no manual extra step.</li> </ul> <h3>Submitting the sitemap to Google</h3> <p>The generated sitemap alone isn't enough – Google needs to know about it. In <strong>Google Search Console</strong> (requires a free Google account; create and verify a property for your domain) under <em>Sitemaps</em>, enter the URL of your sitemap file (e.g. <code>https://yourdomain.com/sitemap_en.xml</code>). Google then crawls it on its own on a regular basis – resubmitting manually after every sitemap update is NOT necessary.</p> <p><strong>Practical tip:</strong> after major content additions (like a new Handbuch or Tutorial series), check under <em>Sitemaps</em> in Search Console whether the "discovered URLs" count increased as expected – if it doesn't, that usually points to a generation cron job that hasn't run yet, or an error in the relevant item provider.</p> <h3>Automatic entry in robots.txt</h3> <p>Under <em>Stores &gt; Configuration &gt; Catalog &gt; XML Sitemap &gt; Search Engine Submission Settings</em>, setting <strong>Enable Submission to Robots.txt</strong> to "Yes" automatically adds a <code>Sitemap:</code> line to robots.txt once the sitemap has been generated. This helps not only Google (which you've registered via Search Console anyway) but also other search engines like Bing, which primarily discover sitemaps through robots.txt.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/searchenginesubmissions6kategorie.png}}" alt="AutomatischerEintrag" /> <h3>Monitoring scheduled generation</h3> <p>On the <strong>Generation Settings</strong> tab of a given sitemap, you set <strong>Enabled</strong>, <strong>Start Time</strong>, and <strong>Frequency</strong> (Daily/Weekly/Monthly) for automatic regeneration via cron job. You can additionally configure <strong>Error Email Recipient</strong>, <strong>Error Email Sender</strong>, and <strong>Error Email Template</strong> – if generation fails, you get notified instead of only noticing weeks later that the sitemap content is outdated.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/generationsettings6kategorie.png}}" alt="GeplanteGenerierung" /> <h3>Separate sitemaps per store view/language</h3> <p>Use <strong>Add Sitemap</strong> to create a separate file per store view (e.g. <code>sitemap_de.xml</code> for the German store view and <code>sitemap_en.xml</code> for the English one) – each then contains only the URLs of its respective language version. This matters for multilingual stores, so search engines crawl the correct, language-specific URLs and URLs from a different store view don't accidentally end up in the wrong sitemap.</p> <h3>Size limits and automatic splitting</h3> <p>The <strong>Maximum No of URLs Per File</strong> and <strong>Maximum File Size</strong> fields (also under the XML sitemap configuration) limit how many URLs and how much data a single sitemap file may contain – per the official sitemap protocol, at most 50,000 URLs or 50 MB per file. If your store exceeds these limits, Magento automatically splits the sitemap into multiple files and additionally generates a parent sitemap index file that references all the individual files – with no extra effort required on your part.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/sitemapfile6kategorie.png}}" alt="Größenlimits" /> </div>