Domain Expiration SEO: Restore Your Site and Rankings

Latest Articles

Domain Expiration and SEO: How to RecoverDomain expiration can interrupt your website, slow search engine crawling, and put organic traffic at risk. The good news is that an expired domain doesn't automatically erase your SEO value. Table of Contents Toggle What Happens When a Domain Expires?Expiration and the grace periodRedemption and releaseHow Domain Expiration Affects SEOAvailability and crawlingIndexing and organic trafficWhat Happens to Backlinks and Existing SEO Value?Domain Expiration Recovery ChecklistRestore DNS, Hosting, and HTTPSPut DNS records back in placeTest the site visitors actually seeUse Search Console to Check RecoveryInspect priority URLsReview indexing and sitemap reportsMonitor Rankings, Traffic, and Business ResultsPrevent Another ExpirationProtect Your Search Visibility Recovery depends on how long the site was unavailable and what happened to the domain during that time. We recommend acting first to restore access, then reviewing search performance once the site is working again. What Happens When a Domain Expires? Your domain registration gives you the right to use an address for a set period. When that registration expires, renewal may still be possible, but the options change as the domain moves through different stages. Expiration and the grace period After expiration, your registrar may offer a grace period when you can renew the domain. The website or email may stop working during this window, even though renewal is still available. According to ICANN's domain renewal guidance, a registrar may offer an auto-renew grace period of 1 to 45 days. The exact window depends on the applicable policies. Some domains may have a shorter window or different rules. The practical takeaway? If you discover an expiration, start the renewal process right away. Redemption and release If the domain is deleted after expiration, it may enter a redemption period. This can give the previous registrant another chance to recover it, often with an additional fee. After redemption, the domain may move toward release and become available to someone else. It can also end up with a new owner through an expiration or auction process. Renewal and redemption options vary, so there isn't one timeline that applies to every domain. If you no longer control the domain, recovery becomes more complicated. The original website address may be unavailable, redirected, or used for different content. How Domain Expiration Affects SEO An expired domain can affect several parts of search performance at once. We find it helpful to separate what happens to visitors from what happens to search engines. Availability and crawling When a domain stops resolving or points to a parked page, visitors may not reach your website. Forms, bookings, and sales can stop immediately, even if your pages still appear in search results. Search engines also need access to crawl your pages. If Google can't reach the site, it can't reliably discover changes or refresh its understanding of the content. Different failures create different responses. A DNS failure isn't the same as a server error. Google's HTTP status code guidance says that 5xx server errors and 429 responses can cause its crawlers to temporarily slow down. An expired domain doesn't necessarily produce either response. Indexing and organic traffic Indexing is the process of storing and organizing pages for possible appearance in search results. If pages remain inaccessible, search engines may have trouble keeping their indexed information current, and important URLs can eventually disappear from results. A short interruption doesn't give us a reliable way to predict ranking changes. A longer outage, a parked page, or replacement content can create more uncertainty. Organic traffic can also fall for two different reasons: fewer people may see your pages in search, or people may click a result but find the website unavailable. That distinction matters when you review Search Console and analytics later. What Happens to Backlinks and Existing SEO Value? Backlinks are links from other websites to yours. They don't disappear from those other sites simply because your domain expires. However, visitors who follow them may reach an error, a parked page, or content that no longer matches the original link. If you regain the domain and restore the same pages at the same URLs, those existing links have a useful destination again. This is one reason we recommend preserving your original URL structure during recovery. The outcome becomes less predictable if someone else takes over the domain or replaces your content. Search engines may encounter a different website, and other site owners may remove links that no longer lead where they expected. After recovery, review your most important linked pages. If a page has moved permanently, use a relevant 301 redirect to its replacement. Avoid sending every old URL to the homepage, since a visitor looking for a particular service or article needs a useful destination. Domain Expiration Recovery Checklist The first goal is to get your domain and website working again. SEO checks come next. Use this order to keep the recovery focused: Renew or redeem the domain. Sign in to the registrar account and complete the available renewal or redemption process. Keep the receipt and record the date of recovery. Restore domain control. Make sure the domain is in the correct account and that you can manage its nameservers and contact information. Review DNS settings. Restore the nameservers and records your website and email need. Use your previous configuration or hosting records rather than guessing. Bring hosting and content back online. Confirm that your hosting account, website files, database, and any content delivery network are active and connected. Test important pages. Open the homepage, major service pages, forms, and any checkout or booking process. Test the HTTPS version and the URLs people use most. Review Search Console. Inspect priority URLs, look for indexing and crawl issues, and request indexing where a restored page needs another visit. Monitor search traffic and leads. Compare performance with a suitable period before the outage, and record changes as the site recovers. If renewal is no longer available because another party controls the domain, contact the current owner about a possible purchase. If you can't regain control, you may need a new domain. That is a larger recovery project, since you may not be able to redirect the old URLs. Restore DNS, Hosting, and HTTPS Renewing the domain is a major step, but it doesn't guarantee that the website is reachable. DNS, hosting, and HTTPS each have a separate job. Put DNS records back in place DNS connects your domain name to the services that handle your website and email. Think of it as the address book that points requests to the right place. Start with the nameservers. Then review the records at the active DNS provider. Your root domain may use an A or AAAA record, while www may use a CNAME record. Email and verification services can also depend on MX and TXT records. DNS changes may take time to reach different networks because records are cached. Our guide to DNS settings for SEO covers the records and access checks that support a reliable site. Test the site visitors actually see Open the preferred HTTPS address and several important pages. Confirm that the right content loads, redirects reach their intended destinations, and visitors don't see a certificate warning. Next, submit a test inquiry or use an available checkout test. A homepage that loads doesn't prove that every business function works. If you see a server error after DNS is restored, investigate hosting or application problems separately. Our guide to diagnosing 502 errors can help distinguish a gateway problem from a domain issue. Use Search Console to Check Recovery Once the site is accessible, Google Search Console helps you see what Google knows about your pages. It also gives you a way to investigate the URLs that matter most to your business. Inspect priority URLs Start with the homepage and your main service, product, or lead-generating pages. Enter each full URL into the URL Inspection tool. Review the last crawl information, any reported access issues, and the canonical URL Google selected. Then run a live test to see whether Google can access the page now. A successful live test is encouraging, but it doesn't mean Google's indexed version has already changed. After fixing an important page, you can request indexing. That request asks Google to revisit the URL; it doesn't guarantee an immediate crawl or a particular ranking. Review indexing and sitemap reports Open the Pages report to see patterns across the site. Google's Page indexing report shows the status of URLs Google knows about in your property. Look for important pages with access errors or unexpected exclusions. Also review your sitemap in the Sitemaps report. A successfully processed sitemap helps Google discover URLs, but it doesn't mean every page is indexed. If a restored page remains excluded, our search indexing guide can help you investigate other causes, including noindex directives, canonical settings, and internal links. Monitor Rankings, Traffic, and Business Results Recovery doesn't end when the homepage loads. Search reports and business outcomes help you see whether visitors are finding and using the restored site. In Search Console, open Performance and compare equivalent periods with the same search type. For example, compare the latest complete 28 days with the previous 28 days. If your business is seasonal, also look at the same period from the prior year. Review clicks and impressions together. Then narrow the report by page, query, device, and country. A drop across the whole site suggests a different problem than a decline limited to one service page or a group of branded searches. Use Google Analytics 4 to review organic visitors and what they do after arriving. Look at inquiries, purchases, or other actions that matter to your business. Search Console and GA4 measure activity differently, so their totals won't necessarily match. Keep a simple recovery log with the expiration date, restoration date, affected URLs, and fixes. Allow for reporting delays and normal variation before drawing conclusions from a single day's numbers. Prevent Another Expiration A reliable renewal process protects more than your domain name. It gives visitors and search engines a consistent path to your website. Turn on automatic renewal when available, keep a valid payment method on file, and use a contact email address you can access even if your domain email stops working. Set a separate calendar reminder before renewal as a backup. We also recommend keeping an inventory of your registrar, DNS provider, hosting account, and renewal dates. Add uptime alerts so you can respond quickly if the site becomes unavailable for any reason. Protect Your Search Visibility Domain expiration can interrupt access before you know whether rankings have changed. Renew the domain, restore the original site, and test the pages your visitors depend on. Then use Search Console and analytics to follow the recovery. With reliable access restored, you can address any remaining indexing or traffic issues with a clearer view of the problem. [...]
Read more...
Google Search Console Properties: Domain vs. URL PrefixFor most websites, we recommend a Domain property in Google Search Console. It gives you a broader view of search performance across subdomains, protocols, and paths. A URL-prefix property is useful when you need to focus on one version or section of a site. Table of Contents Toggle Google Search Console Properties at a GlanceWhat a Domain Property IncludesSubdomains and Site SectionsHTTP and HTTPS VersionsWhat a URL-Prefix Property IncludesProtocol and Host Must MatchPaths Can Narrow the ViewHow Verification DiffersDomain Properties Usually Require DNSURL-Prefix Properties Offer More OptionsWhich Property Should You Choose?Choose a Domain Property for Broad CoverageChoose a URL Prefix for a Focused ViewCan You Use Both Property Types?How to Set Up Your PropertyWhat to Check After SetupReview Performance in ContextInspect Pages and Indexing IssuesStart With the View You Need The choice affects which URLs appear in your reports and how you verify ownership. Let's look at the differences so you can set up the right view without missing important data. Google Search Console Properties at a Glance A property is the website or portion of a website you add to Google Search Console. Its boundaries determine which URLs you can monitor in that property. Think of a Domain property as a view of the whole building. A URL-prefix property lets you focus on one part of it. Here's how the two options compare for a site using example.com. FeatureDomain propertyURL-prefix propertyExample entryexample.comhttps://www.example.com/Protocols coveredAll protocolsOnly the specified protocolSubdomains coveredThe entered domain and its subdomainsOnly the specified hostPaths coveredAll paths under covered hostsOnly paths beginning with the specified prefixVerificationUsually requires a DNS recordOffers multiple verification methodsBest fitA broad view of a siteA specific site version or section The biggest distinction is coverage. Choosing a property doesn't change your website or give you a ranking boost. It changes the scope of the information you can access in Search Console. Google generally recommends a Domain property when appropriate and when you can complete Domain-level verification. For many site owners, that's the simplest starting point. What a Domain Property Includes A Domain property brings the versions of a domain together under one property. Enter the domain without a protocol or path, such as example.com, and Search Console covers URLs beneath that domain. Subdomains and Site Sections A Domain property for example.com includes the root domain and subdomains such as www.example.com, blog.example.com, and shop.example.com. It also includes paths under those hosts, such as /services/ and /blog/. This is helpful when different parts of your business live on different subdomains. You can start with a broader picture instead of switching between separate properties to see each area. You can also create a Domain property for a subdomain. A property for blog.example.com covers that subdomain and its descendants, but it doesn't include the parent domain or sibling hosts such as shop.example.com. HTTP and HTTPS Versions The same Domain property covers both HTTP and HTTPS. For example, it includes http://example.com/ and https://example.com/, along with covered subdomains. That broader coverage is useful during a move to HTTPS because old HTTP URLs can still appear in your data. It doesn't mean both versions should remain accessible. For a site using HTTPS, we recommend directing old HTTP URLs to the appropriate secure pages and using HTTPS URLs consistently in internal links, canonicals, and sitemaps. What a URL-Prefix Property Includes A URL-prefix property covers URLs that begin with the exact prefix you enter. The protocol, host, and any path in that prefix define the boundaries. Protocol and Host Must Match A property for https://example.com/ includes HTTPS URLs on example.com. It doesn't include http://example.com/, https://www.example.com/, or https://blog.example.com/. That difference can surprise beginners. Your browser may redirect one version to another, but the addresses still have different prefixes in Search Console. If you want separate reports for the HTTP and HTTPS versions, or for the root domain and a subdomain, you can add separate URL-prefix properties. A Domain property gives you the broader scope in one place. Paths Can Narrow the View A prefix can also include a folder. For example, https://example.com/blog/ covers URLs beneath that path, including https://example.com/blog/seo-tips/. It doesn't cover https://example.com/services/ or the blog on https://blog.example.com/. The ending slash matters too: /blog/ identifies that folder rather than a different path that starts with similar characters. This narrower setup can be useful for a team responsible for one section. Enter the prefix carefully so the property matches the pages you want to monitor. How Verification Differs Before Search Console gives you property access, Google asks you to prove that you control the site or the relevant part of it. The available methods depend on the property type. Domain Properties Usually Require DNS For a Domain property, Google generally asks you to add a DNS verification record. DNS connects a domain name with services on the internet, and its records are managed through your DNS provider. Search Console supplies a TXT record value for you to add. For a root domain, the host or name field is often blank or @, depending on the provider. DNS changes can take time to appear, so verification may not succeed immediately. Google notes exceptions for properties hosted on Google products such as Blogger and Google Sites. Its property setup instructions explain the available verification methods. URL-Prefix Properties Offer More Options A URL-prefix property can use DNS verification too, but it also supports other methods. Depending on your setup and access, you may be able to upload an HTML file, add an HTML tag, or use an eligible Google Analytics or Google Tag Manager setup. This flexibility helps when you can edit the website but don't control its DNS. For example, a site builder may provide a field for a Search Console verification tag. Keep the verification record, file, or tag in place after setup. Removing it can cause you to lose verified access. Verification proves control of a property; it doesn't configure redirects or change which pages Google indexes. Which Property Should You Choose? Your choice comes down to two questions: how much of the site do you need to see, and what can you access to verify ownership? Choose a Domain Property for Broad Coverage We recommend starting with a Domain property when you own the domain and can add its DNS record. It's a practical fit for a small business site with a www version, a blog subdomain, or a shop on another subdomain. It also reduces the chance of overlooking an older HTTP or non-www version. You can see the wider picture without creating a separate property for every host and protocol. If you're unsure which option to pick, start with a Domain property. It gives you room to monitor the site as its structure grows. Choose a URL Prefix for a Focused View A URL-prefix property makes sense when you only need one version or folder. A content team working on https://example.com/blog/, for example, may prefer a property focused on that section. It's also a useful starting point if DNS access isn't available and you can verify the site through an HTML tag or another supported method. You can add a Domain property later when you have the access needed. The tradeoff is a narrower view. Keep other hosts, protocols, and folders in mind when interpreting your reports. Can You Use Both Property Types? Yes. A Domain property and one or more URL-prefix properties can exist at the same time. We like this approach when you need a broad site view as well as a closer look at a particular section. For example, example.com can be your Domain property, while https://example.com/blog/ is a separate URL-prefix property. The Domain property covers the blog along with the rest of the domain. The prefix property focuses on the blog path. Overlapping properties can report on the same URLs. Don't add their totals together as if they represent separate traffic. You can also use filters in a broad property to investigate particular pages or sections. A separate prefix property can be convenient when that section deserves its own regular reporting view. Access deserves the same care as coverage. Give people access to the property they need for their work, and understand the permissions you grant. A property focused on a folder can help keep a section's reporting separate, while the business retains control of the broader property. For a closer look at the reports after setup, our Search Console beginner guide covers the checks worth making first. How to Set Up Your Property Once you've chosen your scope, the setup process is straightforward. You'll need access to the appropriate DNS settings or a supported verification method for the URL prefix. Open Google Search Console and choose Add property from the property selector. Select Domain for broad coverage, or URL prefix for a particular protocol, host, and optional path. Enter the domain or complete URL prefix. For a Domain property, leave off the protocol and any path. Follow the verification instructions for the method available to you. Add the supplied DNS record or complete one of the supported URL-prefix methods. Select Verify. Once verification succeeds, open the property and review its reports. If DNS verification doesn't work right away, allow time for the record to become available. Also review whether the value and host field were entered in the correct DNS settings. After setup, submit an XML sitemap for the pages you want Google to discover. A sitemap helps with discovery, but it doesn't guarantee indexing. Our guide to how Google crawls and indexes pages explains where sitemaps fit into that process. What to Check After Setup The right property gives you a useful view, but you'll still need to turn that information into practical SEO decisions. Review Performance in Context Open the Performance report and look at clicks, impressions, queries, and pages. Before comparing numbers, note which property you're viewing and which versions it covers. A Domain property and a URL-prefix property may show different totals because their scopes differ. A report for https://example.com/ won't include a shop on https://shop.example.com/, even though the Domain property covers both. Use the same property and date ranges when tracking changes over time. That consistency makes it easier to spot whether a change affects the whole site or one section. Inspect Pages and Indexing Issues For an individual page, select a property that includes the URL and use URL Inspection. Google's URL Inspection documentation explains the information available about the indexed version and live testing. Start with important pages that should appear in search. Review the indexing status and Google's selected canonical, then investigate any issue that applies to the page. A successful live test doesn't guarantee that Google has indexed it. If you find important pages marked as crawled but not indexed, our guide to troubleshooting crawled pages can help you investigate the next steps. Start With the View You Need For most site owners, a Domain property is the best starting point because it covers the domain's subdomains, protocols, and paths. A URL-prefix property gives you a focused view when you need one section or can't access DNS. Choose the scope that matches your goal, then use the reports to guide consistent improvements. You can add another property later without giving up the view you already have. [...]
Read more...
PDF SEO: How to Optimize Files for Google SearchPDF SEO starts with a file Google can find, read, and index. Give your document searchable text, a clear title, and a direct link from your website. Then make sure its server settings allow Google to access it. Table of Contents Toggle How Google Finds and Ranks PDF FilesDiscovery and crawlingIndexing and rankingMake the Text SearchableExport text instead of imagesUse OCR for scanned documentsWrite a Clear Filename and PDF TitleChoose a descriptive filenameEdit the document propertiesAdd Links That Help Visitors Find the PDFSet the Right HTTP HeadersUse a canonical header for duplicatesUse noindex when the PDF should stay out of searchImprove Mobile Usability and AccessibilityMake the file easier to readReduce unnecessary file sizeDecide When HTML Is the Better ChoiceMonitor PDF Visibility in Search ConsoleInspect the PDF URLReview search performancePDF SEO ChecklistGive Each PDF a Clear Purpose A PDF can appear in search results, but indexing doesn't guarantee rankings. The document also needs to answer a real searcher's question. Let's start with how Google handles the file. How Google Finds and Ranks PDF Files Google includes PDFs among its supported file types. That means a PDF can be a search result in its own right, not just a download attached to a web page. Discovery and crawling Google can discover a PDF through links on your website, links from other sites, or a sitemap. Once it finds the URL, Googlebot can request the file and examine the response. For a public PDF you want indexed, the URL should work without a login or password. It also needs to be accessible to Googlebot and return a successful response, such as 200 OK. Indexing and ranking After crawling, Google may add the document to its index. Indexing means the file is eligible to appear in search, but Google doesn't promise to index every file it discovers. When someone searches, Google selects results it considers useful and relevant. Clear content, a descriptive title, and links that help explain the document can support that process. A PDF still needs to compete with other useful results, including web pages. Make the Text Searchable The content inside your PDF is the foundation of its search visibility. If important information is trapped in pictures, it's harder to work with and harder for many visitors to use. Export text instead of images When possible, create the document in an editor such as Microsoft Word or Google Docs, then export it as a PDF. This usually preserves text as text rather than turning each page into a picture. Open the finished file and try to select and copy a few sentences. Paste them into a plain text editor. If the words come through in a sensible order, that's a useful first check. Use OCR for scanned documents A scan often starts as a collection of page images. Optical character recognition, or OCR, adds a searchable text layer by identifying the characters in those images. Google's PDF search guidance, published in 2011, says it may use OCR for image-based text. We wouldn't rely on that alone. Run OCR before publishing, then review the output for errors, especially in names, numbers, and headings. Keep important information in the document's text as well as in charts or images. That gives readers another way to understand the content. Write a Clear Filename and PDF Title Your filename and title help people recognize the document before and after they open it. They also make your files easier to manage as your site grows. Choose a descriptive filename Use a short name that describes the document, such as roof-maintenance-checklist.pdf. Separate words with hyphens and avoid names like document-final-2.pdf. A descriptive filename isn't a shortcut to higher rankings. Think of it as a useful label for your URL, your visitors, and your team. Once a PDF is published, avoid renaming it without a plan for the old address. Edit the document properties The visible heading on page one and the PDF's title property are separate things. In your document editor or PDF software, open the file properties and give the PDF a title that matches its subject. Google's 2011 PDF guidance identifies document title metadata and link text as signals it may use for a search result title. Keep those details consistent, while remembering that Google chooses the title it displays. A clear title such as "Roof Maintenance Checklist for Homeowners" is more useful than a string of repeated keywords. Add Links That Help Visitors Find the PDF A PDF buried in your uploads folder has fewer opportunities to be discovered. Link to it from a relevant page that explains what the reader will find and why the file is useful. For example, a roof maintenance article could link to its printable checklist with the words "download the roof maintenance checklist." That tells visitors more than a button labeled "click here." We also recommend adding a link inside the PDF back to a relevant page on your site. Someone who lands on the document through Google may not know who published it or where to find updated information. If the PDF is an important search destination, you can include its preferred URL in your XML sitemap. A sitemap helps Google discover a URL, but it doesn't force Google to index it. Our guide to search indexing covers the difference between discovery and inclusion. Set the Right HTTP Headers A PDF doesn't have an HTML page's <head> section. Some instructions therefore need to be sent in the HTTP response, which is the information your server returns when the file is requested. First, make sure the PDF is served with the application/pdf content type. You can inspect the response in your browser's developer tools under the Network panel. Select the PDF request and look at its response headers. Use a canonical header for duplicates If an HTML page and a PDF contain substantially the same content, decide which URL you prefer Google to show. Keep both available if visitors need both formats, but send a canonical signal from the duplicate to the preferred version. For a PDF, Google supports a Link response header with rel="canonical". The header uses an absolute URL and looks like this: Link: <https://www.example.com/original.pdf>; rel="canonical" The target can be a closely matching HTML page or another PDF. Point to the final preferred URL, then use that same URL consistently in internal links and your sitemap. Google's canonical guidance for non-HTML files explains this method. A canonical is a preference, not a guarantee. Don't point a detailed PDF to a short, loosely related page. Use noindex when the PDF should stay out of search Some public files need to remain accessible without appearing in Google. For those files, the response header X-Robots-Tag: noindex gives Google an indexing instruction. Don't block the PDF in robots.txt if Google needs to crawl it to see the noindex header. Also, noindex isn't a privacy control. Use access restrictions for sensitive documents. Our guide to PDF indexing with response headers covers where to apply the directive. Improve Mobile Usability and Accessibility A document that looks good on a desktop can be frustrating on a phone. Wide pages, small text, and large downloads make visitors work harder to use the information. Make the file easier to read Use readable type, clear headings, and sufficient contrast between text and background. Avoid placing essential text in tiny tables or across wide layouts that require constant zooming. For longer documents, add bookmarks and a useful table of contents. Tagged headings, logical reading order, and alternative text for meaningful images can also help people using assistive technology. Test the finished PDF on a phone and with a screen reader. A selectable text layer is helpful, but it doesn't guarantee an accessible document. Reduce unnecessary file size Large image files can make a PDF slow to open or download. Compress images, remove unused pages, and export at a resolution suited to how people will use the document. Keep a higher-resolution version when readers need to print detailed graphics. The goal is a file that's practical to open without sacrificing the information people need. Decide When HTML Is the Better Choice PDFs work well for printable checklists, forms, reports, and documents that need a fixed layout. If printing or preserving that layout is part of the purpose, a PDF gives visitors a useful option. HTML is often better for information people will read on a screen. A web page can adapt to smaller displays, support navigation, and make updates without asking visitors to download a new file. You can offer both formats. Publish the complete information as an HTML page and provide a PDF for readers who want to save or print it. If the two versions are substantially the same, use the canonical approach described above to indicate your preferred search result. If the PDF contains substantial information that isn't on the page, treat it as a distinct document rather than assuming the two are duplicates. Monitor PDF Visibility in Search Console Publishing the file is only the first step. Search Console helps you see whether Google knows about the URL and whether it receives search impressions or clicks. Inspect the PDF URL In Search Console, open URL Inspection and enter the complete PDF address. Review the available indexing status, crawl information, and any reported restrictions. You can also run a live test to look for access issues. Google's URL Inspection documentation explains the difference between the indexed version and the live test. A successful live test doesn't guarantee that Google will index or rank the file. If Google has crawled a PDF but hasn't indexed it, review its usefulness, duplicate versions, and internal links. Our guide to crawled but not indexed URLs offers a starting point for diagnosis. Review search performance In the Search results performance report, filter by the PDF's exact URL when data is available. Review impressions, clicks, queries, and average position together. Impressions without many clicks can prompt a closer look at the searches and the result title. Low visibility may call for stronger content or better links, but avoid drawing conclusions from a single day's data. You can also find PDFs with search operators. Treat those results as a rough view, not a complete indexing report. PDF SEO Checklist Before you publish or update an important document, work through these steps: Make the PDF public and accessible to Googlebot if you want it indexed. Export selectable text or run OCR, then review the extracted words. Give the file a descriptive name and set a clear document title. Link to the PDF from a relevant page using descriptive link text. Return 200 OK and the application/pdf content type. Choose a preferred URL for close duplicates and use a canonical header where appropriate. Use an X-Robots-Tag header when a public PDF shouldn't appear in search. Test readability, accessibility, and file size on a phone. Inspect the URL and review available performance data in Search Console. Give Each PDF a Clear Purpose A search-friendly PDF starts with useful content that Google and your visitors can read. Clear links and sensible server settings help Google find the file and understand which version you prefer. Choose HTML for flexible online reading when it fits the task, and offer a PDF when the download adds value. Then use Search Console to guide your next improvement. [...]
Read more...
Why Google Shows the Wrong Site NameGoogle may show the wrong site name when your homepage sends mixed signals, Google can't access it, or a recent change hasn't been processed. An unexpected Google site name can also appear when Google chooses a different name than the one you've suggested. Table of Contents Toggle Key TakeawaysHow Google Site Names Are ChosenWhy Google May Show an Unexpected NameYour homepage sends mixed signalsGoogle can’t access the right homepageYour changes haven’t been processedFind the Homepage Google UsesAdd WebSite Structured Data to the HomepageSet the preferred name and homepage URLAdd an alternate name when it helpsMake the Visible Homepage Signals MatchTest the Markup and Request IndexingInspect the live homepageUse URL Inspection after the fixWhat to Check After Making ChangesFrequently Asked QuestionsCan I force Google to use my site name?Does changing the title tag change the site name?Will fixing the site name improve rankings?Should I request indexing for every page?Give Google a Clear, Consistent Name The good news is that you can give Google a clearer preference. Let's start by identifying the part of the search result that needs attention, then work through the fixes. Key Takeaways Google uses homepage information and other signals to choose a site name. Your preferred name isn't guaranteed. WebSite structured data can communicate your preference, especially when it matches the name visitors see. After a fix, use Search Console to inspect and request indexing for the homepage. Processing can take several days to several weeks. How Google Site Names Are Chosen The site name is the label Google displays to identify your website in a search result. It generally appears near the top of the result, alongside the site's favicon and displayed URL. Think of it as the name on a storefront. The individual page title is more like the sign describing what's inside a particular room. Google creates site names automatically using information it finds on your website and elsewhere on the web. Your homepage is an important source, and Google recommends adding WebSite structured data there to indicate your preferred name. Its site-name guidance also describes the homepage signals that can support that preference. Before changing anything, make sure you're looking at the right part of the result. If the site name is correct but the clickable page title is wrong, you'll need a different approach. Our guide to Google title rewrites covers that problem. The favicon is separate, too. Changing your site name won't replace an outdated icon. Why Google May Show an Unexpected Name An old brand, a domain name, or an abbreviation can appear for different reasons. Start with the most likely sources of confusion on your homepage. Your homepage sends mixed signals Your logo may say one thing while the homepage title, headings, and structured data use another. Google has to interpret those signals together, so inconsistent branding can make your preferred name less clear. For example, if a site uses a shortened brand name in its header but an older business name in its markup, either name may compete for attention. A long homepage title packed with service keywords can add more confusion. First, choose the name you want people to associate with the site. Then use it consistently where your brand appears. Google can’t access the right homepage Google needs to reach the homepage to read its signals. A robots.txt block, a noindex directive, a login requirement, or a server problem can prevent Google from processing the page as intended. Redirects matter, too. If the homepage redirects, Google uses information from the destination it can access. Updating a page that redirects elsewhere may leave the real source of the site name unchanged. Your changes haven’t been processed A rebrand or corrected markup can be live on your website while Google still displays an older name. Your browser shows the current page, but that doesn't mean Google has recrawled and processed it. If the homepage already shows the preferred name in search while internal pages show the old one, allow time for processing before changing the setup again. Find the Homepage Google Uses Before editing markup, identify the homepage associated with the result you're troubleshooting. Open the result, note its hostname, and follow the homepage URL to its final destination. For example, a redirect may take visitors from an older domain to a newer one. In that case, the destination homepage needs the accurate name and markup. A correction on the old page alone won't give Google the same information if it follows the redirect. Next, inspect the destination in Google Search Console. URL Inspection can show the indexed page's crawl details and Google's selected canonical URL, when available. A canonical is the URL Google chooses as the main version among similar pages. If Google selects a different homepage version than you expected, compare the redirects, internal links, and canonical declarations. Our guide to canonical tags for duplicate URLs explains how those signals work together. Also look at accessibility. The final homepage should load normally for Googlebot, without a password prompt, a noindex instruction, or a crawl block. Fix those issues before requesting another crawl. Add WebSite Structured Data to the Homepage Structured data is a way to label information so search engines can interpret it more easily. We prefer JSON-LD because it's straightforward to add and maintain without changing the page's design. For a site name, the relevant Schema.org type is WebSite. Google recommends placing it on the homepage, rather than relying on markup added only to an internal page. Set the preferred name and homepage URL In the WebSite markup, use the name property for the site's preferred name. Set the url property to the canonical homepage URL for the site. For example, our brand name is NKY SEO. A site using that name should present the same wording in its homepage branding and its name property. The goal is a recognizable name, not a string of keywords or a description of every service. Many SEO plugins and website platforms provide fields for site information or generate WebSite markup automatically. Look at the existing output before adding another version. Conflicting names in multiple markup blocks can make the preference harder to interpret. Add an alternate name when it helps The optional alternateName property gives Google another name to consider. It can include one or more alternatives in preference order, such as a genuine abbreviation or another version people use for the brand. Google also suggests the lowercase domain or subdomain as a fallback when it doesn't select the preferred name. Use alternatives that make sense for your site, rather than adding keyword variations. Our structured data SEO guide explains how to keep schema accurate and manageable. Remember, valid markup communicates a preference. It doesn't force Google to display that name. Make the Visible Homepage Signals Match Once the markup is in place, look at the homepage as a visitor would. Can someone easily identify the site name without reading the code? Use the preferred name in visible branding, such as the site header. Review the homepage title and main heading for outdated names or conflicting versions. The og:site_name property, if your site uses it, should support the same identity. You don't need to repeat the name in every paragraph. A consistent, recognizable brand is more useful than a homepage filled with repeated keywords. Also keep related business details consistent across your website and public profiles. Our guide to entity SEO covers how clear names and identifiers help search engines understand a brand. If you use Organization or LocalBusiness markup, keep its business name accurate too. Those types describe an organization or business, while WebSite markup communicates information about the website. Google's Organization markup guidance covers those related details. Test the Markup and Request Indexing After publishing your changes, test what Google can access. A setting saved in your content management system doesn't always mean the expected markup appears in the finished page. Inspect the live homepage Open the final homepage and review its source for WebSite, name, and url. If a plugin generates the markup, look for an older or conflicting version elsewhere in the page. Next, use the Schema Markup Validator to find syntax problems. Google's structured data introduction explains how this information is added to a page. Validation tells you whether the markup can be read. It doesn't guarantee Google will choose your preferred name. Also compare the markup with the visible homepage, because technically valid code can still contain an outdated brand. Use URL Inspection after the fix In Search Console, enter the exact final homepage URL. Review the indexed information, including the last crawl and selected canonical, then run a live test to look for access problems. If the live page is accessible and the correction is published, select Request Indexing. This asks Google to revisit the homepage. It doesn't promise an immediate crawl or a particular search appearance. Our Google Search Console beginner's guide can help you get familiar with the inspection and indexing reports. What to Check After Making Changes Record the date you published the fix and keep the setup stable while Google processes it. Repeatedly changing your brand name or submitting the same URL won't make the update happen faster. Google says crawling and processing can take several days to several weeks. That range is an estimate, not a deadline. A successful live test shows what Google can access now; it doesn't mean the search result has already updated. When you review the result, use the same query and pay attention to the hostname. Search the homepage and a relevant internal page, but treat each result as an observation rather than a complete picture of your site's indexing. If the old name remains after Google has had time to process the change, return to the basics. Look for an accessible final homepage, consistent visible branding, and conflicting WebSite markup. If the homepage name has changed but internal results haven't, give those results more time. Frequently Asked Questions Can I force Google to use my site name? No. You can indicate a preference with WebSite structured data and consistent homepage signals, but Google chooses what to display. Does changing the title tag change the site name? A homepage title can provide useful context, but it isn't the only signal Google uses. Update an outdated title as part of a consistent branding fix, rather than expecting that edit alone to control the site name. Will fixing the site name improve rankings? A clearer name can help people recognize your site in search results. It isn't a guaranteed ranking boost, so focus on accuracy and brand recognition rather than treating the change as a shortcut. Should I request indexing for every page? Start with the corrected homepage. That's where Google recommends placing the site-name markup, and it's the page to inspect and request for recrawling after your change. Give Google a Clear, Consistent Name A wrong site name can come down to conflicting information, an inaccessible homepage, or processing time. The strongest fix is to make your preferred name clear in both the homepage content and WebSite markup. Start with the homepage Google can reach, correct the signals, and request indexing. Then give the change time to work before making another round of edits. [...]
Read more...
Google Nosnippet: How to Control Search PreviewsYou can use Google’s nosnippet directive to stop Google from showing a text snippet or video preview for a page while allowing the page to remain indexed. Add the directive to a robots meta tag or an HTTP response header, then make sure Google can crawl the URL. Table of Contents Toggle What Google nosnippet controlsChoose the right snippet directiveAdd nosnippet with a robots meta tagApply the rule to search enginesTarget Google with googlebotAdd nosnippet with an X-Robots-Tag headerSet the header for a fileInspect the responseLimit snippet length with max-snippetExclude selected text with data-nosnippetMark the text you want excludedKeep the rest of the page usefulVerify the change in Search ConsoleTroubleshoot common snippet problemsCheck crawl access and conflicting rulesCheck the URL and the timingKeep snippet control aligned with your goal Full suppression isn't the only choice. If you want more control without losing the entire preview, you can limit snippet length or exclude selected text. Let's start with what each option does. What Google nosnippet controls A search snippet is the text that may appear beneath a page title in Google Search. Google can create it from page content or use a meta description when that description better matches a search. The nosnippet directive tells Google not to show a text snippet or video preview for the URL. A static image thumbnail may still appear when Google considers it useful. Google also applies snippet controls to features such as Discover, AI Overviews, and AI Mode. According to Google's robots directive documentation, nosnippet prevents page content from being used as direct input for AI Overviews and AI Mode. The distinction is search appearance versus indexing. A page with nosnippet can still appear in search results. If your goal is to remove a page from Google's index, the relevant directive is noindex. Also, snippet controls aren't a privacy system. Visitors can still access content on a public page, and other websites or search engines may handle instructions differently. Choose the right snippet directive The best choice depends on how much content you want Google to display. Here's a comparison: DirectiveWhere it goesWhat it controlsnosnippetRobots meta tag or HTTP headerSuppresses the page's text snippet and video previewmax-snippet:150Robots meta tag or HTTP headerLimits the text snippet to 150 charactersdata-nosnippetSupported HTML elementExcludes the marked text from snippets We recommend nosnippet when you don't want a text preview at all. For a shorter preview, use max-snippet. When only one section needs to stay out of snippets, data-nosnippet gives you more precise control. Keep in mind that Google chooses snippets based on the search query. A limit sets a maximum; it doesn't guarantee that Google will use every available character. Add nosnippet with a robots meta tag A robots meta tag is an HTML instruction placed inside a page's <head>. It's a practical option when you can edit the page template or control SEO settings in your website platform. Apply the rule to search engines Add this tag inside the HTML head: <meta name="robots" content="nosnippet"> The robots name addresses crawlers generally, although each search engine decides which instructions it supports. For Google, this rule applies to the page containing the tag. First, locate the page's head settings in your content management system or template. Add the tag, publish the change, and inspect the output that visitors and crawlers receive. Avoid putting the tag in the visible page body. Target Google with googlebot If you want the instruction to target Google, use: <meta name="googlebot" content="nosnippet"> Choose the version that matches your goal. A Googlebot-specific tag doesn't instruct other search engines to suppress their snippets. You don't need to add index, follow to keep normal indexing and link-following behavior. Those are Google's defaults when no more restrictive instruction applies. Google's supported meta tags and attributes cover the available syntax. Add nosnippet with an X-Robots-Tag header The X-Robots-Tag is an HTTP response header. It travels with the server response instead of appearing in the page's HTML. This option works for HTML pages and is useful for PDFs or other files that don't have an HTML head. Set the header for a file The header itself looks like this: X-Robots-Tag: nosnippet Add it through a server configuration, hosting control, or application setting that can set response headers for the target URL. For a PDF, apply the header to the PDF response itself, not only to the page that links to the file. Our guide to X-Robots-Tag for non-HTML files covers the header's role for assets such as PDFs, images, and videos. Inspect the response Open the target URL in your browser, then use the browser's developer tools and select the Network panel. Reload the page or file, select its request, and look under response headers for X-Robots-Tag. If the URL redirects, inspect the final response too. The important instruction is the one Google receives for the resource it crawls. A header set on one URL doesn't automatically apply to every related file. Review the exact responses affected by the configuration before rolling it out across a larger section of your site. Limit snippet length with max-snippet Want to keep a preview while giving Google less text to work with? Use max-snippet and a character limit. For example, this meta tag sets a maximum of 150 characters: <meta name="robots" content="max-snippet:150"> The equivalent response header is: X-Robots-Tag: max-snippet:150 The number counts characters, not words. A value of -1 lets Google choose the length, while max-snippet:0 is equivalent to nosnippet. Use a valid number, since Google ignores an unparseable value. For positive limits, max-snippet controls textual snippets rather than setting limits for image or video previews. Google also documents exceptions where separately granted permissions can affect permitted uses of content. There isn't one ideal character limit for every website. Choose a limit that supports your goal, then review how your pages appear. If you want to improve the available description instead of restricting it, our meta description SEO guide is a useful next step. Exclude selected text with data-nosnippet Sometimes the page deserves a normal snippet, but one passage doesn't. That's where data-nosnippet helps. It marks a portion of HTML that Google shouldn't use in a text snippet. Mark the text you want excluded Add the attribute to a supported span, div, or section element. For example: <span data-nosnippet>Contact us for a quote.</span> Google can still use eligible text elsewhere on the page. This makes the attribute useful for repeated page elements or passages that don't make sense outside their surrounding content. Use valid HTML and close the element correctly. The attribute is Boolean, so you don't need to assign it a value. Google's supported HTML attribute reference lists where it can be used. Keep the rest of the page useful Place the attribute around the smallest passage that meets your goal. If you mark a large section, Google has less text available to create a relevant preview. Also, remember that excluding text from snippets doesn't hide it from visitors. If information shouldn't be public, restrict access to the content itself instead of relying on a search directive. We recommend putting the attribute in the delivered HTML rather than depending on a late JavaScript change. Then inspect the rendered page to see what Google receives. Verify the change in Search Console After publishing a directive, use Google Search Console to compare the live page with Google's recorded information. This helps you separate an implementation problem from a change that hasn't been processed yet. Open the correct Search Console property and enter the full URL in URL Inspection. Review the indexed information, including the last crawl date and any access or indexing issues. Select "Test live URL" and open the tested page details. For an HTML tag, look for the directive in the HTML Google receives. Inspect the response headers in your browser when you're using X-Robots-Tag. Request indexing after the fix, then allow time for Google to revisit the URL. A successful live test describes the page as it exists at test time. It doesn't mean Google's indexed version or search result has already updated. An indexing request also doesn't guarantee an immediate refresh. Compare the URL you changed with Google's selected canonical, where Search Console provides it. If Google treats another URL as the main version, inspecting the duplicate alone may not explain the result you see. Our search indexing guide explains how to interpret indexing and crawl information when the page itself is difficult to find. Troubleshoot common snippet problems If the directive isn't having the expected effect, start with access and conflicts. A small configuration issue can affect a whole group of pages. Check crawl access and conflicting rules Google must be able to fetch a URL to read its meta tag or response header. A robots.txt rule that blocks the crawl can prevent Google from seeing the instruction. Our guide to robots.txt crawl control explains how those rules work. Next, look for multiple robots tags and headers. Google applies the more restrictive instruction when rules conflict. For example, nosnippet takes precedence over max-snippet:50, so the shorter-preview setting won't restore a text snippet. Shared templates, SEO plugins, server settings, and caching systems can all affect the final response. Review the output rather than relying only on a setting in the editor. Check the URL and the timing Make sure the directive is on the URL that appears in search, including the correct protocol and path. If a redirect leads elsewhere, inspect the destination. Then compare the live change with Google's last crawl. Search results can reflect an earlier version until Google processes the update. A site: search can provide a rough view, but it isn't a complete indexing report. If you've removed nosnippet and want a preview again, remove conflicting restrictions as well. Google still chooses whether and how to create a snippet for each query. Keep snippet control aligned with your goal The right directive depends on the result you want. Use nosnippet to suppress the text preview, max-snippet to set a limit, or data-nosnippet to exclude selected text. Start with one page or file, inspect the delivered tag or header, and review it in Search Console. That gives you a practical way to control search previews without confusing snippet settings with indexing. [...]
Read more...

Domain Expiration and SEO: How to Recover

What Happens When a Domain Expires?

Expiration and the grace period

Redemption and release

How Domain Expiration Affects SEO

Availability and crawling

Indexing and organic traffic

What Happens to Backlinks and Existing SEO Value?

Domain Expiration Recovery Checklist

Restore DNS, Hosting, and HTTPS

Put DNS records back in place

Test the site visitors actually see

Use Search Console to Check Recovery

Inspect priority URLs

Review indexing and sitemap reports

Monitor Rankings, Traffic, and Business Results

Prevent Another Expiration

Protect Your Search Visibility

Submit a Comment Cancel reply

Who we are

Comments

Media

Cookies

Embedded content from other websites

Who we share your data with

How long we retain your data

What rights you have over your data

Where your data is sent